git提交最佳实践
我正在使用git来管理一个C++项目。当我在项目中工作时，我发现当更改与许多地方相关的事情时，很难将更改组织到提交中。
例如，我可能会更改.h文件中的类接口，这将影响相应的.cpp文件，也会影响使用它的其他文件。我不确定将所有东西放在一个大承诺中是否合理。
直观地说，我认为提交应该是模块化的，每个提交都对应一个功能更新/更改，这样合作者就可以相应地挑选东西。但似乎有时不可避免地要包含大量文件和更改，以使功能更改真正起作用。
搜索没有给我任何好的建议或提示。因此，我想知道是否有人可以在提交时给我一些最佳实践。
PS。我使用git已经有一段时间了，我知道如何以交互方式添加/rebase/split/amend/...我问的是哲学部分。
更新:感谢所有的建议。也许这应该从实践中学到。我将把这个问题保留一段时间，看看是否有更多的建议。
回答 7
Stack Overflow用户
发布于 2011-07-01 14:49:13
我倾向于按照您的建议提交:提交是一个逻辑连接的更改集。我的提交可以是任何东西，从一行代码到所有文件中的更改(例如，在源文件中添加/更改版权声明)。改变的原因不一定是我正在实现的完整任务，但它通常是任务中的一个里程碑。
如果我修改了与当前提交无关的内容，我倾向于进行交互式添加，以分离出不相关的更改-即使是空格整理。
我发现，简单地将工作状态转储到存储库的提交会使它们变得不那么有用:如果提交到处都是，我就不能将错误修复移植到较早的版本，也不能在另一个分支中轻松地包含实用程序功能。
这种方法的一种替代方法是在功能分支中使用许多微小的提交，一旦整个功能完成，就进行繁重的历史重写，将提交整理到一个逻辑结构中。但我发现这种方法是浪费时间的。
Stack Overflow用户
发布于 2011-07-01 14:50:23
这正是在git中引入了index (临时区域)的用例。
您可以自由地做尽可能多的彼此无关的更改。然后选择所有相关的内容，然后一次完成多个原子提交。
我一直在这么做。如果您使用git-gui或任何其他图形用户界面客户端，您不仅可以选择要提交的文件，还可以选择hunks within the files，因此您的提交尽可能是原子的。
Stack Overflow用户
发布于 2011-07-01 15:19:59
我试着按顺序遵循这些练习……
- 提交不能使构建失败。最重要的是！
- 它应该由一个逻辑更改单元组成-无论是单行/字符还是整个文件/类，并在代码的其他部分进行相应的更改，仍然遵循#1。
什么是更改的逻辑单元？在git方面，如果您可以在一句话(当然不包括and )中用最少的字符数指定提交消息中的更改，并且您不能将该描述进一步拆分成更小的单元，我称之为一个单元。
- 提交消息应该清楚地指定提交的本质。
- 提交消息应该很小，通常不超过80个字符。任何更多的细化都应该是
description.
的一部分
https://stackoverflow.com/questions/6543913
复制相似问题
腾讯云开发者
