git分支管理和工作流规范：不同场景细化和演示_随笔

git分支管理和工作流规范：不同场景细化和演示

https://www.iteye.com/blog/qqtalk-2415889

前两篇介绍了 git基本概念和具体的规范，本篇针对不同的使用场景做演示。

分支分支命名

拉取远程分支

git checkout -b <分支名称> origin/<分支名称>　拉取并关联远程分支

创建新分支　

git checkout -b <分支名称＞　　创建新分支并切换到新分支

提交备注规范

首行，简明扼要地描述更新内容;
空出一行;
之后，详细描述更新内容。

如果对应jira的问题，填写jira路径：issue：http://jira.n.xiaomi.com/test1

举例

修复bug，工单详情页面，工单记录页面，客服头像不显示
<空行占位符>
导致原因：代码逻辑考虑不全
jira: http://jira.n.xiaomi.com/test1

如何整理自己的commit，保持commit清晰

git commit —amend 修改最近一次提交;
git rebase 　-i　整理提交

再次强调：如果commit已经提交到远程git仓库，一定不要再进行整理合并commit。

举例说明

基于develop分支创建一个功能分支，名称为feature/feature1;

git checkout -b feature/feature1
新建一个文件test.txt，提交;

git commit -m ‘add test.txt file’
修改文件test.txt，添加一行内容，提交;

git commit -m ‘update text.txt file， append content: love vae music’
发现上一步添加的内容错误，想修改内容，但不添加新的commit
修改为正确的内容;

git commit —amend; 会d出修改窗口，修改注释，如果不变，直接回车;
连续提交3个commit，但想合并为1个commit;
使用git log，确定要rebase的commit-id；
git rebase -i df87607d5dd24c0a73f23284e6988d6d32c0d3a4 显示编辑窗口
进行编辑，修改如下：
最终结果只会保留commit1：

新人加入，如何加入开发

从远程拉取develop分支：
git checkout -b <分支名称> origin/<分支名称>　拉取并关联远程分支

如果要开发新功能，基于develop分支创建feature分支：
git checkout -b feature/feature1

如果要修复线上紧急bug，基于master分支创建hotfix分支：
git checkout -b hotfix/hotfix1

开发一个feature

基于develop分支创建feature分支;

开发完成后，整理自己的commit，把无意义的commit进行合并;

准备在下一次迭代上线，整理完成后，合并到develop分支;

不准备在下一次迭代上线，整理完成后，push当前分支到远程git仓库，等待准备上线时，再合并到develop分支：
git push origin feature/feature1:feature/feature1

合并到develop分支前，一定要经过本地测试！

确定版本上线计划及上线

整体上，要有明确的上线计划，确定每次上线哪些功能;

只有确认在下一次版本上线的feature才能合并到develop分支；

提交测试，修复测试反馈的bug

提交测试前，确保所有人的代码修改都已提交到develop分支;

基于develop分支，创建release分支：
git checkout -b release/release1

发布release/release1分支到测试环境，测试人员进行测试；

测试过程中发现的bug，直接在release分支进行修复并提交;

测试完成，确认上线，合并代码到master分支和develop分支，用release分支名打Tag，删除release分支：
git tag release.1.1.1
git branch -d release/release1

修复线上bug

基于master分支，创建hotfix分支
git checkout -b hotfix/hotfix1

修复完成后，finish hotfix，合并代码到master和develop分支;

欢迎分享，转载请注明来源：内存溢出

git分支管理和工作流规范：不同场景细化和演示