首页 > 其他分享> > Git 分支管理规范

Git 分支管理规范

2022-06-10 14:05:25 作者：互联网

Git-Bash 最佳指引手册

每个人都应当遵循对于分支命名、标记和编码的规范。每个组织都有自己的规范或者最佳实践，并且很多建议都可以从网上免费获取，而重要的是尽早选择合适的规范并在团队中遵循。

概述

DEV 环境用于开发者调试使用。
UAT 环境用户验收测试环境，用于生产环境下的软件测试者测试使用。
FAT 环境功能验收测试环境，用于测试环境下的软件测试者测试使用。
PRO 环境生产环境。

项目域名为：http://www.jinmaocloud.com，相关环境的域名可这样配置：

DEV 环境：本地配置虚拟域名即可
FAT 环境：http://fat.jinmaocloud.com
UAT 环境：http://uat.jinmaocloud.com
PRO 环境：http://www.jinmaocloud.com

分支

分支	名称	环境	可访问
master	主分支	PRO	是
release	预上线分支	UAT	是
hotfix	紧急修复分支	DEV	否
develop	测试分支	FAT	是
feature	需求开发分支	DEV	否

master 分支

master 为主分支，用于部署到正式环境（PRO），一般由 release 或 hotfix 分支合并，任何情况下不允许直接在 master 分支上修改代码。

release 分支

release 为预上线分支，用于部署到预上线环境（UAT），始终保持与 master 分支一致，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。
如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。

hotfix 分支

hotfix 为紧急修复分支，命名规则为 hotfix- 开头。
当线上出现紧急问题需要马上修复时，需要基于 release 或 master 分支创建 hotfix 分支，修复完成后，再合并到 release 或 develop 分支，一旦修复上线，便将其删除。

develop 分支

develop 为测试分支，用于部署到测试环境（FAT），始终保持最新完成以及 bug 修复后的代码，可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发。

一定是满足测试的代码才能往上面合并或提交。

feature 分支

feature 为需求开发分支，命名规则为 feature- 开头，一旦该需求上线，便将其删除。

这么说可能有点不容易理解，接下来举几个开发场景。

开发场景

新需求加入

有一个订单管理的新需求需要开发，首先要创建一个 feature-order 分支，问题来了，该分支是基于哪个分支创建？
如果存在未测试完毕的需求，就基于 master 创建。
如果不存在未测试完毕的需求，就基于 develop 创建。

需求在 feature-order 分支开发完毕，准备提测时，要先确定 develop 不存在未测试完毕的需求，这时研发人员才能将将代码合并到 develop （测试环境）供测试人员测试。

测试人员在 develop （测试环境）测试通过后，研发人员再将代码发布到 release （预上线环境）供测试人员测试。
测试人员在 release （预上线环境）测试通过后，研发人员再将代码发布到 master （正式环境）供测试人员测试。
测试人员在 master (正式环境) 测试通过后，研发人员需要删除 feature-order 分支。

普通迭代

有一个订单管理的迭代需求，如果开发工时 < 1 天，直接在 develop 开发，如果开发工时 > 1 天，那就需要创建分支，在分支上开发。

开发后的提测上线流程与新需求加入的流程一致。

修复测试环境 Bug

在 develop 测试出现了 Bug，如果修复工时 < 2h，直接在 develop 修复，如果修复工时 > 2h，需要在分支上修复。

修复后的提测上线流程与新需求加入的流程一致。

修改预上线环境 Bug

在 release 测试出现了 Bug，首先要回归下 develop 分支是否同样存在这个问题。

如果存在，修复流程与修复测试环境 Bug 流程一致。

如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。

修改正式环境 Bug

在 master 测试出现了 Bug，首先要回归下 release 和 develop 分支是否同样存在这个问题。

如果存在，修复流程与修复测试环境 Bug 流程一致。

如果不存在，这种可能性也比较少，大部分是数据兼容问题，环境配置问题等。

紧急修复正式环境 Bug

需求在测试环节未测试出 Bug，上线运行一段时候后出现了 Bug，需要紧急修复的。
我个人理解紧急修复的意思是没时间验证测试环境了，但还是建议验证下预上线环境。

如果 release 分支存在未测试完毕的需求，就基于 master 创建 hotfix-xxx 分支，修复完毕后发布到 master 验证，验证完毕后，将 master 代码合并到 release 和 develop 分支，同时删掉 hotfix-xxx 分支。
如果 release 分支不存在未测试完毕的需求，但 develop 分支存在未测试完毕的需求，就基于 release 创建 hotfix-xxx 分支，修复完毕后发布到 release 验证，后面流程与上线流程一致，验证完毕后，将 master 代码合并到 develop 分支，同时删掉 hotfix-xxx 分支。
如果 release 和 develop 分支都不存在未测试完毕的需求，就直接在 develop 分支上修复完毕后，发布到 release 验证，后面流程与上线流程一致。

检出代码的姿势

检出远程仓库

git clone https://github.com/jmyf/Git-Bash.git

可以检出 origin/main 分支到本地，这是 GitHub 创建仓库时默认的主机名/分支名。使用 git branch -vv 查看本地分支状态

本地分支名为 main，关联的远程分支名为 origin/main（origin 是主机名，main 是分支名

检出远程分支

一个项目需要新建很多远程分支，以便于并行开发

同步远程分支

检出远程分支

提交代码的姿势

永远不要在一个本地分支上，连续提交代码。在多人协作的情况下，这会导致每笔提交之间存在依赖关系，进而可能导致 merge 冲突、cherry-pick 合入冗余代码。

暂存代码

git stash save [-u] 'update readme.md'

[-u] 表示参数可选，加 -u 会将本地新增文件也暂存，不加则仅暂存本地修改部分。'update readme.md' 为描述，下面列出 git stash 支持的所有操作：
- git stash list 显示所有暂存记录
- git stash show stash@{0} 查看指定的暂存记录
- git stash pop stash@{0} 弹出指定的暂存记录
- git stash drop stash@{0} 删除指定的暂存记录
- git stash clear 清空暂存记录
同步代码

git pull --rebase
弹出暂存代码

git stash pop [stash@{0}]

[stash@{0}] 表示可选，不加默认弹出栈顶元素，也可以指定弹出哪一个暂存记录。弹出结果如下：
新建本地分支

根据不同功能新建不同的本地分支，比如 feature_shopping，bugfix_tombstone 等等，假设我们现在需要实现一个购物功能，我们应该使用 git checkout -b feature_shopping 新建一个本地分支来实现这个需求：

提交代码

git commit -m "update README.md" 表示将修改提交到本地仓库，此时还没有推送到远程仓库。-m 后面的是修改描述，这是一种简便写法。

追加提交

commit 之后，本地又修改了一些文件，此时需要使用 git commit --amend 追加提交：

回退提交

commit 之后，发现提交多了，把不需要提交的也提交了，此时需要回退，有两种方式：

git reset [--soft] commit_id，软回退，不会丢弃文件修改记录，--soft 不加也可以。
git reset --hard commit_id，硬回退，丢弃所有修改。一般仅在需要回退到指定节点验证问题时使用。

查看 commit_id：

  git log -1

-1 表示只查看提交记录里的最后一条：

输入 git reset 22d92a412e7ed6e72ee2107db891e7571d307c81，即可回退提交。然后重新 git add ...，git commit。

推送代码

commit 之后很多人就直接 git push 了，这是不对的，应当先同步代码。由于我们现在在新建的本地分支 feature_shopping 上，这个分支没有关联远程分支，所以无法也不应该使用 git pull --rebase 来同步代码。正确的操作为：

git checkout master：切到本地主分支
git pull --rebase：同步代码
git checkout feature_shopping：切换到本地需求分支
git rebase master：将本地主分支代码，合入到本地需求分支（可能有冲突，按照 Git 的提示修复即可）
git push origin HEAD:refs/for/master：将本地需求分支的提交推送到远程 master 分支

标签：git,develop,修复,规范,Git,master,release,分支
来源： https://www.cnblogs.com/l3306/p/16362980.html