我们有项目(PHP 应用程序)，但每个客户的安装情况各不相同，有时很少，有时更多。尽管如此，大部分源代码还是很常见的。我们将特定安装作为并行分支管理到 master 分支，我们需要将更改从 master 转移到其他分支。同样的情况在 Git: how maintain (mostly) parallel branches with only a few difference? 中得到解决投票最多的解决方案是以这种方式在分支之间传输更改:
git pull
git checkout local
git rebase master
如解决方案中所述，它会在 rebase 后创建非快进推送，我发现这是非常不愉快的并发症。我的问题是 - 为什么不这样做:
git pull
git checkout local
git merge master
最佳答案
The idea is you use one common branch, and two (or as many as you need) customer specific branches. All common changes go into the master, and each customer branch gets changes that pertain only to that customer. Periodically (when master is considered to be at a stable point), you'll merge changes from master into the customer branch (
git checkout custA; git merge master). This brings in newer "common" code into the customer branch. You will never merge the other way -- that would pollute master with customer-specific code.When you make a delivery to customer A, you checkout the "custA" branch and send that. And of course similarly for other customers.
Now let's say you acquire a new customer, "C", and a bit later find a feature that customers A and C want, but B doesn't. You create (aka "fork") a branch off of master (
git checkout -b AC_feature master), code/test it, making commits as you go, and then merge it into A and C (git checkout A; git merge AC_feature and similarly for customer C). You do not code it in A and then rely on merging A into C, because that would get all of A into C.If, sometime later, you find a minor bug in that feature, you make the change in the same branch (
git checkout AC_feature; edit/test/commit), and then you merge it into custA and custC as above.
来源: Gitolite 的开发者 Sitaram Chamarty 撰写的这些令人耳目一新、清晰且有用的文章部分是在 Junio Hamano(Linus Torvalds 在维护方面的合作伙伴)的直接投入下撰写的混帐)。
维护并行客户分支:
http://gitolite.com/archived/special-branches.html
关于“修复”通用和客户分支的后续文章:
关于Git:如何维护永久并行分支，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2170179/