当前位置:   article > 正文

【研发设计】多人开发模式下的Git工作流介绍_gitflow 管理模型多个人开发版本

gitflow 管理模型多个人开发版本

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


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

什么是工作流?

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

如何设计工作流?

  1. 一般企业可以根据自己的需要设计一套工作流
  2. 也可以使用业界沉淀下来好的一些工作流,都是基于Git的工作流,比如集中式工作流,功能分支工作流,Git Flow工作流,Forking工作流。
  • 集中式工作流是开发者将自己开发完毕的代码推送到统一的远程仓库,由此完成协作。一般适合变动不大的小项目。

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

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

Git Flow工作流

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

各个分支的作用

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

各个分支的协作如下:
git flow工作流

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 #  修复好后删除

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49

Forking工作流

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

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

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

Forking实践

  1. 首先fork代码到自己的账户中
  2. 将仓库拉取到本地仓库:
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)
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  1. 同步本地分支master
git fetch upstream
git checkout master
git rebase upstream/master
  • 1
  • 2
  • 3
  1. 创建功能分支并开发
git checkout -b feature/mycode
  • 1
  1. 提交commit
git fetch upstream #commit前需要再次同步
git rebase upstream/master
git add <file>
git status
git commit
git rebase -i origin/master
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  1. push功能分支到个人远程仓库
git push -f origin feature/mycode
  • 1
  1. 在个人远程仓库那里创建PR

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

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

#自动合并commit
git commit --fixup
git rebase -i --autosquash
  • 1
  • 2
  • 3

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

git reset HEAD~n  #(n表示几次提交)
git add .
git commit -am "Here's the bug fix that closes #28"
git push --force
  • 1
  • 2
  • 3
  • 4

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

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

参考
项目参考:https://github.com/marmotedu
(@colin)

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/爱喝兽奶帝天荒/article/detail/833622
推荐阅读
相关标签
  

闽ICP备14008679号