Git 版本控制系统规范

我们为什么选择 Git

目前如果你如果进行项目开发有一定规范,那么肯定会使用版本控制系统(Version Control System),目前比较流行两个就是 SVN 和 Git。Git有很多优点,其中很显著的一点,就是版本的分支(branch)和合并(merge)十分方便,相对也占用更少的硬盘空间。


我们的管理规范

我们公司使用了 Git + YouTrack 配合进行版本控制,我先简单说一下我们现在的流程规范(如果你还没用过 Git 可以跳过)。

首先,我们有一个主分支 Master,这里只有稳定的可用版本,Master 上的每个版本就是拿来可以用的对应版本号的发布版本(含已发布版本和待发布版本),Master 是不允许随意改动的。

第二,从 Master 唯一新建分支,开发分支 Develop,该项目所有开发者在完成新模块或修复异常等一个具体任务后,可以合并到 Develop 进行联合测试。

第三,从开发分支 Develop,以开发者名新建分支,如 gallon、sfs、jksfood 等,作为单个开发者的开发分支。

第四,从自己的开发分支(如 gallon)再新建分支(该分支通过 Android Studio 内置的 YouTrack 就会自动提示创建一个任务分支,前提是 AS 的 Git 要和远端仓库关联起来),现在只要把一个个 Task 任务发布到 YouTrack 就可以了,当这个任务完成后,需要你把任务分支合并到自己的分支(gallon),自己运行可以跑通(通常这里不会有任何问题,因为理论上 gallon 是一直低于任务分支版本的)之后再提交到 develop 分支上,让 Android 组长或负责人或测试人员去检验,如果没有问题到此这个任务就算是 done 了。

我自己的使用感受

以上看起来步步都很清晰,你在什么阶段在什么分支上做什么事,但是,我们来想这么一个情况,如果我有两个 Task 但是他们有很多重叠代码,我可以去同时做这两个任务,但是根据管理规范你只应该在一个分支上专注你的那个 Task,而且领导只知道看 YouTrack 上已经确定好的一条条任务给你做绩效评定呢,结果新建了两个任务分支 A 和 B,你猜的到的,效率会非常低,但是也有一点好处,你能更加专注的做好这一个任务,想想规范一些也不错,那么还有另外一种情况,突然又有新的需要优先去处理的 Task,你需要先把当前的任务分支本地提交,注意,这时因为该任务没完成,我们通常不会把这个任务分支 A 合并到 gallon 分支(正确的做法是该任务完成后合并),然后切换到 gallon 分支,然后创建新任务分支 B,这时候 B 是落后 A 版本的,你在分支 A 中修改的代码都不能在分支 B 中看到,但如果有些你需要用到的代码,是的,要么在 B 中重新写一份(可能还是要小小的解决一下冲突),要么等两个任务都完成了,合并后再修改重叠部分,如果有些情况你常常要在任务分支 A 和任务分支 B 跳来跳去,那可能结果是你要不停解决你自己的冲突,听起来是不是很好笑?好吧,我可能是做惯了多线程操作,常常同一时间做几个任务,修复一个小异常或调整布局与开发新功能等同时进行。这种规范对我的编程可以说是加了限制。

但是,我仍然觉得这种规范是很有道理和有必要的,虽然刚开始使用看起来步骤繁多,甚至可能是稍微降低效率的,可是这种规范对任务的按预期可控推进依然起到了非常重要的作用,对安全性也提供了很大的保证。以后我会建议分配到个人的多个小任务也可以写到一个 Task 当中去,这样也在保证这种规范的情况下,更好的提高效率嘛。

然而这样就是最先进的或最规范的管理方法了吗?我不知道,有的公司是没有我提到的个人分支的,只需要在 develop 上创建新的任务分支;我之前的公司则是只要在 develop 上进行开发就行。也许只有适合自己(团队)的,才是最好的。当然,如果你现在连 Git 都还没体验过,肯定是看的一头雾水,赶紧去试试吧!

你可能感兴趣的:(Git 版本控制系统规范)