git提交最佳实践

Question

我正在使用git来管理C++项目.当我在处理项目时,我发现在更改与许多地方相关的事物时,很难将更改组织到提交中.

例如,我可能会更改.h文件中的类接口,这将影响相应的.cpp文件,以及使用它的其他文件.我不确定将所有内容放入一个大的提交是否合理.

直观地说,我认为提交应该是模块化的,每个提交对应一个功能更新/更改,以便协作者可以相应地选择事物.但似乎有时不可避免地要包含大量文件和更改以使功能更改实际工作.

搜索没有给我任何好的建议或提示.因此,我想知道是否有人可以在做提交时给我一些最佳实践.

PS.我一直在使用git,我知道如何以交互方式添加/ rebase/split/amend/...我要问的是哲学部分.

更新:感谢您的所有建议.也许这应该从练习中学到.我会将问题保持一段时间,以确定是否有更多建议.

Answer 1

如果我修改了与当前提交无关的内容,我倾向于使用交互式添加来分离不相关的更改 - 即使它是一个空白整理.

我发现只是简单地将工作状态转储到存储库的提交使它们变得不那么有用:我不能将错误修复向后移植到早期版本,或者如果提交到处都很容易在另一个分支中包含实用程序功能.

这种方法的一种替代方法是在功能分支内部使用大量微小的提交,并且一旦完成整个功能,就要进行大量的历史重写,以便将提交整理成逻辑结构.但我发现这种做法浪费时间.

Answer 2

这正是用例,index在git中引入了暂存区域.

您可以随意尽可能多地进行相互关联的更改.然后你选择所有相关的东西,然后一次性进行几次原子提交.

我一直这样做.如果您使用git-gui或任何其他GUI客户端,您不仅可以选择要提交的文件,还可以选择hunks within the files提交尽可能原子的提交.

Answer 3

我尝试按顺序遵循这些做法......

提交不得使构建失败.最重要的!
它应该由一个逻辑变更单元组成 - 无论是单行/字符还是整个文件/类,其他代码部分都有相应的变化,仍然遵循#1.

什么是变革的逻辑单位？在方面git,如果你能在字符数最少指定提交信息的变化,在一个句子(没有的课程与运算),你不能进一步打破描述成更小的单位,我称之为一个单元.
提交消息应明确指定提交的本质.
提交消息应该很小,通常不超过80个字符.任何更详细的说明都应该是其中的一部分description.

我发现第四点令人困惑.提交消息是编辑器中的整个文本,显然应该只需要解释提交的内容.它应该被构造为1行"主题",最多*50*(所以说是git自己的编码指南)字符后跟空白行,然后是需要的详细解释. (5认同)
如果您需要大胆的提交才能更改单个功能，我不一定会责怪Git。就像构造代码，分离关注点和封装数据一样。 (2认同)

Answer 4

免责声明:我也在试图弄清楚提交应该是什么,以及最终历史应该如何结束.但是,我想分享一些我在自己研究过程中遇到的资源.

首先,Linux Kernel项目在Merge Strategies上有一个很棒的页面,用于将代码合并到上游.他们谈论制作一口大小的提交; 在你想要的实际添加之前做一个或多个重构提交(重构应该使你的功能更加清晰;)和其他东西.

我最喜欢的另一页是Seth Robertson的Git Best Practices.这不仅是关于使用git的许多最佳实践的页面,而且它也是一个巨大的资源,包含有关各种git主题的足够信息,以便在Google上搜索更深入的信息.

Answer 5

我要问的是哲学部分。

我想我可以回答这个问题，因为我最近参与了一些个人研究。

应该把重点放在创建原子提交上。这意味着有必要在一些事情上加倍注意：

提交应该集中于一项更改，并且只能进行一项更改。除此之外，还会产生不良的副作用。

有人可能会认为这太多了，不切实际。但是，即使对于小型公司，支持它的最佳论据是事实，即庞大的原子提交将迫使您的设计更加分离和一致，因为要实现完全最佳的原子提交，一个要求就是拥有一个健康的代码库，而不是一团糟。

如果您一贯强制执行良好的提交实践，则将能够推动工程文化和代码本身进入更好的状态。