我正在处理从主分支的分支( feature1 )。 Feature1分支有很多提交,并且已经做了很多工作。
----------- Master
\---------------- Feature1
同事需要做一些与分支 feature1 密切相关的工作。
同事应该从主人或 feature1 分支出来吗?
假设同事从 feature1 分支出来并创建 feature1_addon ,并且这两个分支之间的工作继续并行。这项工作持续数周并行。
----------- Master
\---------------- Feature1
\----Feature1_addon
最终这两个分支(feature1& feature1_addon)必须合并为master,如何在不丢失任何工作的情况下完成?
答案 0 :(得分:0)
feature1_addon分支可以从feature1创建。 $ git checkout -b feacture1_addon feature1
您的同事可以继续在插件分支上工作。 你可以继续使用feature1。
实现功能和插件后,将两个分支代码推送到原点。
$ git push origin feature1
$ git push origin feature1_addon
稍后你们中的任何一个人都可以将这两个分支机构提取到本地。
$ git fetch&& git checkout"分支在本地"
创建在本地创建分支后
结帐主人
$ git checkout master
$ git merge feature1
$ git merge feature1_addon
在合并任何冲突的同时,解决冲突并提交代码。
通过这个过程,不会丢失任何工作。
答案 1 :(得分:0)
技术上的答案是git在哪里制作分支并不重要。您可以通过任何提交(从任何分支可到达)来创建它们,从而可以访问您需要修改的代码版本。每个分支可以或多或少地独立地合并到任何其他分支。
"更多或更少"因为许多人对提交和分支之间的关系存在误解,导致他们认为合并不是独立的,所以是独立的。考虑:
X -- x -- x -- x -- x <--(master)
\
A -- B -- C -- o -- o <--(feature1)
\
D -- E -- F <--(feature1_addon)
现在您可以将feature1
合并到master
,您可能确切地知道会发生什么。
即使您尚未将feature1
合并到master
,也可以将feature1_addon
合并到master
。但如果你这样做,它会带来A
,B
,C
,D
,E
和F
- 不仅仅是{{ 1}}至D
- 因为F
至A
在C
的历史记录中,但尚未列入{{1}的历史记录中}}。因此,尽管您可能会将feature1_addon
通过master
视为A
分支&#34;的一部分,但是git将它们视为&#34;可以从{{1 }}&#34;和&#34;可以从C
&#34;到达,不再属于另一个。
无论合并的顺序或时间如何,您都不应该担心失去工作。
你应该关注合并冲突,但是,出于这个原因你的分支模型(创建可能长期存在的分支,它们不会相互影响,直到它们最终合并在一起)通常不被认为是最佳实践。
所以非技术性的答案是,虽然您可以根据需要进行分支和合并,但您可能想要更多地考虑它。
究竟哪种分支策略最适合您的情况不是我能确定的。我发现gitflow非常有用,但如果只有你们中的两个,它会有点重量级,并且它假设一个敏捷的工作流程(意味着分支代表很少合并的小工作单元)。 / p>
如果您希望拥有长期的开发线,那么至少应该考虑定期将它们相互合并,这样它们就不会分歧太多。然后,冲突将以可管理的剂量合并,并且与单独开发每个线程相比,将产生更少的冲突。
答案 2 :(得分:0)
首先,同事应该从feature1
分支分支出来,因为他/她需要完成与feature1
相关的工作,而feature1
分支不合并现在进入master
分支。
是的,feature1
和feature1_addon
分支最终将合并到master
分支中。无论合并的顺序是什么,两个分支的作品都不会丢失。
如果首先合并feature1
分支:
…---A---B---C----------------J mater
\ /
D---…---F---…---G feature1
\
H---…---I feature1_addon
如果首先合并feature1_addon
分支:
…---A---B---C---------------------K mater
\ /
\ H---…---I feature1_addon
\ /
D---…---F---…---G feature1
当您稍后进行第二次合并时,如果没有冲突(您和同事没有更改相同的文件),您可以直接合并。否则,您可以在合并期间解决合并冲突(将您和您的同事之间的工作结合起来)。