我们有项目(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
答案 0 :(得分:22)
这个想法是你使用一个共同的分支,两个(或者和你一样多) 需要)客户特定分支机构。所有常见的变化都会进入 master,每个客户分支获得仅与之相关的更改 那个客户。定期(当主人被认为是在 稳定点),您将把更改从master合并到客户中 分支(
git checkout custA; git merge master
)。这带来了新的 “常见”代码进入客户分支。你永远不会合并另一个 方式 - 这将使用客户特定的代码污染主人。当您向客户A交货时,您会结帐“custA” 分支并发送。当然,对其他客户也是如此。
现在让我们说你获得了一个新客户“C”,稍后发现了一个 客户A和C想要的功能,但B不需要。你创造(又名 “fork”)主人(
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的维护合作伙伴)的直接意见GIT)。
维护并行客户分支:
http://gitolite.com/archived/special-branches.html
关于“修复”公共和客户分支的后续文章:
答案 1 :(得分:6)
这实际上取决于你想对分支做什么。是的,如果您在本地重新定位,它将在重新定位后创建非快进推送。另一方面,你将继续保持一系列不同的变化,你的分支上的内容将是一系列的变化,如果他们已经进入最新的主要领域。
将主人与地方合并,将使当地人与主人及时前进,并将记录历史。如果你需要能够重建过去的本地状态,那么你会想要这样做。历史永远不会改变。但是,你将有一个更复杂的历史来处理。
答案 2 :(得分:2)
Greg's answer对你的另一个问题似乎是将不同的分支视为特定安装的本地保留,而不是推送到其他回购(强调添加):
如果系统的本地,则将其提交给该系统的“本地”分支,否则将其提交为“master”并将其推送到公共存储库。
您几乎总是希望快速推送到共享存储库中的分支。 git rebase
documentation解释了如何从上游rebase(即。,git rebase
然后git push -f
)中恢复,对任何参与者来说都没有任何乐趣。
有关其他方法,请参阅Never merging back:
有些情况下,你曾经打算永远不要合并,但一般情况下你应该非常努力地将这种分支上的变化保持在最低限度。
作者继续讨论同一存储库中各种客户版本的分支策略。