提问人：starrywrites 提问时间：11/15/2023 最后编辑：starrywrites 更新时间：11/16/2023 访问量：69
使用 GitFlow 时为什么要在 master 上执行 squash 和 merge？
Why would you ever do squash and merge on master when using GitFlow?
问：
在过去的两个月里，我们的团队一直在虔诚地使用壁球和合并，因为我们听说这是最佳实践。但最近发现我们错误地使用了它。
最初，我认为 squash-and-merge 只是为合并中的提交创建了一个简洁的小包装器提交，但事实并非如此。它创建一个单独的、不相关的提交。因此，两个月后，即使我们的文件在“develop”和“master”分支之间是同步的，但提交却不是——所以我们的 PR 显示了在那段时间内实现的整套更改。不用说，这是不可能看的。
我们通过对“开发”和发布分支进行变基（这是一场噩梦）来解决它，然后，为了确保它不会再次发生，在我们的 GitHub 管理设置中寻找设置或配置，以禁止在 master 上进行压缩和合并，但找不到。
鉴于该设置不存在，我的问题是：如果您使用的是 GitFlow，是否会有将 squash 和 mergeging 用于“master”的用例？似乎这是一个只能在非永久分支和永久分支之间使用的功能，而不应该在两个永久分支之间使用。如果是这样，您是否需要一些步骤或配置，以便您的分支不会不同步？
答：
1赞
Igal S.
11/15/2023
#1
就我个人而言，我不是 gitflow 和 develop/master 对的忠实粉丝。
但据我所知 - 您应该压缩并合并功能分支中的更改以开发分支。这将为每个拉取请求创建一个干净的提交。 这是有道理的，因为功能工作是迭代的，拉取请求可以有多次迭代。
合并到 master 分支时，不应压缩更改。这让 git 明白提交是相同的。例如，在修补程序的情况下，这一点非常重要。您可以只将修复程序推送到 master 分支，然后需要合并回 develop 分支。
至于“小包装器提交”，这不是它在 git 中的工作方式。每次提交都是一个快照，其中包括其整个历史记录。对历史记录的每一次更改（如 rebase 或 squash）本质上都是一个新的提交。
评论
0赞
starrywrites
11/16/2023
GitFlow 是我们公司的标准。-\_（：/）_/- 出于好奇，您更喜欢哪种选择？
0赞
Igal S.
11/16/2023
为开发人员使用单个分支和功能分支。尽可能多地利用 CI/CD。因此，每次提交到 master（PR 合并）都会触发部署到测试环境 + 测试。没有中间分支。必须将功能分支压缩到主节点，才能拥有漂亮而干净的历史记录。masterdevelop
1赞
user229044
11/16/2023
#2
如果您使用的是 GitFlow，是否会有将 squash-and-mergeging 用于“master”的用例？
不可以，切勿将发布分支或修补程序压缩并合并到 master 中。
似乎这是一个只能在非永久分支和永久分支之间使用的功能，而不应该在两个永久分支之间使用
完全正确。您可以使用它来合并要删除的分支，其中您特别不打算保留其历史记录。它是故意破坏性的，将整个分支折叠到目标分支上的单个提交。
Squash-and-merge 主要用于基于主干的开发，其中您可以不断将小的一次性分支合并到主分支中。
如果是这样，您是否需要一些步骤或配置，以便您的分支不会不同步？
不。Git-flow 工作正常，只是不要压缩和合并你想保留的东西。
评论
git merge -s ours进行假合并提交来避免变基 - 它会创建一个真正的合并提交，修复历史记录，但不会更改任何文件（您不需要，因为所有更改都已经存在）