通常如何使用git？ 一对用于“ 同步所有人 ”的基本命令。 从来没有超越这种肤浅理解的人经常会感到沮丧。 但是，掌握git一定会得到回报。 您花了多少时间使用git？ 我建议您使用很多工具，这些工具的使用频率是原来的一半，而学习时间则是原来的两倍。



如果您想了解更多有关git的知识，建议您从Pro Git的 第10章开始（它是免费的！），然后是第2、3和7章。其余是可选的。 在本文中，我们将讨论如何使用本书中描述的工具在git中进行有条理的生产性工作。

基础：良好的提交描述

您可能之前已经听说过，但请耐心等待。 通常，您不需要使用git commit -m " " 。 首先将git配置为使用您喜欢的编辑器： git config --global core.editor vim ，然后运行git commit 。 编辑器将打开，您可以在其中编写有关提交的描述。 第一行应限制为50个字符，并以一个句子结尾： 应用此提交之后…… “将修复CJK语言的文本呈现”，“将添加对v3协议的支持”，“将重构CRTC处理”等，然后添加一个空行并继续对commit进行扩展描述 ，应将其硬编码为72列，并包括诸如commit的理由，权衡，方法限制等详细信息。

我们使用72个字符，因为这是电子邮件的标准宽度 ，电子邮件是git的重要工具。 使用50个字符的限制是因为第一行成为电子邮件的主题，并且您可以“[PATCH linux-usb v2 0/13]”添加很多文本，例如“[PATCH linux-usb v2 0/13]” 。 您可能会发现这些格式设置限制令人烦恼和繁琐，但是请记住，其他人在与您不同的上下文中读取日志。 我经常在垂直显示器上阅读提交日志，它不会像4K 16：9显示屏那样将太多文本压缩成一行。

每次提交都应该是自主更改

每个提交仅应包含一个更改-避免在一个提交中进行小的无关更改（在这一点上，我通常可以听听自己的提示）。 另外，避免将更改分成多个提交，除非将想法分解为单独的步骤，每个步骤代表一个完整的更改。 如果您的工作树中有几处更改，而您只需要提交其中一些更改，请尝试git add -i或git add -p 。 此外，每个提交都应编译，成功通过所有测试，并避免在以后的提交中修复的已知错误。

现在，您可以进行任何提交，并期望代码可以正常工作。 例如，在将提交有选择地包含在发行分支中的过程中，这将派上用场。 这种方法还增强了git-bisect ¹的实用性 ，因为如果您希望代码能够编译并成功通过每个提交的测试，那么您可以传递git-bisect脚本，该脚本以编程方式检查树是否有错误，并避免误报。 这些独立的，描述良好的提交将简化git-shortlog发行说明的准备工作，就像Linux使用Linux发行版所做的那样 。

第一次做就很难

我们来看看git最重要的功能之一，它与之前的版本不同：故事编辑。 所有版本控制系统都带有某种“时间机器”，但在此之前它们大多是只读的。 但是，git time machine不同：您可以更改过去。 实际上，甚至鼓励您这样做！ 但我警告您：只能改变过去，而尚未进入稳定的公共部门。

底线如下。 编写没有错误的提交，具有良好描述的自主提交在第一次尝试时就很难。 相比之下，编辑故事很容易，并且是git高效工作流程的一部分。 签出git-rebase并自由使用它。 您可以使用rebase重新排序，合并，删除，编辑和拆分提交。 例如，我通常会对该文件进行一些更改，提交一个修订提交（ git commit -m fixup ），然后使用git rebase -i将其合并到一个较早的提交中。

各种技巧

• 阅读法力值！ 选择一个随机的git手册页并立即阅读。 另外，如果您尚未阅读顶层git手册页（仅man git ），请执行此操作。
  
• 在高级git命令的每个法术力的底部，通常是高级命令所依赖的低级git命令的列表。 如果要了解有关高级git命令如何工作的更多信息，请尝试阅读这些手册页。
  
• 了解如何使用rev selection选择正确的提交。
  
• 分支很有用，但是您必须学会在没有分支的情况下进行工作，并且还需要使用一系列好的工具。 使用诸如git pull --rebase ， git send-email -1 HEAD~2 git pull --rebase和git push origin HEAD~2:master git pull --rebase git push origin HEAD~2:master 。

简而言之，git bisect是一种工具，可在历史记录中的两个提交之间执行二进制搜索，一次查看一次它们之间的提交，以便检查错误。 这样，您可以计算导致问题的提交。 ↑