git分支规范

前言

本文主要描述敏捷开发模式下（同仓库&多人并行多项目）的分支管理规范，本来很不想写这篇文章，这些内容其实在6-7年前敏捷开发概念提出的时候就应该成熟了，最近遇到很多同学总是搞不清发布/测试分支的用途或者说对分支的一些误操作，稍微整理了如下。
节末另附有一些常用git命令供参考。

分支规范

发布分支

发布分支根据需要设置protected

环境	分支
prod	master
st	buildst
uat	builduat

所有build分支为敏捷开发需要，不涉及的情况下可以用develop分支代替。

开发分支

功能点	分支命名1	分支命名2
app版本	5.0.0
迭代版本	college450
功能开发	feature-	功能点 cart 时间点 20180802
问题修复	hotfix-

开发流程

1. master分支 git pull 保证本地代码与远程一致为最新
2. git checkout -b branchName
3. git push -u origin branchName
4. 开发&自测
5. 发mr（merge request） branchName -> builduat/buildst/master
6. CI/CD 发布
7. 打tag

注意事项

• 避免直接在发布分支修改
• 发布分支产生冲突时，从发布分支切出新分支合并冲突，新分支合完发布分支后删除新分支
• 所有build分支不能作为mr的源头
• 所有开发分支应从master切出

其它

• 条件允许的话，用release分支代替master发布，由CI/CD将release合到master
• 走版本迭代时，可以将>20PD(可自定义)的功能作为feature分支分开，避免产生功能延期的窘境

git命令技巧

cherry-pick

合并另一个分支的单个代码提交记录

git cherry-pick <commitHash>

支持一次性合并多个提交

git cherry-pick <commitHashA> <commitHashB>

merge

场景

需要合并一系列相连的commits
（假设branch为master->commitHashA...->commitHashD，合并中间段commits B~C）

// 指明终点commit
branch: 
git checkout -b newbranch <commitHashC> 
// 指明起点commit
master: 
git merge newbranch <commitHashB>^

场景

merge只有在冲突的时候，解决完冲突才会自动生成一个合并commit
如果想在没有冲突的情况下也自动生成一个commit

git merge --no-ff

clean

删除未跟踪文件

场景

在CI/CD过程中build报错，后经排查是底层框架演变造成，新框架被旧框架生成的编译文件影响，在build前执行clean命令解决。

git clean -fdx

• -f untracked files
• -d untracked directories
• -x untracked in .gitignore

prune

清除本地track过的已被删除的远程分支

git remote prune origin

stash

临时保存和恢复修改

场景

开发任务进行到一半时需要切换分支hotfix，又不想生成新的commit造成污染

git stash -u
git stash pop

reset & revert

// 创建一个新的commit来撤消该commit，不会影响历史记录
git revert <commitHash>
// 将HEAD指针移动到该commit，会影响该commit之后的记录
git reset <commitHash>
// --hard 工作区、暂存区都恢复到<commitHash>节点
## 场景： 放弃所有<commitHash>后的改动
// --soft 工作区、暂存区都不会被修改
## 场景： 合并所有<commitHash>后的commit记录(可能是阶段性地频繁提交)