Git:如何更新合并库生成的分支

可以。。。所以听起来像 development 是一个长期存在的分支,它表示上一个版本,与 master 在Gitflow中。

听起来像 v1.0 是一个长期存在的分支,您将在其中组装下一个版本,就像 develop 在Gitflow中。

给定的本地分支可能类似于功能分支(在这种情况下,您将把它合并到 V1.0 )或者像一个修补程序(在这种情况下,你会把它合并到两个 V1.0 和 发展 )奇怪的是,您似乎总是创建本地分支,以便 能够 两者合并。(所以,在创建分支时,您不知道是否要合并到 发展 ?因为如果不是这样的话,在合并基础上使每个分支“重新启动”似乎都有一些不必要的合并解决成本…但我离题了。)

让我们用图片介绍一下您的场景。你从

A -- x <--(development)
 \
  Z <--(v1.0)

然后创建一个本地分支

A -- x <--(development)
|\
| Z <--(v1.0)
 \
  B -- C <--(feature)

你的同事创建了一个地方分部

A -- x <--(development)
|\
| x -- O <--(hotfix)
|\
| Z <--(v1.0)
 \
  B -- C <--(feature)

(请在这里忍受,我知道可能永远不会有任何一个回购,所有这些分支都在其中,但让我们看看“大局”无论如何…)

所以你的同事合并到两个长期存在的分支

A -- x -- M <--(development)
|\       /
| x --- O <--(hotfix)
|\       \
| Z ----- M <--(v1.0)
 \
  B -- C <--(feature)

注意,从这一点开始, O 合并的基础是 发展 和 V1.0 . 但你的分支是在 A 现在我们来问你一个问题:如何 hotfix 进入你的分支。

到现在为止 热修复 是共享历史的组成部分,因此您可能不想做任何重写和/或复制其提交中更改的事情。

你可能不想合并 V1.0 因为混合 Z 进入你的分支似乎与在合并基础上创建分支的粒度相反。

所以你真的想结合 o 进入你的分支。现在,让我们切换一下,看看你的本地回购如何看待事情,如果我从字面上理解你的术语“本地分行”(意思是你没有 热修复 分支):

A -- x -- M <--(development)
|\       /
| x --- O
|\       \
| Z ----- M <--(v1.0)
 \
  B -- C <--(feature)

现在,考虑到这个 feature 是 也 本地(仅存在于您的回购中),一个选项是将其重新定位到新的合并基础上——这似乎仍然符合您的工作流程的精神。

git rebase $(git merge-base development v1.0) feature

会给你

A -- x -- M <--(development)
|\       /
| x --- O -- B' -- C' <--(feature)
 \       \
  Z ----- M <--(v1.0)

在这一点上 B' 和 C' 都是代码的未测试状态。理想情况下,您应该同时测试它们并解决任何问题(但是,如果 B’ 说起来容易做起来难),这样你就可以有一个干净的历史。

另一种选择是简单地将合并基础合并到分支中,这样可以避免“未经测试的提交”问题,但创建一个“更混乱”(尽管可以说更准确)的历史记录。

git checkout feature
git merge $(git merge-base v1.0 development)

这给了你一些感觉

A -- x -- M <--(development)
|\       /
| x --- O -----------
|\       \           \
| Z ----- M <--(v1.0) \
 \                     \
  B -- C -------------- M <--(feature)

在花了很长时间说“为什么”之后,这意味着我们基本上做了您已经做的事情,除了跳过为合并创建分支的步骤,因为我们可以直接引用合并基。

这是有道理的。你已经知道要和你的分支结合在一起会发生什么变化了-你真的不知道 希望 更改要合并的提交内容。所以我们能做的最好的就是找到一种更简单的方法来引用这些更改。

我所做的是使用合并库创建另一个具有最近更改的分支,并将其与本地所做的更改合并。

这是一种方法( Mark 说明了REBASE方法 in his answer )

但不是这样,有了Git2.22(2019年第二季度),你就不必这么做了:

git merge-base v1.0 development
git checkout <commit-hash>
git checkout -b <new-branch-name>

相反,你应该这样做:

git checkout -b <new-branch-name> v1.0...development

见 commit e3d6539 , commit 27434bf (2019年4月27日) Denton Liu ( Denton-L ) .
帮助者: Junio C Hamano ( gitster ) .
^{(合并人 Junio C Hamano -- gitster -- 在里面 commit 4ac8371 (2019年5月19日)}

branch :制作 create_branch 接受合并基础版本

当我们跑步时

$ git checkout -b test master...

它会随着信息而失败

fatal: Not a valid object name: 'master...'.

这是由于 创建分支 哪里 start_name 是 应为有效版本。
然而, git checkout 允许分支 是有效的 合并基 版次(即带有 ... “)因此 要传入的Rev无效。

制作 创建分支 接受合并基本版本,因此本例不接受 出错。

作为副作用,教Git分支如何处理合并基础版本 好。