Git团队协作规范

为什么要使用Git

为什么要用git?我觉得不要我多说多了吧，因为大家都在用呀，用起来就是爽！！！所以下面介绍点学习git资料，让你爱上学习。话说被大伙称为git圣经，让猴子教你来学习下吧，同时来通过Learn Git Branching来玩下通关的刺激吧。git的相关资料大家自己再找时间去学习，接下来大家主要看下面关于我们git作业的一些相关规定，请仔细阅读，牢记在心，避免工作中踩坑。

分支约定

主分支

master 分支原则

master分支存放的是随时可供在生产环境中部署的稳定版本代码

一个项目只能有一个master分支

仅在发布新的可供部署的代码时才更新master分支上的代码

每次更新master，都需对master添加指定格式的tag(git tag -a v0.0.1 -m "填写描述")，用于发布或回滚。

master分支代码只能被release/*分支或hotfix或开发分支feature/*分支合并，意味着不能在master分支上直接修改代码

release分支

只能衍生于master分支命名规则：release/*，“*”以本次发布的版本号为标识,比如我们的月度版本release/2020.2.27,但一般项目稳定情况下，用release作为分支名即可。

release主要是为发布正式新版本做准备，代码的合并(merge)都来源于我们已经验证好并确定要上正式的开发分支feature/*。

一旦成功上线，就要回归到master分支(负责发版的小伙伴来做这个动作)，如果在release版本期间有修复改动（比如说上线前的小缺陷），也要回归到dev分支

dev

dev分支是保存了测试环境最新的开发成果的分支

一个项目只能有一个dev分支

dev分支主要是针对的测试版本的发布，项目初次开发，还是允许在此分支开发，一旦有线上版本，后面的开发都必须从master或者release分支切一个分支出去开发（feature/*）。

dev 作为为测试环境验证分支，主要是为了满足多人同时开发多个需求时的场景。从master分支切换过来，但是不会回归master分支，也不能在此分支上修改代码，此分支只用于测试环境的发版。

开发分支（feature分支）

这个分支是针对新功能（新需求或版本迭代）的开发从master分支分叉出来的
命名规则feature/* 例如：feature/install 安装需求
此分支一般不需要提交到远程，但如果此项目本地分支比较多，还是建议提交远程，因为有丢失.git 文件风险（我就遇到过）
每个feature/*分支颗粒度要尽量下，比如一次只针对一个需求或者一个功能，但是如果自己比较明确两个需求能够同时验证和上线，那么颗粒度也能适当放宽。
开发完成后，如果此项目只有目前一个需求等待验证，那么直接用此分支发布测试验证即可，如果有多个需求，而且是不同人在开发，请合并到dev分支发布验证。当需求验证通过后，再将此分支合并到release或者master(单独一个人开发开发，没有release分支的情况下)分支。
feature分支只与release分支交互，不能与dev和master分支直接交互
当功能因为各种原因不能开发；或者废弃了；或者已经完整上线，就直接删除这个分支，如果提交到了远程，也一并删除

hotfix分支

命名规则：hotfix/* 如果是短小快速的分支，也可以用hotfix作为名称即可
hotfix分支用来快速给已发布产品修复bug或微调功能
从master分支或者release/*分支衍生出来
修复好后，先合并到dev分支验证。验证通过后需要回归master
hotfix分支一旦建立就将独立，不可再从其他分支pull代码

bugfix分支

命名规则： bugfix/* 如果是短小快速的分支，也可以用bugfix作为名称即可
bugfix分支用来快速给未上线产品或者迭代需求修复bug或微调功能
从master分支或者release分支或者对应的开发分支feature/*衍生出来
修复好后，先合并到 dev 分支验证。验证通过后需要回归release 和master

下图为分支管理的模型图

开发场景

实际开发中，我们所遇到的开发情况要比较多，有可能项目只有一个人开发，或者多人开发，或者存在一个项目同时要开发多个需求，这些需求之间又是项目独立的，其实分支管理跟实际的开发人数没有直接关系，跟开发的需求节点有直接关系，多人开发一个需求与一个人开发一个需求的分支管理是一样的，只是我们需要遵循下代码的提交规范，然后一个人开发多个需求与多个人开发多个需求其实也是一样的开发场景，下面我们来对这些场景逐一分析下。

开发新项目或者此时项目只有一个需求

一个人开发

我们很多小项目都是一个人开发，分支管理根据个人原因可能就会存在很多情况，但是基本的规范还是要遵循到位，以免给后人留坑。
如果开发新项目，此时你在master或者dev分支开发都没有关系，项目上线后，需要将最新代码全部pull到远程仓库master分支
如果是迭代需求，那么从master切一个feature/*（关于分命名请查看上面关于feature分支的约定）出来开发，禁止在master分支开发，开发完上线后，请及时回归master分支

多人开发

多人开发一个需求时，这时候一般都是在同一个分支上开发，如果遇到冲突，相互沟通看看用谁的代码
同样的，如果是开发新项目，此时你们在master或者dev分支开发都没有关系，项目上线后，需要将最新代码全部push到远程仓库master分支
同样的如果是迭代需求，那么从master切一个feature/*（关于分命名请查看上面关于feature分支的约定）出来开发，然后大家沟通统一好，，禁止在master分支开发，开发完上线后，请及时回归master分支

tips

大家开发迭代需求时，应该都比较喜欢直接在dev开发，当你开发完并且在测试的时候，突然产品又新增了一个需求，而且这个需求要比前面那个需求提前上线，这个时候你就只能再切两个分支出来，一个是开发突然新增需求的分支，一个是需要测试环境发版的分支。所以为了避免这样的情况发生，建议大家按照上面分支的约定，我们所有的开发需求分支都命名为feature/*

一个项目同时存在多个需求同时开发

一个人开发很多个需求

一个人同时在一个项目上开发多个需求，一般对于承接多个业务系统的项目遇见的比较多，笔者有幸遇见这样的项目，一个人同时开发6、7个小需求，我需要在本地同时为每个需求创建一个feature/*分支
由于这些分支有的在开发中，有的已经需要测试，所以需要一个测试分支（dev）来合并所有开发分支，用这个测试分支（dev）来进行测试环境的发布
尤其记得每个需求的代码改动只能在对应的那个开发分支（feature/*）上改动，绝对不允许在测试分支（dev）上改动

多人开发不同的需求

多人在一个项目中开发不同的需求，其实跟一个人开发多个需求的操作是一样的，只是每个人管理的分支就没有那么多，代码写错分支的情况就不容易发生
多人开发，难免存在冲突，尤其记得如果不确定是自己修改的，合并代码时发生了冲突，一定要和团队沟通，解决好冲突
同样的每个人的开发分支的代码需要合并到测试分支（dev）,同时习惯性的提交到远程，避免其他人打包时没有拉取到代码

tips

本地的分支代码最好都提交到远程，避免发生丢失代码的风险。同时当开发分支完成使命后也要记得及时删除本地和远程开发分支。

git 相关命令脚本

配置别名

以下命令将status checkout commit branch 单词缩减为st co ci br,并且是全局作用。具体可以参考配置别名

 git config --global alias.st status
 git config --global alias.co checkout
 git config --global alias.ci commit
 git config --global alias.br branch

//  以后 你就可以愉快使用简单命令了
git st 代替 git status
git co 代替 git checkout
git ci 代替 git commit
git br 代替 git branch

git命令开发的流程

1、gitlab 创建项目（具体参看gitlab创建项目规范）

2、 clone 项目

// SSH
git clone git@git.midea.com:xxxxxxx
// HTTP
git clone http://git.midea.com/XXXXXXXX

3、创建分支

// 创建dev分支
git br -b dev
// 从当前分支切换到dev分支
git co dev

// 创建和切换合并为一个命令 如果当前处在master分支，那最后一个参数可以不填。此命令的效果是创建dev分支，并切换到dev分支
git co -b dev master
git co -b feature/test master  //创建feature/test 分支

4、提交代码到暂存区域

//commit使用基本要求 特别注意
//所有commit必须有注释，内容必须简洁明了的描述本次commit涵盖了哪些内容。 **严禁注释内容过于简单或不能明确表达提交内容的！**
//合理控制提交内容的颗粒度，一次commit含一个独立功能点。严禁一次提交涵盖多个功能项。

// 跟踪文件
git add .
// 或者跟踪指定文件
git add test.js
// 提交到暂存区域,记录提交记录
git ci -m "更新文件"
// 将两个命令合并成一个
git ci -a -m "更新文件" //此合并命令只用于已经跟踪文件，没有跟踪的还是需要先使用git add .

5、拉取、提交远程代码

// 拉取远程分支
git pull //将当前分支的远程仓库代码 以及远程所有分支名拉取下来，但是如果当前分支如果在远程没有被跟踪到的时候，git会提示错误信息
git pull origin dev //拉取远程指定分支
git push //提交到远程，同样的，如果当前分支没有被跟踪到，也是不允许提交的
git push origin dev

6、将feature/test分支代码合并到dev分支

// 先切换到dev 分支
git co dev
// 合并代码 采用--no-off 的合并模式
//  默认情况下,Git执行“快进式合并(fast-farward merge)”,会直接将Master分支指向dev分支。使用了--no-ff参数后，会执行正常的合并，在Master分支上生成一个新节点。所以为了保证版本的演进的清晰，我们希望采用这种做法。
git merge --no-off feature/test  
//删除本地分支 但是本地还有合并出去的commit  git会提示你改用大写D
git br -d feature/test 
//删除远程分支
git push origin :feature/test  
//这样也能删掉远程分支
git push origin --delete feature/test

7、版本上线后master 分支打tag

// 查看已经创建tag
git tag
// 创建tag
git tag -a v0.0.1 -m "填写描述"
// 查看指定tag的信息
git show v0.0.1

常用命令语句

查看已经commit的版本

git log
git log --pretty=oneline //简洁的方式
git log --oneline //更简洁的方式

回退版本

git reset --hard HEAD^ //回退上一个版本 HEAD^^意思就是上上个版本
// 如果要回到特定版本
git reset --hard *** //*** 表示上面git log 查询出来的哈希值

版本号简单说明（tag）

版本号（tag）命名规则：主版本号.次版本号.修订号，如下面 (遵循GitHub语义化版本命名规范)

  **v1.2.3**

1.主版本号：当新增或修改了不兼容的API操作

2.次版本号：当新增或者修改了向下的功能

3.修订号：当做了向下兼容的问题修正

参考资料

Git分支管理策略
常用 Git 命令清单
Git 工作流与规范
GIT版本团队内部操作规范