Git团队协作规范
2020-02-21 本文已影响0人
i5yue
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.修订号：当做了向下兼容的问题修正
