优秀的Git仓库管理实践

如果你正在考虑将二进制大文件(BLOB)提交到仓库，请停下来先思考一下。如果它是二进制文件，那它是由什么生成的。是否有充分的理由不在构建时生成它们，而是将它们提交到仓库?如果你认为提交二进制数据是有意义的，请确保在 README 文件或类似文件中指明二进制文件的位置、为什么是二进制文件的原因以及更新它们的协议是什么。必须谨慎对其更新，因为你每提交一个二进制大文件的变化，它的存储空间实际上都会加倍。

让第三方库留在第三方

第三方库也不例外。尽管它是开源的众多优点之一，你可以不受限制地重用和重新分发不是你编写的代码，但是有很多充分的理由不把第三方库存储在你自己的仓库中。首先，除非你自己检查了所有代码(以及将来的合并)，否则你不能为第三方完全担保。其次，当你将第三方库复制到你的 Git 仓库中时，会将焦点从真正的上游源代码中分离出来。从技术上讲，对库有信心的人只对该库的主副本有把握，而不是对随机仓库的副本有把握。如果你需要锁定特定版本的库，请给开发者提供一个合理的项目所需的发布 URL，或者使用 Git 子模块果你的项目已编译，请抵制住使用 git add . 的冲动(其中 . 是当前目录或特定文件夹的路径)，因为这是一种添加任何新东西的简单方法。如果你不是手动编译项目，而是使用 IDE 为你管理项目，这一点尤其重要。用 IDE 管理项目时，跟踪添加到仓库中的内容会非常困难，因此仅添加你实际编写的内容非常重要，而不是添加项目文件夹中出现的任何新对象。

如果你使用了 git add .，请在推送之前检查暂存区里的内容。如果在运行 make clean 或等效命令后，执行 git status 时在项目文件夹中看到一个陌生的对象，请找出它的来源，以及为什么仍然在项目的目录中。这是一种罕见的构建工件，不会在编译期间重新生成，因此在提交前请三思。

（编辑：鹤壁站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!