我们有项目（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
【问题讨论】：
这个想法是您使用一个公共分支，以及两个（或与您一样多） 需要）客户特定的分支机构。所有常见的变化都进入 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
关于“修复”公共和客户分支的后续文章：
【讨论】：
这真的取决于你想对分支做什么。是的，如果你在本地变基，它会在变基后创建非快进推送。另一方面，您将继续维护一组不同的更改，并且您的分支上的更改将是一组更改，就好像它们是由最新的 MASTER 负责人所做的一样。
相反，将 master 合并到 local 将使 local 与 master 同步前进，并将记录发生的历史。如果您需要能够重建本地过去的状态，那么您会想要这样做。历史永远不会改变。但是，您将需要处理更复杂的历史。
【讨论】：
Greg's answer 你的另一个问题似乎将不同的分支视为特定安装的本地，而不是推送到其他存储库（强调添加）：
如果它是系统本地，则将其提交到该系统的“本地”分支，否则将其提交到“master”并将其推送到公共存储库。
您几乎总是希望快进推送到共享存储库中的分支。 git rebase documentation 解释了如何从上游 rebase 中恢复（即，git rebase 然后git push -f），这对任何参与的人来说都不好玩。
有关另一种方法，请参阅Never merging back：
在某些有效的情况下，您曾经为了永不合并而进行了分叉，但通常您应该非常努力地将此类分叉上的更改保持在最低限度。
作者继续讨论同一存储库中各种客户版本的分支策略。
【讨论】：