Git分支管理规范

前言:

前几天,突然想起以前接触的项目,就想拉取下来看看,可是由于以前对代码的管理不注重规范化,提交记录也是随意添加提交msg,导致查找十分的不方便,就算使用 git log命令也不知道自己需要的是在那一次提交记录中.......最后就机械的从每一个分支和tag上pull,就这样折腾了好久才找到了自己需要的资料。介于这种情况,今天,闲来没事,就来谈谈git分支管理规范吧,希望对大家工作以及项目的管理有一定的帮助。

个人认为,管理好自己的项目,不仅是自己对自己负责任的体现,也是对同事的负责(毕竟现在不是一个人开发,涉及团队合作开发,那么标准化的管理时高效工作的第一步),更能体现一个人对工作对生活的严谨......如果你和我一样,希望从今天开始,就要更加的严格要求自己对项目的标准化的管理,这是一种自我的提高,也是走上项目管理必不可少的一个环节。

如何管理自己的项目:

在使用git管理我们项目的时候,个人觉得至少要严格遵守以下原则,当然只是个人愚见,希望大家有更好的管理规范原则。

分支命名不能包含中文,英文不行就用全拼,不要在乎长度。

不同渠道或不同语种的版本,应该通过工程配置来区分打包,用架构设计来消灭“不同版本使用不同分支”的做法。

分支既然叫“分支”,就是要被“修剪”的。达成目的后的分支都该删除,否则就像僵尸代码。

每次commit,要标准和准确的描述做了什么,改了什么,删除了什么,新增了什么,切不可以随意commit msg。

tag只能适用用稳定的版本,比如v.1.0版本核心功能是加入了资金托管,并且基本定型稳定,没有bug,已经发布应用市场,而v.2.0则是加入了银行存管,有别于v.1.0这个版本的业务,同时该版本也是和v.1.0一样没有任何bug,并且已经发布应用市场,以此类推到第n个版本。

不要随意修改主分支master。

管理命名规范:

master(主干):

上肯定是最近一个发布版本的代码。每个版本发布后,从版本分支合并或变基而来。

版本分支

在版本立项后开出。需注意分支名中的版本号中不包括构建号(build code),打tag时才包括。因为有些hotfix或灰度发布并不会修改版本号,只改动构建号。这样的hotfix应继续在该版本分支上开发,并在打tag时用构建号区分。

在版本提测前,所有在此版本发布的需求分支都要合并过来。

正在开发的版本分支可在下个版本发布后删除。例如分支应在发布后删除,或在开出时删除。要找回该版本的代码,应从Tag里面找。实际操作中不删除也可以。

需求分支

在快速迭代的开发过程中,需求确立时未必就确定了在哪个版本,所以需求分支名不包括版本号。需求分支可从任何节点开出,为了减少后续合并麻烦,一般基于版本分支开出,或在开发过程中做变基操作。

如果公司的资源足够多,需求分支可在做完本需求的测试后再合入版本分支。

合入版本分支后,此需求分支应删除,在log中体现该需求。

个人分支

一个需求如果由多个人完成且代码修改范围交集较小,则每个人可以从需求分支开出个人分支做开发,完成后合并回需求分支。合并后,个人分支应删除。

解bug也在个人分支中进行。完成验证后,合并到版本分支并删除。

个人分支也可以用作研究和试验用途。有结论后应把有意义的试验代码通过文档来体现,然后删除此个人分支,否则可能过一段时间后也没人知道这是干嘛的了。

Tag

需注意tag名包含构建号;时间戳精确到分钟,年不要20前缀。保证信息充足的前提下尽量简短。

tag应该都是从版本分支打出,需求独立提测也可以在需求分支打出。提测或者发布版本时都要打tag。通过时间戳来看哪个是最后一版。

发布后,没用作发布的tag都应该删除。

特殊分支

各种莫(shen)名(jing)其(bing)妙的需求都有,特殊分支还是有存在的必要的,例如做个马甲版。一般特殊分支也是要发布的,但不会多次迭代。如果也迭代了几个版本,那么也可以参考主版本有多级结构。例如。

友情链接

git常用命令大全小编整理一下,大概如下

总结:

好了,这就是个人对git使用管理的初步认识,和使用心得,希望可以帮助到一些初级入门的开发者,写的不好的地方,欢迎大家指出,并留言,让我们人人都可以成为一个合格的开发者,甚至,项目管理者。。。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180708G024FK00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券

玩转腾讯云 有奖征文活动