GitFlow、压缩和合并问题

Question

GitFlow、压缩和合并问题

gitmergegit-flowgit-merge-conflictsquash

5

我在我的git仓库中使用GitFlow，所以我有一个master、develop和（临时的）release分支。

工作流程

我从develop创建一个新分支（例如fix/fix-the-bug）
我将我的修复压缩成有意义的提交
我将fix/fix-the-bug分支合并到develop中
一旦我合并了足够多的分支，我就从develop创建一个（临时的）release/x.y.z分支
我在release/x.y.z分支中升级版本并标记该提交
当我想要将release/x.y.z合并到master时，我会遇到合并冲突。似乎master不理解提交已经存在于master中
release/x.y.z分支被合并到develop中
我删除release/x.y.z

需要注意的几点，不确定它们是否全部正确：

当合并到主分支时，我将我的提交压缩成一个提交
master应该有一个git标签指示版本号，但如果我压缩提交，不确定是否能正常工作。

问题

现在我想知道：

如何修复我的仓库，因为我认为我不应该遇到这些冲突。
欢迎进一步的工作流程建议（例如在哪个部分我可以最好地进行压缩）。

- GlennM

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Mark Adelsberger · Accepted Answer

当我合并到主分支时，我会将我的提交压缩为一个提交。

听起来你在合并到主分支时使用了

 git merge --squash 。 这不是标准的gitflow实践； 你应该只做一个正常的合并。
普通合并和压缩合并之间的整个区别在于，压缩合并不记录要合并到的分支上新提交（在这种情况下是 master ）与源分支上原始提交之间的关系。 这就是为什么随后的合并不理解 master 上的内容已经对应于 develop 的先前状态。
使用常规合并的“缺点”是，默认情况下，当记录 master 时，git的默认输出将包括所有单个提交，而不仅仅是 master 上的发布提交列表； 但是您可以通过使用--first-parent选项来解决这个问题。
为了将这个过程可视化，您从一个空存储库开始。
o <--(master)


不创建提交记录，你开始了develop分支，然后在上面创建一个fix分支并做了一些工作。

o <--(master)(develop)
 \
  A <--(fix)


你合并到dev分支

o <--(master)
|
|- M <--(develop)
\ /
 A <--(fix)


您可能需要进行更多修复。

o <--(master)
|
|- M - M2 <--(develop)
| / \ /
| |  B <--(fix2)
\ |
 A <--(fix)

现在，如果您将变更压缩合并到主分支，您会得到类似以下的内容。
o -------- AB <--(master)
|
|- M - M2 <--(develop)
| / \ /
| |  B <--(fix2)
\ |
 A <--(fix)


AB 包含了 A 和 B 引入的所有更改，但在 git 看来，这只是巧合；一旦 develop 包含了其他更改，即使更改“相同”，也会丢失这个事实，并导致冲突（就像您经历过的那样）。

因此，您需要进行常规合并 - 只需省略 --squash 选项，假设您一开始使用了 squash 合并：

o ------- AB <--(master)
|        /
|- M - M2 <--(develop)
| / \ /
| |  B <--(fix2)
\ |
 A <--(fix)

这是git合并的工作方式，未来的合并尝试将“知道”M2（以及它所涉及的一切）已经包含在master中，只有M2之后的更改将被包括在合并计算的“更改”中。
这也是gitflow打算做的事情。