Git分支的重新基于同步

Question

我最近就多台电脑上使用Git进行开发的设置提出了一个问题，并在这里得到了解答。我得到的方案解决了我的主分支(master)的情况，但不能解决基于主分支的侧分支(side branches)。

这是我目前的设置：

A--B--C--D  master
          \
           E--F--G--H  BUG_37

BUG_37 是一个分支，正在开发对系统中一个可选择跟踪的 bug 的修复，并最终将合并到主线中，但目前是独立的。在这种情况下，我在一台机器上对 master 分支进行了一些更改：

A--B--C--D--I--J--K  master
          \
           E--F--G--H  BUG_37

我随后将BUG_37分支变基到master上，以确保它作为最新更改的增强功能正常工作:

A--B--C--D--I--J--K  master
                   \
                    E1--F1--G1--H1  BUG_37

假设我们在rebase之前遇到了一些需要手动修复的冲突。如果我将这些更改推送到远程存储库，现在希望将更改拉回另一个开发系统，该系统仍具有原始设置，最好的方法是什么？运行 git pull --rebase 将再次运行rebase，并且我必须手动处理第一次经历的冲突，对吗？如果我在处理冲突时犯了一个小错误，导致E1-H1在这个新系统中略有不同，我的存储库将更加不同步。

如何使本地存储库回到原始状态，并使远程存储库处于第三个状态，以确保本地存储库与远程存储库完全匹配（删除E-H的更改并将BUG_37 的 HEAD 移动到新位置）？

- MidnightLightning

Answer 1

如果一个分支已经被分享了，我不会在它上面进行变基。虽然这样可以得到最干净的历史记录，但是它将更改 BUG_37 中所有提交的哈希值。因此，在目标机器上，您需要完全删除 BUG_37 并重新拉取它。这样做一两次还好，但作为常规工作流程并不太好。

将master合并到BUG_37中要容易得多；然后合并提交（您解决冲突的提交）可以推送到其他机器，而且不需要删除分支。

- Ben James

Answer 2

删除分支，然后从远程仓库拉取两个分支。

git branch -D BUG_37
git pull origin master
git pull origin BUG_37:BUG_37

如果你不确定这个方法是否可行，不想在删除本地的BUG_37分支之前进行实验，可以将远程分支拉取到另一个本地分支：

git pull origin BUG_37:NEW_BUG_37

- Jakob Borg

Answer 3

我刚刚尝试了一下，当从一个被rebase过的分支pull时，使用git pull --rebase命令是有效的。如果没有--rebase标志，提交记录将会重复出现，但是使用--rebase标志，提交记录不会重复出现。

- char101

Answer 4

我遵循相同的工作流程，在笔记本电脑和台式机之间切换。我的主要仓库在台式机上，笔记本电脑克隆台式机的仓库。最终它们会不同步，因为我想在更新 master 后变基我的主题分支。

简单的答案是，不要使用 git，而是使用 rsync 来保持您的仓库同步。如果您知道只有自己在工作，那么这是有意义的。

好吧，我也不是太喜欢这个解决方案。所以，这可能会更加"干净一些"。在笔记本电脑上，从台式机的仓库拉取变基后的分支时:

git co topic
git fetch origin/topic
git reset --hard origin/topic

这将丢弃桌面仓库中不在提交中的任何更改，因此请确保您真的想要这样做。

此外，您可能只需git pull笔记本电脑的master分支，因为它应该始终是快进的，因为您可能不需要对其进行变基。我认为对主题分支进行变基是有意义的，否则在最后尝试将其合并回主分支时会很麻烦。

- cmcginty