合并/改造工作流程

时间:2012-03-05 08:25:15

标签: git merge rebase

我正在更改我的git-merge-workflow并遇到以下问题:

到目前为止,每当我发布新版本时,我都会将develop分支上的更改(--no-ff)合并回master。这生成了一个新的merge-commit,其中包含所有develop - 提交的历史记录(--log)。 我意识到这是次优的,并希望实际从我的develop分支到master进行快速合并(已更改develop上的提交消息以反映我在master中的更改一种“更清洁”的方式)。

我当前的问题:develop上的最新提交仍然是上次的合并提交,因为我无法从master到{{进行ff合并1}}现在,因为2个分支“分歧”(develop上缺少合并提交)。

我想解决这个问题的方法就是开发:git rebase master,它会引入这个合并提交,然后让我在master上做git merge develop。 但是这会在develop(这个特定的合并提交)上生成一个新提交,还是git足够聪明地认识到这个合并提交的更改已经是develop的一部分?

2 个答案:

答案 0 :(得分:1)

git rebase master

develop可以正常使用。

如果你的分支机构目前是这样的:

A-B-C-D-E <-- master
       /
  F-G-H-I-J <-- develop

然后他们会这样结束(因为I-J是唯一无法从E到达的位):

A-B-C-D-E <-- master
         \
          I'-J' <-- develop

然后将这样快速合并回主人:

A-B-C-D-E-I'-J' <-- master

答案 1 :(得分:0)

您的方法应该允许它工作。解决这个问题的另一种方法当然是在下一次合并时完全删除你的开发分支,以防重新组合失败。然后从这一点开始从master和rebase分支出一个新的开发。

在我以前的公司,我们也试图将工作流程从合并转换为变基。但它最终因合并不同的分支而出现各种奇怪的问题。只是直接从master开始重新开发分支,感觉更干净,更安全。