如何在git中备份私有分支

发布于 2024-07-22 13:13:12 字数 452 浏览 6 评论 0 原文

我有一个本地分支,负责 git 的日常开发工作。 我的工作流程是:

  1. 在 local_branch 上做一些事情,提交
  2. 获取 origin/master
  3. 重新设置 local_branch 以赶上来自 origin/master 的新内容

这一切都很好,但是我遇到的大多数建议都说不应该“推送”私有分支,定期执行 rebase。

这里的问题是,在这种情况下,本地分支没有备份到服务器,保存工作的唯一方法是将其合并回“可推送”分支(即 origin/master),

您对工作流程的建议是什么这个案例?

谢谢!

更新:我意识到我最初的要求之一(避免使用外部实用程序)是不必要的限制。

我当前的解决方案是将所有存储库存储在云同步文件夹中 - 这样我就可以免费获得备份。

I have a local branch for day-to-day dev work in git. My workflow is:

  1. Do stuff on local_branch, commit
  2. Fetch origin/master
  3. Rebase local_branch to catch up with new stuff from origin/master

It all works fine, however most of the recommendations I encountered say that one should not "push" private branches, on which rebase is regularly performed.

The problem here is that in this case local branch is not backed up to a server and the only way to save the work is to merge it back to "pushable" branch (i.e. origin/master)

What would be your recommendations on the workflow in this case?

Thanks!

UPDATE: I realised that one of the original requirements I had (avoiding usage of external utilities) is unnecessary limiting.

My current solution is to store all my repositories in a cloud-synchronised folder - this way I get backup for free.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

苦笑流年记忆 2024-07-29 13:13:12

我使用 --mirror 选项并推送到个人备份存储库:

将其添加为远程:

git remote add bak server:/path/to/backup/repo

进行备份:

git push --mirror bak

这将自动使您的备份存储库看起来像您的活动存储库 -- 将创建、删除、更新分支(甚至强制/非快进)根据需要。 您也可以为此创建一个别名:

git config alias.bak "push --mirror bak"

然后,当您想要进行备份时,只需运行“git bak”即可。 您也可以将其放入 cron 作业中。

I use the --mirror option and push to a personal backup repository:

Add it as a remote:

git remote add bak server:/path/to/backup/repo

Do the backup:

git push --mirror bak

This will automatically make your backup repository look like your active one -- branches will be created, deleted, updated (even forced/non-fastforwards) as needed. You can make an alias for this too:

git config alias.bak "push --mirror bak"

Then, it's just a matter of running "git bak" when you want to do a backup. You could also throw this into a cron job.

牵你的手,一向走下去 2024-07-29 13:13:12

推送个人分支并没有什么问题。 通常不鼓励这样做,因为人们可能会根据您的分支开始工作,并且当您变基时,他们的更改会保持浮动。

我所做的是使用前缀来表示“这是我的分支,使用它需要您自担风险”,例如:fc-general-cleanup

There's nothing wrong with pushing personal branches. It is generally discouraged because people might start work based on your branch, and when you rebase, their changes are left floating.

What I do is use a prefix to denote "this is my branch, use it on your own risk", like: fc-general-cleanup.

歌入人心 2024-07-29 13:13:12

另一种选择是将“local_branch”推送到“origin”存储库,但推送到该存储库中它自己的分支(而不是“master”),即:

git push origin local_branch:local_backup

然后当你准备好进行另一个备份(并且在完成一些工作和变基之后)只需从原始存储库中删除备份分支,然后再将其推出:

git push origin :local_backup <== = 从源中删除分支

git push origin local_branch:local_backup

这样,在从“origin/master”重新设置基础后,在推送“local_branch”时就不会遇到问题。

如果删除备份分支让您感到紧张(直到您最终将工作提交给“master”之后),您始终可以继续推送到具有新名称的新分支(例如“local_backup1”、“local_backup2”等) 。

Another option would be to push "local_branch" to the "origin" repo, but to it's own branch in that repo (not "master"), i.e.:

git push origin local_branch:local_backup

Then when you are ready to make another backup (and after you've been doing some work and rebasing) just delete the backup branch from the origin repo before you push it out again:

git push origin :local_backup <=== deletes the branch from origin

git push origin local_branch:local_backup

This way you won't run into problems pushing "local_branch" after it has been rebased from "origin/master".

And if deleting your backup branches makes you nervous (until after you've finally committed your work to "master"), you could always keep pushing to a new branch with a new name (e.g. "local_backup1", "local_backup2", etc).

厌味 2024-07-29 13:13:12

您可以设置另一个远程存储库来将所有分支推送到其中吗? 另一件需要考虑的事情是备份本地计算机上的所有内容(重要的),包括 git 存储库。

Can you set up another remote repository that you do push all of your branches to? The other thing to consider is just backing up everything (important) on your local machine, including the git repo.

狂之美人 2024-07-29 13:13:12

推送到您要变基的同一分支没有任何问题。 这些图应该说明为什么它工作得很好:

可以说,这就是您对 local_branch 进行分支并对其进行了几次提交(C 和 D)之后的提交图。 自从你分支 local_branch 以来,其他人已经对 origin/master 进行了一次提交(E):

A -- B -- E  [origin/master]
      \
       \    
        \-- C -- D  [local_branch]

然后在运行“git rebase origin/master”之后,提交图将如下图所示。 “origin/master”仍然是相同的,但“local_branch”已经重新设置:

A -- B -- E  [origin/master]
           \
            \
             \-- C -- D  [local_branch]

在这个阶段,如果你执行“git push origin local_branch:master”,那么它将导致简单的快进。 “origin/master”和“local_branch”将是相同的:

A -- B -- E -- C -- D  [origin/master],[local_branch]

现在您可以自由地在“local_branch”上做更多工作。 最终你可能会得到这样的结果:

A -- B -- E -- C -- D -- G -- I [origin/master]
                     \
                      \
                       \-- F -- H [local_branch]

请注意,这看起来很像起始图。 您可以一遍又一遍地重复这个过程。

您应该避免推送到某个其他分支,即您不从中进行变基的分支。 这就是你会遇到麻烦的地方(对于另一个分支,在你从“origin/master”重新建立基础之后,你的“local_branch”历史看起来突然被重写了)。

There is nothing wrong with pushing to the same branch that you are rebasing from. These diagrams should illustrate why this works fine:

Lets say this is what the commit graph looks like after you've branched local_branch and made a couple of commits to it (C and D). Someone else has made one commit (E) to origin/master since you branched local_branch:

A -- B -- E  [origin/master]
      \
       \    
        \-- C -- D  [local_branch]

Then after running "git rebase origin/master", the commit graph will look like the next diagram. "origin/master" is still the same, but "local_branch" has been rebased:

A -- B -- E  [origin/master]
           \
            \
             \-- C -- D  [local_branch]

At this stage, if you do "git push origin local_branch:master", then it will result in a simple fast-forward. "origin/master" and "local_branch" will be identical:

A -- B -- E -- C -- D  [origin/master],[local_branch]

Now you are free to do more work on "local_branch". Eventually you might get something like this:

A -- B -- E -- C -- D -- G -- I [origin/master]
                     \
                      \
                       \-- F -- H [local_branch]

Notice this looks a lot like the starting graph. You can keep repeating this process over and over.

You should avoid pushing to some other branch, one that you are not rebasing from. That is where you will run into trouble (to the other branch, it will look like your "local_branch's" history has suddenly been re-written, after you've rebased from "origin/master").

長街聽風 2024-07-29 13:13:12

这就是我所做的。 但是——这不是私人的。 我这样做是为了我可以与自己合作(可以这么说)。 它让我可以在两个或多个盒子上的同一个分支上工作。 如果其他人有权访问共享存储库,他们可以看到我在分支上所做的工作。 当然,在我的家庭仓库中,没有其他人可以访问,所以它仍然是私有的。 在 github 上,全世界都可以看到我的东西。 就像他们真的很关心一样。 ;)

Here's what I do. But - this isn't private. I do this so that I can collaborate with myself (so to speak). It lets me work on the same branch on two or more boxes. if other people had access to the shared repo, they could see the work I'm doing on the branch. Of course, on my home repos, nobody else has access, so it's still private. On github, all the world could see my stuff. Like they really care. ;)

隔岸观火 2024-07-29 13:13:12

我宁愿使用 git bundle,它仅生成一个文件(包括所有私有分支),并同步该文件使用 DropBox 文件。
Git 与 Dropbox”

请参阅“ .com/questions/2129214/backup-a-local-git-repository/2129286#2129286">备份本地 Git 存储库", Yars 提到与 Dropbox 同步时出现错误。

Rather than relying on Dropbox to synchronize all the files of a git repo, I would rather use git bundle, which produces only one file (including all your private branches), and sync that file with DropBox.
See "Git with Dropbox"

In "Backup a Local Git Repository", Yars mentioned having sync errors with Dropbox.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文