在工作中我们经常使用Git但是最近我们在尝试在分支之间进行合并时遇到了很多麻烦。
我们有两个开发团队，我负责合并每个团队的工作。当我们在应用程序的不同部分工作时，我想知道合并时是否存在正常流程。
这就是为什么我aske：我们应该如何合并分支：将分支A合并到B或将分支B合并到A？
我们不是分公司主人。我们把它保持稳定。有分支机构：“ A队”和“ B队”。
团队A在某些控制器中工作，而团队B在某些视图中工作。当共享代码的时间到来时，我合并了分支。
我所做的是将B队合并到A队，但我们有有合并冲突，但是，我们已经能够解决它们。
为了顺利工作并避免合并冲突（有时难以解决）我试图找出一种更好的方式在分支机构之间工作，但我没有想到任何事情。
答案 0 :(得分：1)
根据我的经验，将贡献从一个分支流向另一个分支以及从存储库流向存储库是最有效的。虽然git可以支持任何通常会导致混淆的方向的合并。
为git push“上游”和git pull ed“下游”更改定义明确的工作流程。例如，开发人员可能会：
pull分支的development以获取最新版本。push这些更改通过合并回development分支并推送或通过将其功能分支（或补丁）推送到拉取请求，代码审查流程或其他远程集成器来提升。 类似地，开发人员完成的工作被上游推送到部署分支，发布版本或存储库的其他更稳定的分支。
这可以产生clean history of topic branches。通常我喜欢确保每个分支的作者负责处理合并。在大多数情况下，他们最有能力解决任何冲突，或者他们还没有公布他们的分支，这样他们就可以将他们的承诺变更并重写为不会发生冲突的快速变更。
不要害怕创造更多短命的分支。如果飞行中的多个要素需要进行少量更改，请在历史记录中找到它们的共同祖先，从那里进行分支，应用更改，并允许两个要素分支将其引入其工作中。
在某些情况下，合并冲突是不可避免的。如果您有两个公共分支（任何人都可以从中分支，因此您不想重写历史记录），那么我将从上游分支中获取，解决下游分支上的冲突，并始终将无冲突合并推回上游。因此，解决冲突的责任再次落在为更具权威性的“上游”分支做出新的冲突变革的人身上。