在工作中，我们经常使用 Git，但最近在尝试在分支之间进行合并时遇到了很多麻烦。
我们有两个开发团队，我负责合并每个团队所做的工作。当我们在应用程序的不同部分工作时，我想知道合并时是否有正常的流程。
这就是我问的原因：我们应该如何合并分支：将分支 A 合并到 B 或将分支 B 合并到 A？
我们没有在分支 master 上工作。我们让它保持稳定。有分支：“ Team A ”和“ Team B ”。
团队 A 在某些控制器中工作，而团队 B 在某些视图中工作。当共享代码的时间到来时，我会合并分支。
我所做的是将团队 B 合并到团队 A，但是我们有合并冲突，但是，我们已经能够解决它们。
为了顺利工作并避免合并冲突（有时很难解决），我试图找出一种更好的在分支之间工作的方法，但我什么都没想到。
以我的经验，让贡献从一个分支到另一个分支、从一个存储库到另一个存储库以单一方向流动是最有效的。虽然 git 可以支持任何通常会导致混乱的方向的合并。
git push为“上游”和git pull“下游”的变更定义清晰的工作流程。例如，开发人员可能：
pull从development分支获取最新版本。push这些更改要么合并回development分支并推送，要么将其功能分支（或补丁）推送到拉取请求、代码审查流程或其他远程集成器。类似地，开发人员所做的工作被推送到上游的部署分支、发布版本或存储库的其他更稳定的分支。
这可以产生一个干净的主题分支历史。通常我喜欢确保每个分支的作者负责处理合并。在大多数情况下，他们最有能力解决任何冲突，或者他们还没有公开他们的分支，因此他们可以重新定位并将他们的提交重写为不冲突的快进更改。
不要害怕创建更多短命的分支。如果正在运行的多个特性需要一个小的更改，则在历史中找到它们的共同祖先，从那里分支，应用更改，并允许两个特性分支将其拉入他们的工作中。
在某些情况下，合并冲突是不可避免的。如果您有两个冲突的公共分支（任何人都可能从中拉出的分支，因此您不想重写历史记录），那么我将从上游分支拉出，解决下游分支上的冲突，并始终将无冲突合并推回上游。因此，解决冲突的责任再次落在为更权威的“上游”分支贡献新的冲突更改的人身上。