如果我的注释或术语错误,我道歉。我已经在我的个人项目中使用git
一段时间了,并且不必处理复杂的合并场景。我们开始在工作中使用它,并且正在遇到更复杂的场景。我仍然是git
新手,所以我想找出采摘樱桃的最佳做法。
情景一
在这里,我们有一个master
,fix
和develop
分支。在我们对fix
进行分支后,我们将版本号更新为1.0.1
。我们对develop
执行了相同操作,并将版本号更改为1.1.0
。
让我们说修复F1
,F2
和F3
已提交给fix
。其中,我们关注修复F2
和F3
,但不关心F1
,因为它是对已弃用功能的更改。我们也不关心版本号的更改为1.0.1
。
现在,我们可以将这些更改合并回master
fix
,而不会出现问题。但是,如果我想将这些更改合并到develop
,该怎么办?现在我正在使用git cherry-pick
来挑选F1
和F2
。此外,对于大量的提交,我使用一系列提交樱桃挑选,这似乎工作正常。这是最好的做事方式吗?
这让我想到了关于git cherry-pick
的下一个场景:
场景2
如果术语不正确,或者我的图表没有意义,我再次道歉。这是我能描述的最好的。
所以在这种情况下,除了上面的分支之外,我们还有一个hotfix
分支。我们假设有人将修补程序H1
和H2
提交到hotfix
,然后将这些更改合并到master
,fix
和{{1} }}。
大约在同一时间,其他人将develop
,F1
和F2
修复了F3
分支,但是以交错的方式({{1}在fix
之前提交了F1
,H1
之前提交了H2
。现在,F3
工作的人想要同步,所以他运行fix
,这使得这些变化有序。我们也假设没有冲突。
现在,让我们说这个人想要将他的所有修正合并到git pull
。在这种情况下,如果他在develop
的提交开始时使用git cherry-pick
一系列提交,并在F1
的提交结束时会发生什么?那些合并会被忽略吗?据我所知,你无法挑选合并(因为你需要指定主线)。那么在这种情况下,F3
会忽略那些合并吗?
此外,为了不必处理这种情况,总是 git cherry-pick
而不是rebase
更好,以便您的更改在之后应用?这样你可以指定提交范围,它不会包含合并。
谢谢,如果我的问题很愚蠢,或者没有任何意义,我道歉。
答案 0 :(得分:5)
情景一
现在我正在使用git cherry-pick来挑选F1和F2。
你的意思是F2和F3,对吗?基本上就是这样:
git cherry-pick F1..F3
如果是这样,那没关系。或者,您可以创建一个临时分支和rebase:
git checkout -b for-develop F3
git rebase --onto develop F1
git checkout develop
git merge for-develop
您实际上并不需要创建分支,因为您可以直接使用SHA-1,或者使用reflog,但是,为了简化起见,我使用了分支。
请注意git rebase
基本上是一个美化的樱桃选择,所以在一天结束时它会做同样的事情。
情景二
如果他在提交F1时使用git cherry-pick并提交一系列提交,并以F3提交结束,会发生什么?那些合并会被忽略吗?
你可以告诉cherry-pick忽略与--no-merges的合并,因此合并提交本身将被忽略(M1,M2),但不会被提交本身(H1,H2)。因为你已经拥有了“开发”这些产品。这可能会产生一些问题。如果git cherry-pick --skip
已实施,那就不会有问题(我已发送补丁但从未应用过补丁)。
但你可以告诉cherry-pick忽略已经存在的提交:
git cherry-pick --no-merges --right-only --cherry-pick develop...F3
您可以尝试git log
使用相同的参数来查看哪些提交会被挑选出来。或者您可以自己指定它们:
git cherry-pick F2 F3
最后,您可以使用git rebase
:
git checkout -b for-develop F3
git rebase --onto develop F1
git checkout develop
git merge for-develop
请注意,git rebase
将与上面提到的cherry-pick命令相同,并且您可以在两种方案中使用相同的git rebase
命令。您也可以在两种方案中使用相同的git cherry-pick
命令(使用--no-merges --right-only --cherry-pick)。如果存在冲突,您可能遇到一些麻烦,特别是如果提交变空(很可能已经应用),因为没有git cherry-pick --skip
。
使用git rebase
通常更安全,因为这是每个人都使用的东西,但如果您觉得有冒险精神,可以尝试git cherry-pick
一段时间,看看它是如何转变的进行。
答案 1 :(得分:1)
情景1很好;事实上,樱桃挑选似乎是去那里的最好方式。
情景2更成问题。我还没有尝试过,但我怀疑git会对尝试樱桃选择合并提交有所了解。在这种情况下,我认为变基是最好的选择。在某些情况下,合并提交是很棒的事情,但在这种交错的情况下,它们会妨碍并且还会使修改图形变得非常复杂。 (当然,它就是这样,但是rebase可以让你逃脱。)