我们都知道提交代码的最佳实践。 保留一组整齐的提交，这些提交说明了为什么需要提交并有一个提交目的，而不仅仅是“修复测试”。 每个提交都应该是开发计划中的一个步骤（您甚至在触摸键盘之前就已计划过），并且应该包含通过该步骤的测试。 这是锻炼TDD的一种好方法，并且对检查您的代码的任何人都非常有用。
这是您今天可以加快和清理git使用量的一小部分工作。
处理评论评论
想象一下，您拥有一个美丽的git历史，其中包含大约10个小提交。 有人检查了您的代码，并指出了一个他们认为会更好地命名的变量。 您同意并在分支机构的末尾进行更改。 您对自己说：“不用担心”，“我将以交互方式将其重新设置为正确的提交，并且没人会知道我对其进行了更改”。
您将按照以下步骤操作，然后使用:wq vim浏览器。 令您惊骇的是，一次提交已暂停，并且您会在标准输出中看到“ CONFLICT ”一词。 您没有意识到的是，在以后的提交中，您在该行上编辑了函数调用中的一个参数，并且由于您位于分支的末尾，因此您提交了该更改，并尝试强制执行它到您以前的提交。 它询问您要保留哪个版本，您急于考虑“当然，我在代码中需要该参数”会被原谅，因此您将其保留在那里。 您还没有意识到的是，此更改现在已经破坏了测试，上帝知道您现在需要编辑哪个提交。 如果有很多这种情况，可能会使审阅者感到困惑。
为了解决此问题，我喜欢使用一种技巧来编辑我的提交，而不是尝试将提交强行强加到其中。 要做到这一点很简单：
git rebase -i主
您将遇到通常的屏幕，但是不要将其更改为squash或fixup ，而应在提交行的开头添加e 。 当rebase到达提交时，您应该获得类似于以下内容的输出
停在b4r3736dw3 ...将任务批处理为较小的任务，以实现可伸缩性。
您现在可以修改提交，
git commit-修改
对更改感到满意后，请运行
git rebase-继续
您可以对提交进行任何更改，就像您当时所做的一样。 您甚至可以执行git reset HEAD~来重置所有文件并根据需要进行多次提交。 这非常适合将海妖提交分成较小的部分。 完成所有编辑后，可以运行git rebase --continue并完成其余的提交。 您可能仍然会遇到冲突，但是它们会更容易理解。
别名命令
对于那些微生产率的书呆子，我建议将每个命令的别名都别名为尽可能少的字母。 对于上面的示例，运行起来非常令人满意：
-
grbi—git rebase -i master -
gcane—git commit --amend --no-edit -
grbc—git rebase --continue -
push—git push origin 'git rev-parse --abbrev-ref HEAD'（但将引号替换为反引号）
这有助于将代码快速推送到CI服务器，以使测试并行运行！ 很高兴注意到当您多次键入命令并立即将其写入.bash_profile中时，即使您至少不重新加载外壳程序，它也下次会存在！ git rev-parse是获取事物名称的一种好方法，并且该文档可以使就寝/通勤阅读变得更加出色！
自动壁球
如果您要在提交时快速修正提交，只需键入以下内容
git commit --fixup
然后，当您完成提交后，将它们自动压缩到正确的位置：
git rebase -i-自动压扁
自然，我将其缩短为gll （ git log --oneline --decorate ）来获取提交SHA，然后使用gcf 和grbas来完全gcf 。
全局gitignore
您是否有仅影响代码的文件，而没有其他文件？ 也许是编辑器留下了流氓文件（vim为打开缓冲区生成*.swo和*.swo文件）。 要只为您取消跟踪它们，只需在~/.gitignore_global创建一个全局gitignore文件并将其添加到其中。 然后，您可以责怪其他人意外提交文件。 我完全喜欢混叠git blame以blame为我的编码注入一些无礼。
如果您有任何认为能胜过我的git生产率提示，我很想听听他们的意见！ 不严重，请保持联系并让我知道。
