标签：git develop 修复 规范 Git master release 分支
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
- 推送代码
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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。