每个人都应当遵循对于分支命名、标记和编码的规范。每个组织都有自己的规范或者最佳实践，并且很多建议都可以从网上免费获取，而重要的是尽早选择合适的规范并在团队中遵循。
-
DEV 环境 用于开发者调试使用。
-
UAT 环境 用户验收测试环境，用于生产环境下的软件测试者测试使用。
-
FAT 环境 功能验收测试环境，用于测试环境下的软件测试者测试使用。
-
PRO 环境 生产环境。
-
项目域名为：http://www.abc.com，相关环境的域名可这样配置：
DEV 环境：本地配置虚拟域名即可 FAT 环境：http://fat.abc.com UAT 环境：http://uat.abc.com PRO 环境：http://www.abc.com
| 分支 | 名称 | 环境 | 可访问 |
|---|---|---|---|
| master | 主分支 | PRO | 是 |
| release | 预上线分支 | UAT | 是 |
| hotfix | 紧急修复分支 | DEV | 否 |
| develop | 测试分支 | FAT | 是 |
| feature | 需求开发分支 | DEV | 否 |
- master 为主分支，用于部署到正式环境（PRO），一般由 release 或 hotfix 分支合并，任何情况下不允许直接在 master 分支上修改代码。
-
release 为预上线分支，用于部署到预上线环境（UAT），始终保持与 master 分支一致，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。
-
如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。
- hotfix 为紧急修复分支，命名规则为 hotfix- 开头。 当线上出现紧急问题需要马上修复时，需要基于 release 或 master 分支创建 hotfix 分支，修复完成后，再合并到 release 或 develop 分支，一旦修复上线，便将其删除。
- develop 为测试分支，用于部署到测试环境（FAT），始终保持最新完成以及 bug 修复后的代码，可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发。
一定是满足测试的代码才能往上面合并或提交。
- feature 为需求开发分支，命名规则为 feature- 开头，一旦该需求上线，便将其删除。
这么说可能有点不容易理解，接下来举几个开发场景。
有一个订单管理的新需求需要开发，首先要创建一个 feature-order 分支，问题来了，该分支是基于哪个分支创建？ 如果 存在 未测试完毕的需求，就基于 master 创建。 如果 不存在 未测试完毕的需求，就基于 develop 创建。
需求在 feature-order 分支开发完毕，准备提测时，要先确定 develop 不存在未测试完毕的需求，这时研发人员才能将将代码合并到 develop （测试环境）供测试人员测试。
-
测试人员在 develop （测试环境） 测试通过后，研发人员再将代码发布到 release （预上线环境）供测试人员测试。
-
测试人员在 release （预上线环境）测试通过后，研发人员再将代码发布到 master （正式环境）供测试人员测试。
-
测试人员在 master (正式环境) 测试通过后，研发人员需要删除 feature-order 分支。
有一个订单管理的迭代需求，如果开发工时 < 1 天，直接在 develop 开发，如果开发工时 > 1 天，那就需要创建分支，在分支上开发。
开发后的提测上线流程 与 新需求加入的流程一致。
在 develop 测试出现了 Bug，如果修复工时 < 2h，直接在 develop 修复，如果修复工时 > 2h，需要在分支上修复。
修复后的提测上线流程 与 新需求加入的流程一致。
在 release 测试出现了 Bug，首先要回归下 develop 分支是否同样存在这个问题。
如果存在，修复流程 与 修复测试环境 Bug 流程一致。
如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。
在 master 测试出现了 Bug，首先要回归下 release 和 develop 分支是否同样存在这个问题。
如果存在，修复流程 与 修复测试环境 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/Mr-GaoYu/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 remote rm origin
git remote add origin git@github.com:user_name/user_repo.git
git push origin