推荐的代码管理规范 2019-07-11 / 5,634 次 / 沙发被抢 / 28

代码管理是有技术开发的公司首要考虑的问题。

作为多年的技术开发人员，能够深刻体会到代码管理的重要性，曾经对代码管理的不了解导致的代码丢失，由于公司服务器提供商的问题导致代码的丢失，这些问题还历历在目。那么我们要如何整理好代码呢？有以下一些推荐的参考方法；

从维基百科里面针对版本控制软件的列表中，我们可以看到版本控制软件的类型可以分为：本地/客户端与服务端/分布式三种类型。

其实就以往的经验来说，大部分公司选择 SVN 和 Git，就目前流行趋势来说，比如程序员越来越依赖的 GitHub，让我们倾向于选择 Git。Git 早期也是由大神 Linus Torvalds 开发的，为了更好的管理代码。所以我觉得我们应该顺势而为：选择 Git 作为代码版本控制系统。

其实目前针对代码管理系统的选择，只有三种较为合适：公网 GitHub/GitLab，私有化部署 GitLab。其他的诸如简要针对 Git 仓库的简单管理程序或者诸如 Gitea 或者国内的代码托管服务：Gitee，目前我个人还是不推荐的。简单的管理程序是不满足后续进行各种高效生产力写作的，其他私有化部署的实力不如 GitLab（背后有 Google 这个大佬支持），国内目前还没有看到可以私有化部署的代码管理系统。

如果你是开发开源项目，那么毫无疑问，强烈推荐 github.com，作为开源界的首选，这样的平台能够给你带来更多的流量。如果你是个人开发私有项目，可以托管到 github.com 上面，也可以托管到 gitlab.com。两者目前均支持私有仓库，但是目前在多人协作上面有些差别。

如果公司项目非常多，而且代码对安全性有一定的要求，强烈推荐进行 GitLab 私有化部署。这个是目前很多公司采取的方式。自己可以完全掌控。只要公司有对 GitLab 这块私有化部署和数据备份很熟悉的情况下，就可以使用 GitLab 私有化部署来实现代码管理系统的搭建，如果没有人会这块，那么可以使用 gitlab.com 的私有仓库，阶段性的本地备份 Git 仓库即可。

表 1：推荐的代码管理系统

代码管理系统	适合人群	场景	数据备份
GitHub.com	个人/企业	[个人/企业开源][个人私有]	Git 仓库备份
GitLab.com	个人/企业	[个人/企业私有]	Git 仓库备份
GitLab 私有化部署	企业	[企业私有]	GitLab 备份机制/Git 仓库备份

个人一直在移动互联网公司从事技术相关的工作。我的一些针对 Git 仓库命名的看法如下：
1.仓库名称采用全部小写英文字母，避免数字打头。中间用横杠隔开每个单词。
2.仓库项目类别英文名称打头，例如：
android:安卓项目。
ios:iOS 项目。
back-end:后端相关项目：服务器程序等。
front-end:前端相关项目：小程序、Web 程序等。
3.第二级别，我们区分：
app/lib/demo/module：针对 Android/iOS 项目区分应用/库/Demo/Module。
server/lib/demo/module：针对后端项目区分的服务器/库/Demo/Module。
[mini-program|web]/lib/demo/module：针对前端的项目区分
备注：module 这个可以理解为有些大型项目采用多仓库开发，每个 module 一个仓库，采用仓库依赖的方式，我们使用 Git Submodule 或者 Git Subtree 的这个功能。
4.第三级别，不同厂家，举例：
alibaba/tencent/baidu。
5.第四级别，项目产品类型区分，举例：
bluetooth-smart-sound-box：蓝牙智能音箱。
wifi-smart-story-machine：Wi-Fi 智能故事机。
6.第五级别，项目名称区分，举例：
ilight/yizhiting。
7.第六级别，若有大版本区分，举例：
v1/v2/v3。
8.第七级别，若有开发语言/架构/框架区分，举例：
java/kotlin/objective-c/swift。
9.第八级别，若有架构框架区分，举例：
mvc/mvvm/mvp

举例：
android-app-alibaba-bluetooth-smart-sound-box-ilight-v1-kotiln-mvp
用 MVP 架构、 Kotlin 语言开发的第一个大版本的 Android 名叫 ilight 的针对阿里巴巴的智能音箱 App 项目。

另外：项目产品文档、交互文档、测试文档、技术文档也可以用 Git 仓库来统一进行版本管理，仓库命名格式推荐采用：documentation + 厂商 + 项目名称 即可！

其他：项目的设计文档：设计原图、设计效果图/标注图、设计切图，均可以采用 Git 仓库来进行统一版本管理。仓库命名格式推荐采用 design + 厂商 + 项目名称 即可！

说明：以上 Git 仓库命名方式比较适合项目比较多的公司，例如：外包公司，自己产品线非常广的公司。

对于 Git 命令行操作的方式，还没有达到很熟练的情况下，针对重要的项目，建议大家使用 Git 可视化管理工具，比如目前最好用的 SourceTree。这样对于 Git 命令行操作不熟悉的开发者，对于 Git 的管理很容易上路。

其次一定要针对不同项目，配置好 .gitignore 文件，如果这个文件没有配置好，不仅会使整个 Git 仓库会 track 一些无需 track 的文件，导致仓库变大，另外一个还可能会导致项目编译运行出现问题。其他的一些细节我们也是需要注意：全局 .gitignore 文件，一般可视化管理工具里面有配置。要将 Git 默认忽略文件名称大小写修改成对文件名称大小写敏感，这是一个非常重要的小细节。

另外一个，最为重要的就是要有自己的一套 Git 仓库分支管理原则，我们不一定要使用比较专业的 Gitflow 分支模型，针对小项目，小团队（单个项目 2-3 个人左右团队开发），只要有自己的一套合理的分支管理方法，都是可以被认可的，关键是要有统一的标准。

超大型的项目，需要控制代码阅读权限的项目，以及需要分模块仓库来开发的项目，我们可以使用 Git Submodule 或 Git Subtree 功能，可以使仓库依赖另外仓库。或者采用项目打成库，然后做远程依赖的方式，可以很好的解决以上相关问题。

以上便是我个人针对代码管理的一些认知，若有新方法与收获，再持续更新！

上一篇： « 会议：不仅仅是一群人聚集在一起说话 下一篇： WordPress 的安装和数据备份及迁移 »