之前一直在用git，但仅仅只是在自己的分支push和pull，用的也是GUI来提交，没有想那么多，可是突然成为一个管理者的时候发现git项目管理还是很重要的，然后自己之前也没有系统学习过。对于Git常用命令是个程序员都不用多说什么，大家肯定信手拈来，但对于技术团队，还是需要用较为规范的 Git操作流程，本篇也是相应学习总结。
Git最重要的概念就是分支（fork），而操作流程的复杂度也取决于分支的个数和提交的复杂度。最大而全的框架就是Git Flow了，分支较多，非常适用于版本发布的工作流程。但不太适合持续发布（代码部署非常频繁）的开发场景。所以GitHub Flow对Git Flow做了简化，并充分利用了GitHub 的Pull Request功能，是一个非常轻便的基于分支的工作流。它只维护一个长期分支master，其它的无论是做什么用途的分支都算临时分支，用完即删除。如此，无论何时发布master，其都是最新的内容。而GitLab Flow则是吸收了Git Flow和GitHub Flow的优点，遵循“上游优先”的策略，做到既简单容易操作，又能满足不同的工作流程。
一、Git Flow简介
（1）常用分支
| 分支名称 | 分支功能 | 分支特性 | 提交规则 | 备注 |
| master | 产品的功能全部实现后最终在master分支对外发布 | 只读分支，只能从其他分支(release/hotfix)合并，不能在此分支修改 | release合并到master , 或hotfix合并到master | 所有在master分支的推送应该打标签做记录，方便追溯 |
| develop | 基于master分支克隆，包含所有要发布到下一个release的代码 | 只读分支，只能从其他分支合并。 | Feature功能分支完成合并到develop（不推送）； develop拉取release分支，提测； release/hotfix分支上线完毕，合并到develop并推送 | |
| feature | 基于develop分支克隆，主要用于新需求新功能的开发 | 功能开发完毕后合并到develop分支（未正式发布之前不推送到远程中央仓库） | feature分支可同时存在多个，用于团队中多个功能同时开发，属于临时分支，功能完成后可选删除 | |
| release | 基于feature分支合并到develop之后，从develop分支克隆，主要用于提交给测试人员进行功能测试 | 属于临时分支，功能上线后可选删除 | 测试过程中发现的BUG在本分支进行修复 , 修复完成上线后合并到develop/master分支并推送(完成功能) , 打Tag | |
| hotfix | 基于master分支克隆，主要用于对线上版本进行bug修复 | 属于临时分支，补丁修复上线后可选删除 | 修复完毕后合并到develop/master分支并推送，打Tag | 所有hotfix分支的修改会进入到下一个release |
（2）工作流程（步骤中仅列举部分相关命令）
1. 初始化项目为gitflow，默认创建master分支，然后从master拉取第一个develop分支：(git checkout develop; git pull)
2. 从develop拉取feature分支进行编码开发（多个开发人员拉取多个feature同时并行开发，互不影响）：(git flow feature)
3. feature分支完成后，合并到develop（不推送，feature功能完成还未提测，推送后会影响其他功能分支的开发）：(git push origin feature; git checkout develop; git merge feature)
合并feature到develop，可以选择删除当前feature，也可以不删除，但当前feature就不可更改了，必须从release分支继续编码修改
4. 从develop拉取release分支进行提测，提测过程中在release分支上修改bug：(git checkout develop; git pull; git flow release start '1.0.0')
5. release分支上线后，合并release分支到develop/master并推送：(git flow release finish '1.0.0')
合并之后，可选删除当前release分支，若不删除，则当前release不可修改，线上有问题也必须从master拉取hotfix分支进行修改
6. 上线之后若发现线上bug，从master拉取hotfix进行bug修改：(git fetch origin; git flow hotfix start '1.0.1' '1.0.0'; git push origin hotfix/1.0.1)
7. hotfix通过测试上线后，合并hotfix分支到develop/master并推送：(git push origin develop) (git checkout master; git push origin master; git push --tags)
合并之后，可选删除当前hotfix分支，若不删除，则当前hotfix不可修改，若补丁未修复，需要从master拉取新的hotfix继续进行修改
8. 当进行一个feature时，若develop分支有变动，如其他开发人员啊完成功能并上线，则需要将完成的功能合并到自己的分支上，即合并develop到当前feature分支
9. 当进行一个release分支时，若develop分支有变动，如其他开发人员完成功能并上线，则需要将完成的功能合并到自己分支上
即合并develop到当前release分支（因为当前release分支通过测试后会发布到线上，如果不合并最新的develop分支就会发生丢失代码的情况
更详细的Git Flow工作流程图如下：
二、GitHub Flow简介
1. 始终保持master主干分支为可发布、部署的状态(这样可以时刻被创建特性分支或者可以被部署)，不能在其上进行开发
2. 新特性、作业或修改bug，从主干分支创建新的本地分支（该分支应具有描述性的名称），若该分支已存在，应先git pull更新为远程仓库master主干分支的最新状态：（git branch -b feature master;）
3. 确认在本地环境中通过所有测试，此后便可修改新建的本地分支下内容(一般只修改一定小粒度的内容)并在该分支中进行提交(修改内容前一般需要先编写测试代码)：( git checkout master; git merge feature)
4. 在GitHub端的仓库中创建同名的分支，并push操作(即在该分支下创建远程分支)
5. 此外可通过Pull Request反馈、交流(整个过程可能多次被请求审查、重新修改等直到完成作业)。即开发结束后向master发送 Pull Request，Pull Request通过review之后合并到 master，并从master向正式环境发布；
6. 让其他开发者进行审查，待确认后再与master主干分支进行合并(事实上应现在本地测试通过)
7. 与master主干分支合并后即刻部署，而在部署到正式环境之前需要先通过测试(包自动化测试、持括测试代码编写、续集成等工具(部分部署工具: Capistrano、Mina、Fabric、Cinnamon、Webistrano、Strano等，持续集成IC: Jenkins、Travish CI等))
三、GitLab Flow简介
（1）持续发布使用说明
持续发布的场景要求我们随时都有最新的内容发布到生产，因此我们还是保留一个master长期分支，它作为其它任何分支的上游分支，然后再分别创建一个预发布分支pre-production和发布分支production：
git checkout -b pre-production master
git checkout -b production master
其中，预发布分支pre-production是用来检测master上的更新内容是否具有风险和Bug的，如果没有问题，则直接再合并到production上，进行发布即可。
git checkout pre-production
git merge master
git checkout production
git merge pre-production
如此，可以实现使用GitLab Flow来实现持续发布的工作流程。
（2）版本发布使用说明
每一个稳定的版本都单独作为一个分支存在，从master上拉取出来。以后只有master上的Bug修复才会被允许cherry-pick到这些单独的版本分支上，而对于master上的新内容是不采取合并操作的：
git checkout -b stable1 master
创建了稳定版本stable1分支后，master可以继续接受来自其它分支的合并内容，但这些内容和stable1分支没有关系，因为stable1分支是某个具体的版本，只包含固定的内容。只有那些发现了存在于stable1上的Bug，才会需要从master合并到stable1上。因为GitLab Flow遵循的上游优先策略，我们只有先合并到master上，才能再从master上合并到stable1上
git cherry-pick 提交号
如上，就可以实现使用GitLab Flow来实现版本发布的工作流程，大致示意图如下：
参考网址：
https://blog.csdn.net/xingbaozhen1210/article/details/81386269
扫一扫
1368
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
