后端开发教程 - Java、Spring Boot 实战 - msg200.com
Git 修复工作流程
原帖：
介绍
GitHub 流程，或者说是一种类似的 Git 策略，主要工作在功能分支上完成，然后通过拉取或合并请求进行，已经成为许多开发团队使用 Git 和 GitHub 或 GitLab（甚至 Bitbucket）的标准方式。除了这种工作方式的主要优势之外，它还能让开发人员保持清晰的 Git 历史记录（另请参阅5 条让 Git 更上一层楼的规则）。
我们假设以下内容作为本文中建议的工作流程的起点：
- 您希望维护干净的 Git 历史记录，这意味着应避免修复提交
- 你不想因为总是重写 Git 历史记录而中断你的开发工作流程
- 您
git commit --amend只能使用最新的提交
Git 有一些强大的命令，让我们既能保持干净的历史记录，又不会中断开发流程。我们称之为“Git 修复工作流程”。
线性工作流程
为了说明 Git 修复工作流程，我们将使用以下示例 hack 会话：
# coding the user component's index view
$ git commit -m "add user component's index view"
# coding the user component's edit view
$ git commit -m "add user component's edit view"
# updating the component's index view so it actually works
$ git commit -m "add user component's index view, it works now"
# a typo is noticed in the index view
$ git commit -m "fix typo in index view"
# fix a bug in the view rendering
$ git commit -m "fix view rendering"
$ rubocop
$ yarn lint
# fix linting errors
$ git commit -m "fix linting errors"
# team members do a code review on the PR / MR
$ git commit -m "fix import in index"
上述会话导致以下 Git 历史记录：
fix import in index
fix linting errors
fix view rendering
fix typo in index view
add user component's index view, it works now
add user component's edit view
add user component's index view
以下提交反映了从另一位开发人员的角度相关的实际工作：
fix view rendering
add user component's edit view
add user component's index view
所有修改先前提交的提交只会使历史记录变得混乱，应该被压缩。例如，“修复索引视图中的拼写错误”这个提交应该与“添加用户组件的索引视图”一起压缩。
为了清理历史记录，我们可以在合并分支之前手动以交互方式对提交进行变基。但想象一下，你可能有很多提交，而之后在合并过程中，你记不住哪些提交应该合并在一起。此外，在交互式变基模式下标记相关提交需要大量的手动工作。
修复工作流程
Git 包含了实现自动化所需的一切。那么，让我们用新的工具集重做之前的 hack 会话：
# coding the user component's index view
$ git commit -m "add user component's index view"
# coding the user component's edit view
$ git commit -m "add user component's edit view"
# updating the component's index view so it actually works
$ git commit --fixup <COMMIT HASH OF THE COMMIT "add user component's index view">
# a typo is noticed in the index view
$ git commit --fixup <COMMIT HASH OF THE COMMIT "add user component's index view">
# fix a bug in the view rendering
$ git commit -m "fix view rendering"
$ rubocop
$ yarn lint
# fix linting errors, assuming the linting error was introduced in the commit
# "add user component's edit view"
$ git commit --fixup <COMMIT HASH OF THE COMMIT "add user component's edit view">
# team members do a code review on the PR / MR
$ git commit --fixup <COMMIT HASH OF THE COMMIT "add user component's index view">
生成的 Git 日志如下所示：
fixup! add user component's index view
fixup! add user component's edit view
fix view rendering
fixup! add user component's index view
fixup! add user component's index view
add user component's edit view
add user component's index view
--fixup我们使用标志来创建修复提交，而不是定期提交（并编写提交消息） 。
现在，在合并合并请求之前，我们发出带有--autosquash标志的交互式变基。
注意：
GitLab 将包含修复提交的 MR 标记为WIP，因此如果您尚未压缩，则会阻止合并。
$ git rebase --interactive --autosquash \
<COMMIT HASH OF THE COMMIT "add user component's index view">~1
我们将进入交互式 rebase 模式，其中相关提交已标记为修复：
pick 364003b add user component's index view
fixup afa6970 fixup! add user component's index view
fixup 1da5d7c fixup! add user component's index view
fixup c998b08 fixup! add user component's index view
pick d9731b5 add user component's edit view
fixup 33d6080 fixup! add user component's edit view
pick 73e8a6a fix view rendering
生成的 Git 历史记录如下所示：
fix view rendering
add user component's edit view
add user component's index view
最终结果是一个非常一致且可读的 Git 历史记录，其中每个其他开发人员都知道发生了什么，而无需您在开发过程中采取无趣的回避措施。
概括
总而言之，以下两个基本 Git 命令对于使用 Git 修复工作流程是必需的：
$ git commit --fixup <COMMIT THAT NEEDS FIXING>
$ git rebase -i --autosquash <FIRST COMMIT THAT NEEDS FIXING>~1
奖励：创建 Git 别名
如果你开始采用这种工作流程，你将需要在终端中输入大量代码。这时，创建一些 Git 别名来减轻你的大脑和双手负担是有意义的。
[alias]
cif = commit --fixup
ri = rebase -i --autosquash
更多奖励：全局自动压缩配置
无需提供--autosquash标志，配置可以全局应用。-i不过 rebase 命令仍然需要。
$ git config --global rebase.autoSquash true
编辑（2018-09-18）
我编写了两个 git 脚本git fixup来git squash支持此工作流程，并添加了一篇博客文章来描述它们。