git的七个重要基本原则

Git 展开的七个重要基本原则

1. 每次 commit 只能做一件事
2. commit 不能破坏构建
3. 所有代码都是二等分的
4. 永远不要 rebase 公共分支
5. Git 正确合并
6. 保留定义明确的 commit 日志
7. 持续测试和集成

每次 commit 只能做一件事

代码提交中心原则是，所有更改都必须分解为小步骤进行 —— 您的每个 commit 都只能做一件事。这并不意味着每个 commit 都必须很小，比如对在数千个文件中使用的函数的 API 进行简单更改，可以使更改量很大，但仍然可以接受，因为它是针对某一项单一任务的更改。
通过始终遵循此原则，项目维护者可以更轻松地识别和隔离任何有问题的更改，而不影响其他的功能。

commit 不能破坏构建

不仅应该将所有更改分解为尽可能小的变量，而且还不能破坏内核。即每个步骤都必须完全起作用，并且不引起退化。这就是为什么对函数原型的更改还必须更新调用它的每个文件，以防止构建中断的原因。因此，每个步骤都必须作为一个独立的更改来工作

所有代码都是二等分的

如果在某个时候发现了错误，则需要知道是哪个更改导致了问题。从本质上讲，二等分是一种操作，它使开发者可以找到所有发生错误的确切时间点。

为此，请转到最后一个已知的工作 commit 所在的节点，并且已知第一个 commit 已损坏，然后在该点测试代码。如果可行，则前进到下一个节点；如果不是，则返回更上层的节点。

这样一来，开发者就可以在十几次编译/测试中，从成千上万的可能 commit 中分离出导致问题出现的 commit 。Git 甚至可以通过 git bisect 功能帮助自动化该过程。

重要的是，这只有在开发者遵守以前的规则的情况下才能很好地起作用：每个 commit 仅做一件事。否则，您将不知道是 commit 的许多更改中的哪一个导致了问题

如果 commit 破坏了构建让整个项目无法正常启动，同时等分线又恰好落在了该 commit 上，则您将不知道接下来是该往上一个节点测试还是往下一个节点测试，因为它们都有问题。

这意味着您永远都不应编写依赖于将来 commit 的 commit ，例如：调用尚不存在的函数，或更改全局函数的参数而不更改同一 commit 中的所有调用者。

永远不要 rebase 公共分支

项目工作流程不允许 rebase 他人使用的任何公共分支。因为 rebase 这些公共分支后，已重新基准化的 commit 将不再与基于原存储库中的相同 commit 匹配。在树的层次结构中，不是叶子的公共主干部分不能重新设置基准，否则将会破坏层次结构中的下游分支。

Git 正确合并

其他的版本管理系统是合并来自不同分支代码的噩梦，它们通常难以弄清代码冲突，并且需要大量的手动工作来解决。而 Git 的结构可以轻松完成这项工作，在 5.8-RC1 发布周期中，平均每天有 200 个 commit ，并从 5.7 版本中继承了 880 个合并。一些维护者注意到了其中增加的工作量，但是对此仍然没有感到什么太大的压力或者导致倦怠

保留定义明确的 commit 日志

每个 commit 都必须是独立的，这也应该包括与该 commit 相应的日志。更改的代码越少，日志反而应该说明得更详细。

在一个 commit 过了几年之后，几乎没有人会记得当初为什么进行更改。Git 的 blame 功能就可以显示这些代码的修改记录。

持续测试和集成

最后一项基本原则是开发过程中进行持续测试和持续集成。在向上游发送 commit 请求之前，开发者会测试每个 commit 。