Git从另一个分支创建分支。发送两者的拉取请求?

时间:2017-05-04 17:50:38

标签: git bitbucket branch rebase pull-request

  1. 我创建了一个分支,并对这些更改发送了拉取请求,让我们将其称为分支A.
  2. 然后我在我的分支A上创建了一个分支B.经过一些更改后,我想发送一个拉动请求来进行这些更改,并看到了分支A(我发送了一个拉取请求的那个)的提交。分支B的最新提交。
  3. 我应该如何管理?

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

    我想我通常应该确保在创建另一个分支以开发新功能之前再次使用主设备,以便它不会再次发生?

2 个答案:

答案 0 :(得分:1)

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

让我们快速了解一下

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

我认为A的PR仍未完成,因此A1masterB之间的差异。如果B中的任何内容都不依赖于A1,那么这在概念上并不好;您不希望批准/合并B以依赖于A1中的接受/可能过早发布的更改。

现在,如果A的PR获得批准,那么合并之后A1就不再是差异了;你可以争辩说,没有伤害,没有犯规&#34 ;;但是,如果独立分支机构独立于master

,那么它仍然是最好的

我可以改为对最后一次主合并的提交进行重新绑定,并将提交重命名为分支B上的更改名称吗?那还会删除我发送拉取请求的分支A上的提交吗?

首先考虑第二部分:变基不会删除回购中的提交;这是一种(看似很常见的)错误观念。由于A1可以从分支A访问,因此它不会受到B的rebase的影响。 但是,在重新定位时应该小心,以避免创建A1提交的副本,因为这会破坏rebase的目的。

git rebase --onto master A B

应该给你

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

(请注意,我在此图中显示了B1B2B3,以便明确强调重新定位不会删除提交。由于没有refs指向它们,除非你知道如何查找它们,否则你不会看到它们,它们将被排除在push操作之外;最终它们可能会被垃圾收集但是在改变之后,在你的本地回购中,你可以做git log B@{1}之类的事情并看到他们仍然在那里)

请记住,如果曾经推送B,这可能会给其他开发人员带来问题(因为虽然没有从repo中删除任何提交,但这确实会使过去的提交可达来自B的{​​{1}}变得无法访问,而且不是很好。

参见&#34;从上游rebase恢复&#34;在B文档中,如果这似乎不是问题,那么您可以进行rebase。请记住,您需要重新测试重新定位的git rebase,因为它的树处于一个独特的新状态。 (IMO最佳实践也是重新测试中间提交。)

如果在接受拉取请求之前我需要在分支A上进行其他更改,我是否仍然可以在不影响分支B的情况下重新分配/压缩分支A的提交?

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

如果 <{em>} <{1}}远离B,那么任何重写或替换B的重定位操作都可能会让您处于意外状态,因为A仍会指向A1(不是{1}},而是B创建的,或者A1,如果是壁球,或其他什么。)

如果您 A1'重新设置为远离A1A2,那么您可以对B执行任何操作,而不会对A产生进一步影响。再次注意重写历史的风险。

答案 1 :(得分:0)

最后,我找到了另一种我非常喜欢的方式,即采摘

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

    RewriteCond %{QUERY_STRING} ^searchparam=
    RewriteRule ^([a-z-]+)/$ $1.php [L]
    
  3. (可选)如果要保留相同的名称,请删除旧分支(B):

    git log --pretty=format:"%h - %an, %ar : %s"
    
  4. 从主人创建一个新分支:

    git branch -D B
    
  5. Cherry选择更改(将更改合并到新分支中):

    git checkout -b B
    
  6. 合并是否有冲突,然后结束樱桃选择:

    git cherry-pick HASH_OF_B (noted in step 2)
    
  7. 在主服务器上正确发送此新分支的拉取请求。
  8. 我喜欢这个是主分支保持完美的形状(非常干净),并且它非常简单。我们也可以在没有担心的情况下压缩树枝中的提交。

相关问题