GitFlow，压缩和合并问题

Question

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

工作流程

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

问题

我现在想知道：

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

Answer 1

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

当您合并到 master 时，听起来您正在使用 git merge --squash。这不是标准的 gitflow 做法；你只需做一个正常的合并。

常规合并和壁球合并之间的全部区别在于壁球合并不记录您要合并到的分支上的新提交（即在这种情况下为master）和原始提交之间的关系源分支；这就是为什么后续的合并无法理解master 上的内容已经对应于develop 的先前状态。

使用常规合并的“缺点”是 git 的默认输出，例如在记录 master 时，将包括所有个人提交，而不仅仅是 master 上的发布提交列表；但您可以使用--first-parent 选项来解决此问题。

要将其放入视觉效果中，您可以从一个空白 repo 开始

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 包含A 和B 引入的所有更改，但就git 而言，这是巧合；并且一旦develop 包含额外的更改，即使更改“相同”的事实也会丢失，并且会导致冲突（正如您所经历的那样）。

因此，您改为进行常规合并 - 只需省略 --squash 选项，假设您首先使用的是 squash 合并：

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

这就是 git 对合并工作的意义；现在，未来的合并尝试将“知道”M2（以及它所包含的所有内容）已经包含在 master 中，并且只有在 M2 之后的更改才会作为“他们的更改”包含在合并计算中。

这也是 gitflow 打算做的事情。