拉取请求后更改的正确 git 工作流程

Question

这种情况推荐的git工作流程是怎样的：

我们有一个 2 人的开发团队。我已经建立了自己的分支 并将其重新设置为与主分支相对应。我创造 拉取请求；我的同事检查了代码并发现了一些东西 纠正。我纠正它并推动；与此同时，她找到了另一个 需要改变的点。经过多次修改后，拉 请求已准备好合并到主程序中。

然而，现在的历史是这样的：

Fixed Error X
Fixed Error Y
Added thing Z

Issue XX: Doing YY.

而我希望它只是这样

Issue XX: Doing YY.

通常，这可以通过类似的方法方便地解决

git rebase -i HEAD~4

然而现在，虽然这仍然是可能做到的，但它创造了 与已推送到 git 的分支发生合并冲突。 这当然可以通过--force克服，但我不愿意 为此，我确信一定有一种更优雅的方法。什么 会是吗？

Answer 1

只用南瓜

如果您只想压扁整个分支，那么最简单的选择 是使用你的 forge 的挤压合并按钮（如 GitHub 的）。

如果正常合并会产生合并冲突，则挤压合并永远不会产生合并冲突 没有造成合并冲突。所以你在这里写的不是真的：

但是现在，虽然这仍然可以做到，但它会创建一个合并 与已经推送到 git 的分支冲突。

发生的情况是，当您重写了分支后，您尝试推送分支 历史。这总是需要

--force

。[1]没有更多了 如果您的工作流程是：

，那么优雅的方式（所谓的）可以做到这一点

1. 在当地做壁球
2. 推树枝
3. 从网络拉取请求视图合并

但是如果你从 GitHub（或任何伪造的地方）进行挤压合并，那么你 不必强行推你的分支。

使用 rebase（squash 的超集）

Squash 是一把大锤，你可以用它做更多有趣的事情 git-rebase(1) 的全部功能。

假设 PR 是这样开始的（不是提交消息，只是描述）：

3: Fix #987654
2: Fix typos
1: Formatting: tabs to spaces

我开始修复#987654。然后我看到里面还有一些其他的东西 我的方式：

1. 文件使用制表符缩进，这不是项目标准
2. 我要更改的代码中的函数和变量中的拼写错误

所以我先做这些。然后当他们不妨碍我时我就可以做这件事 我被派来这里做事。

然后我会收到公关反馈。他们在我的修复中发现了错误。那么历史 变成：

6. Make adjustments for #987654 in another module
5: Fix test suite regression
4: Fix off-by-one error that I made
3: Fix #987654
2: Fix typos
1: Formatting: tabs to spaces

(5) 是由于我没有更新单元测试而导致的，该单元测试涵盖了我所使用的代码 已修复。

(6) 是关于一位审阅者注意到 #987654 在以下方面有一些微妙的行为 我没有注意到的另一个模块。

现在审核完成了。现在的问题是：历史是什么？ 我想合并？

我不想保留（4）和（5），因为这些是正在进行中的 那些对永久历史没有价值的错误。 （这是一个 判断力。）

我想保留其他一切：

• (1) 和 (2) 是与 #987654 无关的初步工作，但是 在我可以做之前需要完成#987654
• (6) 非常微妙且不明显。所以除了一小段代码 评论我想在自己的提交消息中记录该更改

所以我想要这段历史：

Fix #987654 in module b
Fix #987654 in module a
Fix typos
Formatting: tabs to spaces

这意味着

git rebase --interactive

待办事项列表变为 像这样的东西：

pick Formatting: tabs to spaces
pick Fix typos
pick Fix #987654
fixup Fix off-by-one error that I made
fixup Fix test suite regression
pick Make adjustments for #987654 in another module

注释

1. 或者

   --force-with-lease

   或者甚至（稍微）更安全的东西