我们有项目（PHP 应用程序），但每个客户端的安装情况各不相同，有时很少，有时更多。尽管如此，大部分源代码还是很常见的。我们将特定安装作为并行分支管理到主分支，我们需要将更改从主分支转移到其他分支。同样的情况在Git 中得到了解决：如何维护（大部分）并行分支，只有很少的区别？投票最多的解决方案是以这种方式在分支之间传输更改：
git pull
git checkout local
git rebase master
正如解决方案中提到的，它在变基后会创建非快进推送，我发现这很令人不快。我的问题是 - 为什么不这样做：
git pull
git checkout local
git merge master
这个想法是您使用一个公共分支和两个（或您需要的任意多个）客户特定的分支。所有常见的更改都进入主服务器，每个客户分支都会获得仅与该客户相关的更改。定期（当 master 被认为处于稳定点时），您会将 master 的更改合并到客户分支 (
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 维护 Git 的合作伙伴）直接输入。
维护并行客户分支：
http://gitolite.com/archived/special-branches.html
关于“修复”公共和客户分支的后续文章：
这真的取决于你想对分支做什么。是的，如果你在本地变基，它会在变基后创建非快进推送。另一方面，您将继续维护一组不同的更改，并且您的分支上的更改将是一组更改，就好像它们是由最新的 MASTER 负责人所做的一样。
相反，将 master 合并到 local 将使 local 与 master 同步前进，并将记录发生的历史。如果您需要能够重建本地过去的状态，那么您会想要这样做。历史永远不会改变。但是，您将需要处理更复杂的历史。
格雷格对您的其他问题的回答似乎将不同的分支视为特定安装的本地，而不是推送到其他存储库（强调添加）：
如果它是系统本地的，则将其提交到该系统的“本地”分支，否则将其提交到“主”并将其推送到公共存储库。
您几乎总是希望快进推送到共享存储库中的分支。该git rebase文档解释了如何从上游 rebase（即git rebasethen ）中恢复，git push -f这对任何参与的人来说都不好玩。
对于另一种方法，请参阅从不合并：
在某些有效的情况下，您曾经为了永远不会合并回来而分叉，但一般来说，您应该非常努力地将此类分叉上的更改保持在最低限度。
作者继续讨论同一存储库中各种客户版本的分支策略。