GitFlow、压缩和合并问题

Question

我在 git 存储库中使用GitFlowmaster ，因此我有一个, developand （临时）release分支。

工作流程

1. develop我从（例如fix/fix-the-bug）创建一个新分支
2. 我将修复压缩为有意义的提交
3. 我将我的fix/fix-the-bug分支合并到develop
4. 一旦我合并了足够的分支，我就会创建一个（临时）release/x.y.z分支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 标签来master指示版本号，但不确定如果我压缩提交是否可以正常工作。

问题

我现在想知道：

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

Answer 1

当合并到 master 时，我将我的提交压缩为一个提交

听起来您git merge --squash在合并到时正在使用master. 这不是标准的 gitflow 实践；你只需进行正常的合并即可。

常规合并和挤压合并之间的全部区别在于，挤压合并不记录要合并到的分支上的新提交（即master在本例中）与源分支上的原始提交之间的关系；这就是为什么后续合并不明白 上的内容master已经对应于 的先前状态develop。

使用常规合并的“缺点”是 git 的默认输出，master例如在记录时，将包括所有单独的提交，而不仅仅是 ; 上的发布提交列表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)

现在，如果你将合并合并到master，你会得到类似的东西

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

并包含和引入的AB所有更改，但就 git 而言，这是巧合；一旦包含额外的更改，即使更改“相同”的事实也会丢失，并导致冲突（正如您所经历的）。ABdevelop

因此，您可以进行常规合并 - 只需忽略该--squash选项，假设您首先使用的是挤压合并：

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

这就是 git 让合并发挥作用的方式；现在，未来的合并尝试将“知道” M2（及其所需的所有内容）已包含在其中，master并且只有之后的更改M2才会作为“他们的更改”包含在合并计算中。

这也是 gitflow 打算做的事情。