git工作流入门，

 

什么是Git工作流？

Git工作流你可以理解为工作中团队成员遵守的一种代码管理方案，在Git中有以下几种工作流方案作为方案指导：

• 集中式工作流
• 功能开发工作流
• Gitflow工作流
• Forking工作流

 

Gitflow工作流

这个工作流其实也是我们团队采用的工作流，这也是很多团队会采用的工作流，它会相对复杂一点，但它非常适合用来管理大型项目的发布和维护，后面笔者也会详细讲下这一块。贯穿整个开发周期，master和develop分支是一直存在的，master分支可以被视为稳定的分支，而develop分支是相对稳定的分支，特性开发会在feature分支上进行，发布会在release分支上进行，而bug修复则会在hotfix分支上进行。笔者也是花了不少时间才熟练掌握整个工作流，期间遇到不少坑，后面会跟大家分享下。
 

 

我们团队针对Gitflow的一些实践：

master分支

主分支
保持稳定
不允许直接往这个分支提交代码，只允许往这个分支发起merge request
只允许release分支和hotfix分支进行合流

develop分支

开发分支
相对稳定的分支
用于日常开发，包括代码优化、功能性开发

feature分支=特性分支

从develop分支拉取，用于下个迭代版本的功能特性开发
功能开发完毕合并到develop分支
release分支

release分支=发布分支

从develop分支拉取
用于回归测试，bug修复
发布完成后打tag并合入master和develop
hotfix分支

热更新分支
从develop分支拉取
用于紧急修复上线版本的问题
修复后打tag并合入master和develop
大家可能会发现我们这个跟标准的Gitflow工作流有些差别，其实也没有什么标准不标准的，前面说到要结合团队的实际情况，我们团队对于目前所采用的工作方式都是达成共识的，所以有一些差异并没有关系。

说了这么久，还没有一句git命令，那就让大家感受一下吧（感谢Bugly小色熊整理）：

1). 首先将远程代码拉取到本地

    git clone xxx
    git checkout -b develop origin/develop

2).新建feature分支

    git checkout -b feature 

3).多人在feature上开发，如果中途需要将develop的变更合入feature，所有人需要将本地的代码变更提交到远程

    git fetch origin 
    git rebase origin/feature
    git push origin feature

然后由feature负责人rebase develop分支，删除原来feature分支，重新新建feature分支；

    git fetch origin
    git rebase origin/feature
    git rebase develop
    git push origin :feature
    git push origin feature

这样可以保证feature保持线性变更；

4).feature开发完成后，所有人需要将本地的代码变更提交到远程

    git fetch origin 
    git rebase origin/feature
    git push origin feature

然后由feature负责人rebase develop分支，然后将feature分支合入develop，删除feature；

    git fetch origin
    git rebase origin/feature
    git rebase develop
    git checkout develop
    git merge feature
    git push origin :feature

这样可以保证develop保持线性变更，各feature的变更完整可追溯； 
5).合入feature后拉出对应的release/feature分支，后续bug修复在release/feature上

    git checkout develop
    git checkout -b release/feature

release/feature分支的同步合并与feature分支相同 
6).release/feature分支bug修复完成后，拉取对应的tag推送远程进行发布

    git tag -a v1.0 -m 'feature发布'
    git push origin v1.0

之后将release/feature合入develop分支，然后删除

    git rebase develop
    git checkout develop
    git merge release/feature
    git push origin :release/feature

7).发布完成后将release合入master分支，保证master为最新稳定版本（实际操作为发起merge request）

总结
本篇文章主要针对笔者工作中对于git工作流的一些理解和实践，目前我们团队也是严格按照这样的工作流来完成日常的开发工作，一个让团队成员认可并且有效的工作流才是最适合我们的工作流，任何规则不是为了限制我们思考，而是为了让工作更加高效有序，尽量减少人为的失误。git是一个博大精深的东西，笔者也是不断在实际应用中去理解它，任何一门技术的学习也是这样，就像程序员常用来装逼的一首诗：
--------------------- 
作者：IT_xiao小巫 
来源：CSDN 
原文：https://blog.csdn.net/wwj_748/article/details/55226044 
版权声明：本文为博主原创文章，转载请附上博文链接！

大型项目  ，推荐工具：sourcetree

大型项目相对于中型项目又多了release版本。这个版本的作用只要是控制需求的更新以及当前版本bug的fix处理。

点击查看大图：

 对于这种情景sourcetree自带git-flow的功能

 

并且给出各种引导提示

 

和中型项目相比，hotfix分支在大型项目中只处理线上的bug问题。对于需求的控制，都会发生在release分支中。一个release版本的生成并不意味着它可以直接提交master，qa的介入在中小型项目中属于master分支，

但是在这个流程下，qa的介入属于release分支，包括对于bug的修复操作也是直接在release版本完成。当qa对于release版本确认完成后，release版本merge到master预上线并且merge回develop保持代码一致性。

参考文档：

Git 工作流的一些经验分享

https://blog.csdn.net/wwj_748/article/details/55226044

【过程改进】总结大中小型项目的git流程

https://www.cnblogs.com/dubing/p/3709759.html