我可以发送分支B的拉取请求吗?会有副作用吗?
让我们画一个快速的画面
X --- X --- X --- X <--(master)
\
A1 -- A2 <--(A)
\
B1 -- B2 -- B3 <--(B)
我承担A
公关依然突出,所以A1
是master
和B
之间的差异。如果B
中没有任何内容依赖于A1
,那么这在概念上并不好;您不希望B
的批准/合并取决于接受/潜在的A1
过早发布的变更。
现在,如果公关A
获得批准,那么合并后A1
不再是一个区别;你可以说“没有伤害,没有犯规”;但如果独立分支机构独立于master
之后,仍然最好。
我可以改为在最后一次主合并时重新提交提交,并将提交重命名为分支B上更改的名称?这是否也会删除我发送拉请求的分支A上的提交?
以第一部分为准:rebasing不会删除回购的提交;这是一个(看似普遍的)误解。因为A1
可从分支A
到达,所以它不会受到B
的重设影响。 但是,在重新绑定时应该小心,以避免创建一个重复的提交,因为这会破坏rebase的目的。
git rebase --onto master A B
应该给你
B1' -- B2' -- B3' <--(B)
/
X --- X --- X --- X <--(master)
\
A1 -- A2 <--(A)
\
B1 --- B2 --- B3
(请注意,我已经展示了B1
,B2
,这对于图清晰度B3
加强这一基础重建不会删除提交点。由于没有如果你不知道如何寻找它们,你就不会看到它们,并且它们将被排除在push
之外,最终它们可能会被垃圾收集,但是在rebase之后,在你的本地回购你可以做一些像0123一样的东西请注意,如果B
曾经被推送过,这可能会给其他开发者带来问题(因为虽然没有提交从repo中移除,但是这确实会提交曾经是的提交B
可达不再可达来自B
,这并不好。
请参阅git rebase
文档中的“从上游rebase”恢复,如果这看起来没有问题,那么您可以rebase。请记住,您需要重新测试已重建的B
,因为它的树处于一个独特的新状态。 (IMO的最佳做法是重新测试中间提交。)
如果我在接受请求之前需要对分支A进行其他更改,我还可以重新分割/压扁分支A的提交吗?影响分支B?
这个问题至少有几个变化。
如果你有不重建基础B
从A
远,那么任何垫底的操作,将改写或更换A1
可能让你在一个意想不到的状态,因为B
仍然将指向通过A1
(不A1'
这是在重订创建,或在南瓜的情况下为A1A2
,或其他)。
如果有重建基础B
远离A
,那么你可以做任何你喜欢A
没有进一步影响B
。再次,只要意识到重写已推动历史的风险。