如何维护长期运行的 git 分支

Question

理想情况下，Git 分支应该持续很短的时间，可能是 1-2 天。然后它被合并到一些主线中。

但在某些情况下，当我们处理非常大的功能时，我们会维护分支。当 2 或 3 个人在专有代码区域中分别开发这些非常大的功能时，维护它们就变得有点困难。

在进入稳定分支的热修复中，我们需要使这 2-3 个大分支与稳定分支保持同步。所以我们最终经常这样做。

(in feature-branch1) $ git merge stable
(in feature-branch2) $ git merge stable
(in feature-branch3) $ git merge stable

有没有正确的方法来维护 git 中这些长期运行的分支？通过执行上述操作，git 历史记录有点混乱。这些功能分支大多被推送到远程，这意味着我们看不到rebase作为一个选项。我还能做什么？

Answer 1

时不时地合并到稳定分支实际上是保持功能分支最新的最简单也是最好的事情。我不建议重新设置基准，因为可能有更多的人同时处理该功能，并且每次强制推送时他们都必须重置本地分支。即使只有一个人在功能分支上工作，合并也会更好，因为它清楚地显示了您从稳定分支引入修复的历史点。

是的，一旦将功能分支合并回稳定分支，您的历史记录可能会看起来有点混乱。但是，只要您避免 git pull 中日常微合并的混乱（使用 git pull --rebase 代替），您将能够欣赏到真正有意义的合并。

如果您确实想要避免将新功能从稳定版合并到功能分支中，但只想修复错误，则可以将错误修复挑选到功能分支中。然而，这可能需要大量工作，因为它要求您始终掌握稳定中发生的所有事情。使用 gitcherry 来帮助你：

# commits from "stable" that are not present in
# the current branch will be prefixed with "+"
git cherry HEAD stable

Answer 2

如果团队足够小并且由相当有经验的 git 用户组成，则可以进行变基。

例如，您可以做的是同意功能分支每天晚上都将基于稳定版本。或者，您可以在将功能分支变基为稳定版本时发送电子邮件。

一切都应该没问题，但是
如果您忘记与重新定位的功能分支同步，假设您在旧功能分支 oldFB 之上提交了 C，该分支已重新定位为 oldFB'< /code>：

S1 - oldFB - C <-- feature-branch
    \
     S2 - oldFB' - D <-- origin/feature-branch

仍然可以通过运行以下命令来重新设置提交 C：

git checkout feature-branch
git rebase --onto origin/feature-branch oldFB C

请注意，您必须手动查找上图中名为 oldFB 的提交。

Answer 3

最好的选择是仅将所需的小错误修复/功能分支合并到长期存在的功能分支中。这样你就只能得到你需要的东西。请注意，如果您让这些分支存活足够长的时间，它们最终可能会与主分支完全不同步。有时，您可能希望从长期存在的功能分支创建一个临时分支，并将 master 合并到其中只是为了进行健全性检查 - 查看是否存在冲突，查看 master 中的更改是否会破坏该功能，等等在。

接下来最好的办法是定期将 master 合并到长期存在的功能分支中。这是相当安全的，但也可能会合并许多您不感兴趣的更改，并使事情变得复杂。

我不建议定期重新建立 master 基础。这使得每个人都很难保持同步，也使得在功能分支上维护复杂的历史记录（合并）变得更加困难，并使冲突解决变得更加痛苦。