因此，我试图了解Git如何处理某些流程以及一些已使用的实践。
假设我们有一个Git存储库，其中包含一个名为master的分支。我们还有两个master同时创建的分支。我们将它们称为branch_one和branch_two。
branch_one已针对特定功能完成工作。我目前正在branch_two上进行开发。为了便于讨论，我们假设我无法将branch_one合并到master，因为它正在等待其他开发人员的批准。
问题出在这里
我需要branch_one的所有工作才能继续进行branch_two。
这是我当前的流量：
1）将branch_one合并到branch_two中。
2）在branch_two上工作。
3）在提交拉取请求之前，以branch_two为基础master重新定位。
嗯。重新定位在30多个补丁程序上存在冲突。我认为这是因为合并（步骤1）更改了branch_two的开头。我可能假设不正确。
很明显，我希望避免在版本控制过程中进行大量的冲突解决步骤。
所以我的问题：
有没有更好的方法来处理这种类型的过程，其中一个功能分支需要从另一个功能分支进行更改，而其中不包含大量冲突？
答案 0 :(得分：1)
您需要一个由主HEAD制成的集成分支：
如果branch1在其验证的上下文中需要其他工作，请再次合并合并的新branch1提交。
在某个时候，branch1将合并到master。
然后，每当您要验证branch2时，请首先将其重新建立在更新的集成分支之上。然后将其合并到集成中（使用--no-ff：无快进合并）。
最后，准备好将branch2合并到master。那里没有冲突。
有关此工作流程的更多信息，see gitworkflow（远胜过Gitflow）
答案 1 :(得分：0)
您正在遇到GIT的一个常见陷阱。解决方案始终是，请提前考虑。在您的方案中，提前知道是否需要一个分支的功能将使您能够以一种避免出现此问题的方式进行分支：
从master分支创建分支，这将是史诗般的分支
git checkout -b epicBranch
从branch_one创建branch_two和epicBranch
git checkout -b branch_one
git checkout -b branch_two
一旦您需要PR branch_one中的功能，并将branch_one合并到epicBranch中
然后将epicBranch合并到branch_two
git checkout branch_two
git merge epicBranch
现在您有了branch_one中branch_two的更改，而没有关闭分支的开销。
您将拥有提交历史记录，并且在合并或重新定级时不会遇到任何问题。
您还可以通过选择所需的功能提交到自己的分支（可以在分支之间共享）来减轻很多麻烦。