Git：如何维护永久并行分支

Posted 2023-02-23

【中文标题】Git：如何维护永久并行分支

【英文标题】：Git: how to maintain permanent parallel branches

【发布时间】：2011-01-11 07:52:01

【问题描述】：

我们有项目（php 应用程序），但每个客户端的安装情况各不相同，有时很少，有时更多。尽管如此，大部分源代码还是很常见的。我们将特定安装作为并行分支管理到主分支，我们需要将更改从主分支转移到其他分支。 Git: how maintain (mostly) parallel branches with only a few difference? 解决了同样的情况。投票最多的解决方案是在分支之间以这种方式传输更改：

git pull
git checkout local
git rebase master

正如解决方案中提到的，它在变基后会创建非快进推送，我觉得这很令人不快。我的问题是 - 为什么不这样做：

git pull
git checkout local
git merge master

【问题讨论】：

或者你的意思是这个？ ***.com/questions/2850369/…

【参考方案1】：

这个想法是您使用一个公共分支，以及两个（或与您一样多） 需要）客户特定的分支机构。所有常见的变化都进入 master，并且每个客户分支都会获得仅与 那个客户。定期（当主人被认为是在 稳定点），您会将更改从 master 合并到 customer 分支（git checkout custA; git merge master）。这带来了更新 “通用”代码进入客户分支。你永远不会合并另一个 方式——这会用客户特定的代码污染 master。

当您向客户 A 发货时，您会结帐“custA” 分支并发送。当然对于其他客户也是如此。

现在假设您获得了一个新客户“C”，稍后又找到了一个 客户 A 和 C 想要但 B 不想要的功能。你创造（又名 "fork") master 的一个分支 (git checkout -b AC_feature master), 对其进行编码/测试，随时提交，然后将其合并到 A 和 C (git checkout A; git merge AC_feature and similarly for customer C)。 您不要在 A 中对其进行编码，然后依靠将 A 合并到 C 中，因为 这将使所有的 A 变成 C。

如果稍后您在该功能中发现了一个小错误，您可以制作 在同一分支中更改（git checkout AC_feature; edit/test/commit）， 然后你把它合并到上面的 custA 和 custC 中。

来源： 这些令人耳目一新的清晰和有用的文章来自 Gitolite 的开发者 - Sitaram Chamarty，部分内容来自 Junio Hamano（Linus Torvalds 的合作伙伴，负责维护吉特）。

维护平行客户分支：

http://gitolite.com/archived/special-branches.html

关于“修复”公共和客户分支的后续文章：

http://gitolite.com/archived/special-branch-fixups.html

【参考方案2】：

这真的取决于你想对分支做什么。是的，如果你在本地变基，它会在变基后创建非快进推送。另一方面，您将继续维护一组不同的更改，并且您的分支上的更改将是一组更改，就好像它们是由最新的 MASTER 负责人所做的一样。

相反，将 master 合并到 local 将使 local 与 master 同步前进，并将记录发生的历史。如果您需要能够重建本地过去的状态，那么您会想要这样做。历史永远不会改变。但是，您将需要处理更复杂的历史。

【讨论】：

在我的团队中，我们（几乎总是）对任何将要合并的分支进行 rebase。尽可能频繁地使 rebase 更容易。当您回来时，这简化了对变更历史的理解。当我们必须并行维护两个分支并且我们同时发布两个分支（维护和开发版本，比如）时——那么我们就不能再变基了，这太令人困惑了。我们开始合并。

【参考方案3】：

Greg's answer 你的另一个问题似乎将不同的分支视为特定安装的本地，而不是推送到其他存储库（强调添加）：

如果它是系统本地，则将其提交到该系统的“本地”分支，否则将其提交到“master”并将其推送到公共存储库。

您几乎总是希望快进推送到共享存储库中的分支。 git rebase documentation 解释了如何从上游 rebase 中恢复（即，git rebase 然后git push -f），这对任何参与的人来说都不好玩。

有关另一种方法，请参阅Never merging back：

在某些有效的情况下，您曾经为了永不合并而进行了分叉，但通常您应该非常努力地将此类分叉上的更改保持在最低限度。

作者继续讨论同一存储库中各种客户版本的分支策略。