Question

我有一个关于git分支协议的问题。我开始对git命令越来越熟悉了，但我对这个过程还是比较新的。

我正在与另一个人一起开展一个基于git的项目。我们正在添加一个大型功能，因此我们将工作分为“Branch_1”。另一个开发人员开始在Branch_1的分支中使用一个名为Branch_2的附加组件。另一个开发者在Branch_2上做了一些工作，然后暂时继续其他任务。我需要继续并扩展他在Branch_2中所做的更改，因此我基于Branch_2创建了Branch_3。

图1

Branch_1
  |_______> Branch_2  (other developer working on)
                |________> Branch_3  (I'm working on)

当我在使用Branch_3时，我意识到需要成为所有分支的一部分的错误FIX，我需要FIX才能继续开发Branch_3。（另外，如果放弃Branch_3工作，则无论如何，FIX都必须在所有其他分支中。）

所以我的想法是结帐Branch_1，对FIX进行更改，结帐Branch_2，在Branch_1中合并，然后结帐Branch_3并合并来自Branch_2的更改。见下图2。

图2

git checkout Branch_1
# make my changes
git pull origin Branch_1  # to pull in any other changes
git push origin Branch_1 

git checkout Branch_2
git pull origin Branch_2    # to pull in any other changes
git merge --no-ff Branch_1  # merge in branch 1 
git push origin Branch_2    # push to the remote repository  

git checkout Branch_3
git pull origin Branch_3    # to pull in any other changes
git merge --no-ff Branch_2  # merge in branch 2
git push origin Brach_3     # push to the remote repository

但是，我想知道在这种情况下的几件事情：

有很多步骤要做。一段时间后会耗费时间。如果我创建一个基于Branch_3的Branch_4和Branch_4的Branch_5，则涉及更多步骤。
为了在完成FIX之后继续进行Branch_3工作，我基本上必须向我的同事Branch_2做出承诺，他可能没有意识到。
对于更复杂的设置，我可能不会重新考虑从什么分支。我可以将我的错误修复到Branch_1并将其合并到我的同事Branch_2中，但也许我的同事通过分支某些中间分支（如Branch_1a）创建了Branch_2。 FIX不会以正确的顺序正确合并到Branch_1a中。

我主要想知道别人会如何接近类似的情况。当进行需要在分支层次结构中的更改时，这是正确的思维方式吗？

Answer 1

不幸的是，是的。如果要将修补程序集成到所有分支中，则必须将其修改为一次并将其合并到任何位置或多次修复（由cherry-pick支持）。当担心branch2并且你正在提交你的同事没有意识到的提交时，只需省略branch2。当你的同事最终将它合并回branch1时（这应该是理想的结果，因为成功使用分支机构的秘密实际上又合并了），修复程序将自动合并。如果他迫切需要修复，你可以简单地通知他，他可以自己合并。

git flow分支依赖

1 个答案: