我试着将我的每个项目都变成git。
我看到了提交（和文档！）代码更改的两种可能策略。
A）在每日基础上并将非常简单的注释放入git的commit-log中以查找更改差异的详细信息将是首选工具。
B）永久性地进行每次微小更改（或更改每个文件），并且commit-log将详细描述更改。对于方向，日志就足够了，而不是文件版本之间的差异。
当一个项目在一天中的多个地方发生变化时，我认为现实生活中几乎没有提交和详细的提交日志。
而且我不确定现在是在搜索日志还是区分文件是搜索历史记录的最佳方式。
通常在git世界中最好的做法是什么？
这确实是一个重要的问题，因为a lot of people实际上忽略了他们的提交清单。它们不应该是因为组织良好的存储库大大提高了项目的价值，达到了一个点，在这个点上，给定的信息，当易于检索时，几乎比代码本身更有价值。
简而言之 ：
我个人已完全采用Linux kernel development guidelines为我自己的项目。这些是引诱我最多的。
它基本上包括将更改分组为“逻辑单元”，这可能会导致您批量提交或oneliner。
例如，内核源代码附带一个名为sparse的工具，而不是扫描所有C文件并检查潜在的语义问题。当发现新内容时，我们会定期升级此工具，因此我们希望清理整个项目。在需要更改的事项中，删除了FSF的邮政地址，该地址用于包含在每个源文件顶部的文本注释中的许可证中。
对于这种特殊情况，我会将所有这些变更集（截断顶部注释）收集到一个专用于此的提交中，即：包含为每个C文件删除此部分（即使它们在子系统目录中有30个）但没有别的。没有额外的代码更改或侧面修改。然后我会为其余的工作准备其他一些提交。
这在Git之前已经是必需的，因为大多数这些更改到目前为止（实际上仍然是）作为“补丁”提交给负责审核它们的维护者，然后才决定是否将它们集成。不仅向他发送包含本周工作的大型压缩包，并且通知“自己应对此问题”，您有机会看到您的完整工作被拒绝，但提交准备充分的补丁可让人们有选择地拒绝您的一些补丁虽然仍然接受其余的大部分，然后让你修复导致问题的那些并再次提交它们。
此外，多用户开发项目中的一个常见做法是永远不要重写“历史”......除非所有主角都与Git完美配合并且可以处理这个问题。但是，没有什么能阻止您在发布之前更改自己的历史记录。因此，如果您没有时间专注于“打包”，那么您在开发时可以做的就是将所有内容都提交到个人临时分支上，直到您完成为止，然后按主题挑选所有主题官方开发分支，与git diff核实您的临时和开发分支的顶部是否同步并最终推动您的工作。
关心提交的另一个好理由是利用调查命令，例如git blame。例如，如果您落在用于控制用户身份的行上并且突然不再发生，那么您不仅可以享受git blame指向引入更改的确切提交，还可以快速检索整个上下文，一点信息。在这种特殊情况下，这可能是由于所有身份检查都集中在专用功能或模块的上游。
这是因为Git的主要定向方式是某些命令（如git add）默认单独拾取文件并需要一些选项（如-u或-A）来选择已更改的所有内容（与其他SCM不同，如Mercurial，提供addremove，结果证明是一个错误的好主意）。
为了帮助您这样做，您当然可以逐个包含文件。但是你也想看看：
git add -p
...从单个修改过的文件中单独选择帅哥。然后你可以使用
git diff
git diff --cached
...查看仍需要添加的内容以及您已为下次提交准备的内容。
最后，请务必关注每次提交中消息的正文，因为这是应该记录某些内容的原因。大量开发人员只需使用git commit -m在主题行中声明一些内容，但描述提交允许您避免在代码中直接设置此信息，从而保持其清洁。