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

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

代码管理规范:是作为技术开发人员必须要关注和执行的内容。
代码作为技术开发人员的首要资产,一定是要作为重中之重来管理。

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

代码版本控制系统:是对代码版本最基本的版本管理。
选择好的代码版本控制系统,是进行技术开发的前提条件。

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

wikipedia-version-control-software-list

其实就以往的经验来说,大部分公司选择 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 仓库命名:要有一个规则的格式和良好的命名。
一个好的仓库命名,能够更直观的看出这个仓库的代码类型和产品内容。

个人一直在移动互联网公司从事技术相关的工作。我的一些针对 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 分支管理,是重要的开始。
磨刀不误砍柴工。

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

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

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

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

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

打赏
本博客所有文章如无特别注明均为原创。复制或转载请以超链接形式注明转自ifeegoo,原文地址《推荐的代码管理规范
上一篇: « 下一篇: »
暂无相关文章
Copyright © ifeegoo Time is limited, less is more! / 粤ICP备15109713号 / Theme by Hang & Ben / WordPress / 知识共享许可协议