2017-05-04 100 views
0
  1. 我创建了一个分支并发送这些更改拉入请求,我们称之为分支A.
  2. 然后,我创建了一个支路B,而我仍然在我的分支A.一些变化,我想送一请求这些更改并在分支B的最新提交中看到分支A(我发送了一个请求)的提交。

我该如何管理?Git从另一个分支创建分支。为两者发送拉请求?

  • 我可以发送分支B的拉取请求吗?会有副作用吗?
  • 我可以改为在最后一次主合并时重新提交提交,并将提交重命名为分支B上更改的名称?这是否也会删除我发送拉请求的分支A上的提交?
  • 如果我在接受pull请求之前需要对分支A进行其他更改,是否仍然可以在不影响分支B的情况下重新分割/压缩分支A的提交?

我想我应该在创建另一个分支开发一个新功能之前再次确认我已经在主人身上,这样它就不会再发生了吗?

回答

0

最后,我找到了另一种我非常喜欢的方式,那就是樱桃采摘

  1. 对来自master(A)的分支执行pull请求。
  2. 获取不基于master(B)的分支的提交哈希。

    git log --pretty=format:"%h - %an, %ar : %s" 
    
  3. (可选)删除旧的分支(B)如果你想保持相同的名字:

    git branch -D B 
    
  4. 创建从主一个新的分支:

    git checkout -b B 
    
  5. 樱桃挑选变化(合并变化到新的分支):

    git cherry-pick HASH_OF_B (noted in step 2) 
    
  6. 合并如果有冲突,然后结束摘樱桃:

    git cherry-pick --continue 
    
  7. 发送有关主正确基于这个新分支拉请求。

我喜欢这个的是主分支保持完美的形状(完全干净),这很容易做到。我们也可以在不用担心的情况下压缩分支中的提交。

1

我可以发送分支B的拉取请求吗?会有副作用吗?

让我们画一个快速的画面

X --- X --- X --- X <--(master) 
     \ 
     A1 -- A2 <--(A) 
      \ 
      B1 -- B2 -- B3 <--(B) 

我承担A公关依然突出,所以A1masterB之间的差异。如果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 

(请注意,我已经展示了B1B2,这对于图清晰度B3加强这一基础重建不会删除提交点。由于没有如果你不知道如何寻找它们,你就不会看到它们,并且它们将被排除在push之外,最终它们可能会被垃圾收集,但是在rebase之后,在你的本地回购你可以做一些像0123一样的东西请注意,如果B曾经被推送过,这可能会给其他开发者带来问题(因为虽然没有提交从repo中移除,但是这确实会提交曾经是的提交B可达不再可达来自B,这并不好。

请参阅git rebase文档中的“从上游rebase”恢复,如果这看起来没有问题,那么您可以rebase。请记住,您需要重新测试已重建的B,因为它的树处于一个独特的新状态。 (IMO的最佳做法是重新测试中间提交。)

如果我在接受请求之前需要对分支A进行其他更改,我还可以重新分割/压扁分支A的提交吗?影响分支B?

这个问题至少有几个变化。

如果你有重建基础BA远,那么任何垫底的操作,将改写或更换A1可能让你在一个意想不到的状态,因为B仍然将指向通过A1(不A1'这是在重订创建,或在南瓜的情况下为A1A2,或其他)。

如果重建基础B远离A,那么你可以做任何你喜欢A没有进一步影响B。再次,只要意识到重写已推动历史的风险。