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