多人开发模式下基于Git的工作流介绍

文章目录

多人开发模式下基于Git的工作流介绍
- 什么是工作流？
- 如何设计工作流？
- Git Flow工作流
- - 各个分支的作用
  - Git Flow实践
- Forking工作流
- - Forking实践

一个大型的项目总是由多人一起开发完成的，多人协作一般需要选取合适的协作方式，比如统一的规范、合适的开发模式等。现在项目一般采用Git管理，可以有效管理代码版本。

什么是工作流？

工作流就是开发模式。例如，不同的开发人员将代码编写完毕之后怎么汇总合并，项目上线之后的后续功能开发，代码测试以及出现BUG怎么紧急修复等问题都是属于开发模式的范畴，也就是项目的工作流。
目前，大多数企业都借助Git来设计工作流。

如何设计工作流？

一般企业可以根据自己的需要设计一套工作流
也可以使用业界沉淀下来好的一些工作流，都是基于Git的工作流，比如集中式工作流，功能分支工作流，Git Flow工作流，Forking工作流。

集中式工作流是开发者将自己开发完毕的代码推送到统一的远程仓库，由此完成协作。一般适合变动不大的小项目。

功能分支工作流是集中式工作流的进一步拓展，依据功能来创建分支，编写完之后pull request，然后将功能分支合并到主分支上。适合分工明确、规模较小的项目。

而本文将着重介绍Git Flow工作流与Forking工作流，这两个也是业界常用的开发模式。

Git Flow工作流

Git Flow工作流是企业用的比较多的开发模式，也是非开源项目常用的开发模式。Git Flow是功能分支开发模式的进一步拓展。不单单开拓出了功能分支(feature)、还有增加了开发分支(develop)、修复分支(hotfix)以及release分支。
下面介绍一下几个分支的作用。

各个分支的作用

master
master分支是发布的分支,不允许在这个分支上开发。master分支可以合并develop，hotfix，release分支。
develop
这个分支是开发中的最新代码，develop分支只能合并不能开发。一般合并feature。
feature
这个分支就是功能开发分支的，一般基于develop新建feature分支，开发完毕之后，合并到develop分支。
release
这个分支是develop分支到master分支之间的过渡，中间状态。功能代码开发完毕合并到develop后，基于develop分支创建release分支（注意版本命名），release提交测试，若出现问题就在release修改。通过测试之后合并到master分支并打版本标签，合并到develop并删除release。
hotfix
这个分支是紧急修复的分支。一般是线上错误，基于master创建hotfix，修复完合并到master与develop，然后删除hotfix。

各个分支的协作如下：

Git Flow工作流适合团队稳定，规模较大的项目，小项目不建议使用。Git Flow模式较为健壮，使用较多。

我们可以通过实践来看看Git Flow工作流的过程。

Git Flow实践

#1.创建一个常驻分支
git checkout -b develop master#2.新建功能分支
git checkout -b feature/v1 develop#3.开发功能
vi main。go#4.功能代码提交到feature
git commit -a -m "test-v1'"#5.本地feature推送到远程
git push origin feature/test-v1#6.pull request and code review#7.合并到develop分支
git checkout develop
git merge --no-ff feature/test-v1#8.创建release并测试
git checkout -b release/v1.0.0 develop
go build -v . # 构建后，部署二进制文件，并测试#9.如果测试不成功，需要基于release修改#10.测试完成后合并到develop和master
git checkout develop
git merge --no-ff release/v1.0.0
git checkout master
git merge --no-ff release/v1.0.0
git tag -a v1.0.0 -m "add test-v1" # 打 tag#11.删除feature
git branch -d feature/test-v1#12.如果线上出现了紧急bug，需要记住hotfit修复
git checkout -b hotfix/print-error master #从 master 建立 hotfix 分支
vi main.go # 修复 bug，
git commit -a -m 'fix print message error bug'
git checkout develop # 切换到 develop 分支合并hotfix
git merge --no-ff hotfix/print-error
git checkout master #切换到 master 分支合并hotfix
git merge --no-ff hotfix/print-error
git tag -a v0.1.2 -m "fix log bug" # 打 tag
go build -v .
git branch -d hotfix/print-error #  修复好后删除

Forking工作流

前面介绍了Git Flow工作流，是适用于非开源项目的工作流，这里介绍适合于开源项目的工作流，Forking模式。（如果想给开源项目贡献代码，也可以看看这部分内容）

基于Git的Forking就是拷贝一份远程仓库的代码到自己的代码库，然后进行相应的开发。开发完成之后，推送到远程仓库并提交一个PR（pull request）给远程仓库的作者。作者收到PR之后，可以进行code review，并且可以针对PR评论。code review通过之后，提交的代码就会合并进远程仓库。这样就完成了远程仓库的协助开发。

一般Forking模式应用在开源项目，支持贡献代码，协助开发。社区中一般基于Git使用这种开发模式。

Forking实践

首先fork代码到自己的账户中
将仓库拉取到本地仓库：

git clone https://github.com/······
cd ······
git remote add upstream https://github.com/xxx
git remote set-url --push upstream no_push
git remote -v # Confirm that your remotes make sense
origin  https://github.com/······ (fetch)
origin  https://github.com/······ (push)
upstream  https://github.com/xxx (fetch)
upstream  https://github.com/xxx (push)

同步本地分支master

git fetch upstream
git checkout master
git rebase upstream/master

创建功能分支并开发

git checkout -b feature/mycode

提交commit

git fetch upstream #commit前需要再次同步
git rebase upstream/master
git add <file>
git status
git commit
git rebase -i origin/master

push功能分支到个人远程仓库

git push -f origin feature/mycode

在个人远程仓库那里创建PR

等作者那边通过了就可以了,需要注意作者在PR下的留言.

补充拓展
在提交的时候,可能会有一堆不同版本的commit，但是一般只有一个commit或者两三个commit是我们最终需要的。为了便于维护与阅读，可以使用git rebase来合并我们的commit；

#自动合并commit
git commit --fixup
git rebase -i --autosquash

或者，可以撤销之前的提交，重新建立最后的一次提交。

git reset HEAD~n  #（n表示几次提交）
git add .
git commit -am "Here's the bug fix that closes #28"
git push --force

以上就是Forking工作流的介绍，可以看到，这个模式适用于开源项目，而且开发团队不那么固定的项目。如果有衍生代码版本的需求，forking是优选的模式。

以上就是关于Git工作流的介绍，如果有什么错误的，请联系我改正。

参考
项目参考：https://github.com/marmotedu
（@colin）

【研发设计】多人开发模式下的Git工作流介绍相关推荐

4.4 开发模式下的测试：简化我们对链码的测试过程
4.4 开发模式下的测试:简化我们对链码的测试过程原创kevin-hf(ID不是微信) 最后发布于2019-02-26 16:48:19 阅读数 180 收藏展开目标熟练掌握链码的 dev ...
敏捷开发模式下如何更好的进行测试
最近CTO组建了一个敏捷开发团队,团队人员包括 PM.设计.开发.测试角色,主要由PM来主导团队走向,因为以前并没有参加过敏捷开发的经验,对敏捷开发做了简单理解后,参考了前人的一些意见,总结出在敏 ...
前后端分离开发模式下后端质量的保证 —— 单元测试
概述在今天, 前后端分离已经是首选的一个开发模式.这对于后端团队来说其实是一个好消息,减轻任务并且更专注.在测试方面,就更加依赖于单元测试对于API以及后端业务逻辑的较验.当然单元测试并非在前后端分 ...
如何在微信公众帐号开发模式下，通过程序代码向用户发送符号表情。
本文重点介绍如何在微信公众帐号开发模式下,通过程序代码向用户发送符号表情.部分代码来自:FreeEIM 至于如何识别用户发送的是符号表情,就不在此讲解了,留给大家一点学习思考的空间.我只是给大家一个提 ...
ultraedit 运行的是试用模式_单元测试 —— 前后端分离开发模式下后端质量的保证...
概述在今天, 前后端分离已经是首选的一个开发模式.这对于后端团队来说其实是一个好消息,减轻任务并且更专注.在测试方面,就更加依赖于单元测试对于API以及后端业务逻辑的较验.当然单元测试并非在前后端分 ...
MBD开发模式下的XIL仿真测试
MBD开发模式下的XIL仿真测试 "想了解MBD模式下的MIL.SIL.PIL.HIL吗?"--虹科汽车从一个发动机加上几个轮子的简单形态发展到如今机械与电子高度融合的复杂整体, ...
如何在微信公众帐号开发模式下，通过程序代码向用户发送符号表情
本文重点介绍如何在微信公众帐号开发模式下,通过程序代码向用户发送符号表情.部分代码来自:FreeEIM 至于如何识别用户发送的是符号表情,就不在此讲解了,留给大家一点学习思考的空间.我只是给大家一个提 ...
Vue - 去除控制台“你正在开发模式下运行Vue”的警告
目录 1. 警告内容 2. 解决方案 1. 警告内容调试 Vue 代码时,Console 控制台老是有警告,警告内容文字信息如下: You are running Vue in developme ...
cocos2d-x+lua开发模式下编辑器的选择
cocos2d-x+lua开发模式下编辑器的选择原本打算直接用CocosIDE的,毕竟是官方出品,并且支持Android远程调试,windows下的调试也非常方便,调试的信息也非常全,智能提示也不错 ...
Nodejs搭建前后端分离开发模式下的微信网页项目
原文链接:<Nodejs搭建前后端分离开发模式下的微信网页项目>- 陈帅华本文涉及对前后端分离及微信网页项目中的前端如何在本地环境中开发与调试的思考. 主要问题 1.如何配置微信公众平台 ...

【研发设计】多人开发模式下的Git工作流介绍