修改 git commit 信息的方法：修改最近一次提交信息：git commit –amend -m “新的 commit 信息”修改之前的提交信息：git rebase -i HEAD~n，选择 reword 修改信息（谨慎使用，特别是多人协作时）规范 commit 信息：遵循 50/72 规则，清晰简洁地描述修改内容
改写 Git commit 信息，别让历史蒙羞！
很多时候，提交代码后才发现commit message写得乱七八糟，或者干脆就是错的，这感觉，就像写完论文才发现标题打错了，让人抓狂。 别担心，Git 提供了修改 commit message 的方法，让你能优雅地修正历史，维护代码库的整洁。 读完这篇文章，你将能轻松掌控修改 commit 信息的技巧，并且理解背后的原理，避免再次掉坑。
先说个基础概念：Git 的 commit 记录是不可变的，这听起来很死板，但实际上，Git 的巧妙之处就在于它并没有真正修改历史，而是创建新的 commit 来替换旧的。 理解了这一点，很多问题就迎刃而解了。
最常用的方法是 git commit –amend。 这玩意儿就像一个“后悔药”，它能修改最近一次提交的 message。 比如你刚提交了一个 commit，发现描述写错了，那么：
git commit --amend -m "This is the corrected commit message"
这行命令会创建一个新的 commit，新的 commit 的内容和之前的完全一样，只是 message 被修改了。 原来的 commit 就像被时光机抹去了，只剩下修正后的版本。 简单粗暴，高效实用。 记住 -m 参数后面是新的 commit message。
但如果想修改之前的 commit 呢？ –amend 就无能为力了。 这时需要用到 git rebase -i HEAD~n (其中 n 代表你想修改的 commit 数量)。 这命令会打开一个交互式界面，让你选择修改哪个 commit。 选择 reword 就能修改对应的 commit message。 这可是个高级操作，慎用！特别是已经push到远程仓库的commit，千万别直接rebase，否则会给协作带来巨大的麻烦。 正确的做法是先git pull –rebase，然后再进行rebase操作。
说到这儿，我得提醒你，修改历史不是儿戏。 特别是多人协作的项目，随意修改共享分支的历史，会让你的队友崩溃。 所以，养成良好的提交习惯，在提交前认真检查 commit message，才是王道。 与其事后补救，不如事前做好。
再来说说一些坑：
- git rebase -i 的风险： 它会重写提交历史，如果别人已经基于你修改的 commit 进行了工作，那么就会产生冲突，甚至导致项目崩溃。 所以，除非万不得已，不要在公共分支上使用 git rebase -i。
- commit message 的规范： 一个好的 commit message 应该清晰简洁地描述这次提交做了什么，为什么这么做，以及如何做。 遵循一定的规范，例如 50/72 规则 (主题行不超过 50 个字符，描述行不超过 72 个字符)，能极大地提高代码的可读性和可维护性。
最后，我想说，Git 的强大之处在于它的灵活性和可控性，但这种灵活性和可控性也需要我们谨慎使用。 熟练掌握 Git 的命令，并理解其背后的原理，才能真正驾驭它，让它成为你提高效率的利器，而不是让你头疼的负担。 记住，写好 commit message，从现在开始！
