Git团队协作规范

Git团队协作规范

为什么要使用Git

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

分支约定

主分支

• master 分支原则

• master分支存放的是随时可供在生产环境中部署的稳定版本代码
• 一个项目只能有一个master分支
• 仅在发布新的可供部署的代码时才更新master分支上的代码
• 每次更新master，都需对master添加指定格式的tag(git tag -a v0.0.1)，用于发布或回滚。
• master分支代码只能被release/分支或hotfix分支合并，意味着不能在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

下图为分支管理的模型图

git工作流.png

使用规范

commit使用基本要求

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

--no-ff 的作用

默认情况下,Git执行“快进式合并(fast-farward merge)”,会直接将Master分支指向dev分支。使用了--no-ff参数后，会执行正常的合并，在Master分支上生成一个新节点。所以为了保证版本的演进的清晰，我们希望采用这种做法。

git merge --no-ff release

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

常见命令语句

• 创建切换dev分支

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

• 提交代码

git ci -a -m "des"// 可以将git add . 和 git ci 命令合为一体

• feature/test开发分支合并到release分支，并删掉开发分支

git co release 
git merge --no-off feature/test  // 采用--no-off 的合并模式
git br -d feature/test //删除本地分支 但是如果没有merge git会提示你改用大写D
git push origin :feature/test  //删除远程分支
git push origin --delete feature/test  //这样也能删掉远程分支

• 版本上线后master 分支打tag

git tag -a 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版本团队内部操作规范