将git rebase应用到远程更新

Question

我和一个用git进行源代码管理的小团队合作。最近，我们一直在使用主题分支来跟踪功能，然后将它们合并到本地的master分支，然后推送到远程服务器上的中央git存储库。当master分支没有发生更改时，这种方法效果很好：我创建主题分支，提交它，将其合并到master分支，然后推送。太好了。

但是，如果有人在我之前推送到原始库，那么我的提交就不是快进式的。因此，会出现合并提交。当主题分支需要与本地的master分支合并以确保我的更改与当前的代码相匹配时，也会发生这种情况。因此，我们到处都是合并提交，并且git日志可以与友谊手链相媲美。

因此，重新设置基础是明显的选择。我想要的是：

• 创建包含多个提交的主题分支
• 切换到master并拉取（快进因为我没有提交到master）
• 将主题分支重新设置到新的master头部
• 将主题分支重新设置为对master进行重新基础化，使主题从主线头部开始，并将主线提升到我的主题头部

我目前的做法如下：

git checkout master
git rebase master topic_1
git rebase topic_1 topic_2
git checkout master
git rebase topic_2
git branch -d topic_1 topic_2

有更快的方法吗？

- Blake Chambers

Answer 1

你知道 git pull --rebase 吗？它在拉取时进行变基而非合并操作，可以避免合并提交记录污染你的历史记录。

你还可以通过 branch.<name>.rebase 和 branch.autosetuprebase 配置选项将其设置为分支的默认行为。

- Martin Owen

---

是的，我经常使用它来将共享代码库更新到最新版本。然而，这篇文章更多地涉及特性分支，一种更简化的方式来实现，而 git pull rebase 不是我认为的最佳选择。不过，分支自动变基是一个很棒的功能，我已经在几个仓库中添加了它。非常好的提示！ :) - Blake Chambers

Answer 2

随着时间的推移，我发现我最喜欢的解决方案是：

git checkout topic
# make [n] commits
git rebase -i HEAD~[n] #clean up time
git checkout master
git pull --rebase
git checkout topic
git rebase master
git checkout master
git merge topic
git push origin

- Blake Chambers

---

最后一次合并是必要的吗？我可以想象在图表上看到所有工作分支的新奇之处，但是代码已经集成到主干中，如果它不成为真正的分支，我认为扔掉工作代码并不是不合理的。否则，在我看来，这个答案是完美的。 - Evan Plaice

Answer 3

你可以直接将分支变基到最新的主分支。

git checkout topic_1
git rebase refs/remotes/origin/master

这样做可以避免需要拉取（至少在您的特性分支到期之前）。我们的流程使用GitHub pull请求，所以我从不需要在本地执行此操作。

- Andy V

Answer 4

对于我们的团队，我们建立了一个非常有效的工作流程，完全不使用rebase。

我们将工作拆分为Jira任务，每个任务通常需要1-2天的工作量。每个开发人员为每个任务创建一个分支，并在该分支上进行工作。准备好后，将其推送到中央服务器。

中央服务器由Hudson CI服务器监视，该服务器拉取更改、合并所有更新的分支、重新构建软件、运行测试并将所有内容推送到中央主git存储库。

然后我们将其从中央主存储库拉回到我们的存储库。我们定期（即每隔几天）将我们的工作分支与中央主分支合并，以保持它们“接近”。

由于没有人在“合并”机器上工作，除CI服务器外没有其他人触摸主分支，因此我们很少遇到合并问题（大约1-2％的提交）。这些问题可以通过清理工作区域来快速解决。我们发现，通过保持分支短小并在推送之前与远程主分支合并，我们可以避免大部分问题。

我还发现，合并比rebase更加稳健，并且需要更少的重复工作。

- Peter Tillemans

---

这对于开发速度较慢的情况非常好，但我们的环境要求某些提交每晚上线，而其他提交则等待更大的发布。我想解决这个问题的一种方法是在远程仓库上设置夜间和发布分支...但如果不完全遵守，这可能会导致更多的合并提交。虽然我也认为合并更加“健壮”，但我们的团队能够解决git-rebase并处理问题。对我来说，拥有更可读的提交历史同样重要。 - Blake Chambers

个人认为合并的分支在历史记录中看起来很丑/混乱，所以我总是将临时/开发分支变基到远程源。不过，我发现你们的团队已经有效地实施了一个仅合并计划，并取得了可衡量的好处。你们是否会在常规拉取计划中进行变基，以使事情更加“接近”中央主分支？“清理工作区”包括哪些内容？在与中央代码库合并之前，你们是否会拉取和变基以检查冲突？ - Evan Plaice

@EvanPlaice 清理工作区会在 Jenkins 上擦除工作目录。下次进行新的克隆时需要重新开始。 - Peter Tillemans