GitFlow、压缩和合并问题

Question

我在git存储库中使用GitFlow，因此我有一个master、develop和(临时) release分支。

工作流

1. 我从develop创建了一个新的分支(例如fix/fix-the-bug)
2. 我把我的修正压缩成有意义的提交。
3. 我将我的fix/fix-the-bug分支合并成develop
4. 一旦有足够多的分支合并，我就从develop创建一个(临时的)develop分支
5. 我的版本-在release/x.y.z分支中插入我的脚本并标记提交
6. 当我想将release/x.y.z合并到master中时，我会得到合并冲突。似乎master不明白master中已经存在提交。
7. release/x.y.z分支被合并为develop
8. 我删除了release/x.y.z

很少有事情需要注意，不确定它们是否都是正确的：

• 当我合并为师父时，我把提交压缩为一次提交。
• master上应该有一个git标记，指示版本号，但如果我压缩提交，则不确定它是否正确工作。

问题

我现在想知道：

• 我怎么能修复我的回购，因为我不认为我应该得到这些冲突。
• 任何关于工作流程的进一步建议(例如，在哪一部分中我可以最好地执行壁球)将受到欢迎。

Answer 1

当我合并为师父时，我把提交压缩为一次提交。

当您合并到git merge --squash时，听起来像是在使用master。这不是标准的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选项，假设您首先使用的是南瓜合并：

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

git意味着合并是如何工作的；现在，将来的合并尝试将“知道”M2 (及其所包含的一切)已经包含在master中，并且只有在合并计算中将M2作为“更改”包含之后才会进行更改。

这也是gitflow打算做的事情。