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

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

是的，一旦将功能分支合并回稳定版，您的历史记录就会变得有点混乱。但是只要你从git pulls中避免每日微合并的混乱（改为使用git pull --rebase），你将能够理解实际有意义的合并。

如果确实希望避免将新功能从稳定版合并到功能分支中，但只是想要修复错误，则可以在功能分支中挑选错误修正。然而，这可能是很多工作，因为它要求你始终处于稳定发生的一切事情之上。使用git cherry来帮助您：

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

Answer 2

如果团队规模足够小，并且由经验丰富的git用户组成，则可以进行重新定位。

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

一切都应该没问题，但是如果您忘记与已更改的功能分支同步，请说您已在旧功能分支C之上提交oldFB，该分支已重新定位到oldFB'：

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合并到您的长期功能分支中。这是相当安全的，但也可以合并你不感兴趣的许多变化，并使事情变得复杂。

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

如何维护长时间运行的git分支

3 个答案: