Git 最佳范例

Git 是最流行的版本管理工具，也是程序员必备的技能之一。在本文中，作者将分享其多年使用 Git 的经验。

作者 | Marcus Eisele

译者 | 谭开朗

责编 | 屠敏

出品 | CSDN（ID：CSDNNews）

以下为译文：

这些年来，我学到了很多关于Git的知识。而这些知识的获得大都是通过大量地实践，可谓学来不易。下面，我总结了一些Git最佳范例，想必大家在团队工作中会用到。

使用原生工具Luke—使用CLI

你至少得动手试一试！就像年轻的天行者一样，至少曾逼自己走在绝地的道路上。使用原生工具Luke，动手一试吧！

这些年我看惯了Git的终端窗口，以至于现在很烦其他所有类型的窗口。它们本身并不差，只是我认为有必要学习Git基础知识。

即使实践得多了，我有时也难以理解图形工具对点击事件的响应逻辑。在使用GUI时出现问题，那就更糟糕了。

我喜爱的图形工具需具备：模拟环境、检出改动点和解决冲突代码。在我看来，没有什么比大屏幕上的横向视图更棒了。为满足这些功能，我现在最常用IDE(IntelliJ IDEA或Android Studio)，他们在这领域的表现十分优秀。

一次提交一个变更

我另一篇关于“代码评审最佳范例”的文章已经涵盖了其中的很多内容。但在这里，我仍想强调提交变更的注意事项。

一次提交应该是原子提交。实际上，这意味着源码库有无此变更项都能正常运行。每一次提交变更都不能影响源码的构建。也就是说，如果某次提交变更导致构建失败，那么仅通过查看提交本身就能轻而易举地恢复回来。

在实践中，这常常归结为重构和新特性要分开。原因如下：

1. 混合两者，增加了冲突的几率，且难以解决——不仅针对你个人负责的代码，多人平行开发的代码也是如此。
2. 一旦混合，将会增加代码评审的难度：评审人员不得不考虑变更项是针对新特性还是单纯的代码重构。
3. 混合两者导致回滚变得困难。分两次原子提交要好很多：如果是重构代码出了问题，就回滚重构。否则，如果是新特性代码出了问题，就回滚它！
4. 标注“仅做了些样式变更”的提交可能是个好线索，便于进一步查看历史。

一个拉取请求，一个关注点

基本和上一点相同。在你提出一个拉取请求时，请确保只针对一个特性分支。如果可以，请遵循与上一点相同的原则。

可以有两个原子提交：一个添加功能，另一个做大量重构。这并不违反原子提交原则。不过，与将两个变更项分散在两个拉取请求相比，（两个原子提交的）评审代码更困难。

以我的经验，如果没有杂乱的重构或美化性变更（例如去空格），包含特性或修复Bug的拉取请求被批准的速度会快很多。同样的，仅包含非功能变更的拉取请求也会迅速被批准。在区分功能的变更时，也可以更快的通过审批。

恰当的提交信息

“恰当的提交信息是什么样的？”。这是我过去老生常谈的问题。我肯定迟早要写一篇关于我对优秀提交信息的看法的文章。根据我的经验，提交信息应该提供代码本身不能提供的内容——上下文。

提交信息应该扼要概括做了什么。接着说明此次提交的原因。

下面是我今天写的一条提交信息（替换了一些内容，以免暴露敏感信息）：

修复：基于VAR_A而不是VAR_B的更新FEATURE A。

当FEATURE C中存在VAR_B时，出现一个bug。

这导致FEATURE C执行后，FEATURE A不能正常刷新。

在这种情况下，用户界面一直显示在加载中，这是由于端点返回“刷新”而不是“完成”。

当你熟悉代码库，你应该对提交包含的内容与原因心中有数。如果提交信息介绍得千奇百怪，你肯定能猜到这不是提交的本意。

经常提交，压缩和发布

这样做会给你带来很多好处（以下几点主观性非常强）。

1. 通过跟踪提交历史记录，你可以查看曾试图实现的目标。
2. 这些提交无需完美无瑕，我甚至觉得它们无需编译。
3. 随时推送变更至远程分支，因此就有了备份代码以防误操作（或电脑死机）。

“但这和你之前说的不矛盾了吗？”。

是矛盾了。

我的辩解是：这应该只是暂时的。在创建拉取请求前，请确保将所有的变更压缩至一个提交中。通过一些实践，你会发现这样一个提交已满足我在提交部分阐述的全部要求。

在对这个主题进行一些研究时，我发现了一个术语“香肠制作”（参见Set Robertson的文章）。这是一个非常棒的参考。

正如我们已意识到的，我们想做到原子提交。尽管如此，与之矛盾的经常提交还是好处多多。

香肠的生产过程是不透明的。我不想过分纠结细节。但当你看到香肠时，生产者会想尽一切办法隐藏生产过程。

同理，这对属于拉取请求一部分的提交同样适用。这些提交看起来光鲜亮丽，满足我们对原子提交的所有要求。

至此，我们已涵盖了很多内容。但对于如何成功一名优秀的git仓库使用者，仍需注意一些额外要点。

关于合并提交

我个人根本不用这个功能——但也有人使用，合情合理。但我认为这是类似“最喜爱的编辑器”或“制表符VS空格键”的争论，暂且这么放着不讨论吧。如果你想听建议，我提一个：团队制定流程，并执行下去。

不要重写共享分支的历史记录

这很必要！一旦重写历史记录，将会给共享此分支的同事带来麻烦。这样容易导致冲突，因此中断他们正常的工作流程。

请不要在共享分支上这么做。我的解决方案是，与公用特性分支的同事沟通好。大多情况下，我们先提交至本地分支，随后压缩所有分支再合并。

避免重要分支被重写

很多人共享的一个分支：MASTER。将该分支保护起来，是给自己也是给团队帮大忙了。

通过分支保护MASTER分支，任何人都不能重写它的历史记录。如果你想更进一步，甚至可以限制所有贡献者的MASTER权限。这意味着，贡献者必须通过代码评审流程（例如拉取请求）来合并代码，因此也额外需要至少一个人的审批。

不要提交占用空间大的二进制文件

我不想深入讨论DCVS（分布式代码版本系统）的缺点，但git不是专门用来保存二进制文件的。如果有大的二进制文件，建议直接找替代库来保存。

通常来说，从有二进制文件的仓库中拉取代码会更慢，且Git的通用性能也会降低。如果需要对二进制文件进行版本控制，可考虑git LFS或者切换到SVN。

不要提交生成的文件

这与上一点有些联系。提交生成的文件降低了仓库容量。更何况它们也没有额外价值。如果这些文件经常被重新生成，那真是非常糟糕了。

总结

将来可能会扩展此列表。

但现在就先列这么多。我真希望本文git最佳实践能得到你的点头赞许，而不是看不出喜恶。遵循这些建议可能有助于在git中找到你和你的团队想要的东西。

原文：https://programmerfriend.com/index.php/2019/03/01/git-best-practices/

本文为 CSDN 翻译，如需转载，请注明来源出处。作者独立观点，不代表 CSDN 立场。