请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-艾拓先锋网

 找回密码
 

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 1074|回复: 0

test

[复制链接]
发表于 2020-6-16 17:24:37 | 显示全部楼层 |阅读模式
本帖最后由 陈小宝 于 2020-6-16 17:24 编辑 ; V9 f/ q0 ~  T+ w. e4 S, n
$ ]  J. L" k2 m
* _  x# w* D* ^$ @$ O! p
微信图片_20200616170215.jpg
2 O  \; o7 U" e& W& i
Git 作为一个源码管理系统,不可避免涉及到多人协作。

. Q7 J/ Q6 P$ t9 U
协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。”工作流程”在英语里,叫做”workflow”或者”flow”,原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。
微信图片_20200616170402.jpg
本文介绍三种广泛使用的工作流程:
  • Git flow
  • Github flow
  • Gitlab flow
    3 s6 w+ t% t% j
一、功能驱动本文的三种工作流程,有一个共同点:都采用”功能驱动式开发”(Feature-driven development,简称FDD)。它指的是,需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(hotfix branch)。完成开发后,该分支就合并到主分支,然后被删除。二、Git flow
最早诞生、并得到广泛采用的一种工作流程,就是Git flow 。
2.1 特点
它最主要的特点有两个。
微信图片_20200616170858.jpg
. w! ^7 a7 M, Q- N2 @( x
首先,项目存在两个长期分支。
  • 主分支master
  • 开发分支develop

  • ' i7 o. [! h4 R/ e# i! ~
前者用于存放对外发布的版本,任何时候在这个分支拿到的,都是稳定的分布版;后者用于日常开发,存放最新的开发版。
其次,项目存在三种短期分支。
  • 功能分支(feature branch)
  • 补丁分支(hotfix branch)
  • 预发分支(release branch)

  • 6 l3 a9 C" O. U# o0 `8 C
一旦完成开发,它们就会被合并进develop或master,然后被删除。
Git flow 的详细介绍,请阅读我翻译的中文版《Git 分支管理策略》。

0 G$ c6 @: Q% j  C# Z* y8 U
2 F& u1 ~% Y; S$ a! [; c
2.2 评价
Git flow的优点是清晰可控,缺点是相对复杂,需要同时维护两个长期分支。大多数工具都将master当作默认分支,可是开发是在develop分支进行的,这导致经常要切换分支,非常烦人。

9 c( @% j/ K- z% a/ ]3 W3 H
更大问题在于,这个模式是基于”版本发布”的,目标是一段时间以后产出一个新版本。但是,很多网站项目是”持续发布”,代码一有变动,就部署一次。这时,master分支和develop分支的差别不大,没必要维护两个长期分支。

/ v5 t" f: Y! k7 T. M

' R* ~& f1 F) t4 K6 u/ E
三、Github flow
Github flow 是Git flow的简化版,专门配合”持续发布”。它是 Github.com 使用的工作流程。
3.1 流程
它只有一个长期分支,就是master,因此用起来非常简单。
官方推荐的流程如下。
微信图片_20200616170930.jpg
5 c; k* J( a( l

& @4 F0 l& g5 B& O4 ~4 R* F7 I! j
  • 第一步:根据需求,从master拉出新分支,不区分功能分支或补丁分支。
  • 第二步:新分支开发完成后,或者需要讨论的时候,就向master发起一个pull request(简称PR)。
  • 第三步:Pull Request既是一个通知,让别人注意到你的请求,又是一种对话机制,大家一起评审和讨论你的代码。对话过程中,你还可以不断提交代码。
  • 第四步:你的Pull Request被接受,合并进master,重新部署后,原来你拉出来的那个分支就被删除。(先部署再合并也可。)

    : \/ m9 a& o+ ^, B+ k" E
3.2 评价
Github flow 的最大优点就是简单,对于”持续发布”的产品,可以说是最合适的流程。

/ P/ _3 b6 T4 }5 m7 _
问题在于它的假设:master分支的更新与产品的发布是一致的。也就是说,master分支的最新代码,默认就是当前的线上代码。

, B  f" n, i* T3 A- u: Y4 a
可是,有些时候并非如此,代码合并进入master分支,并不代表它就能立刻发布。比如,苹果商店的APP提交审核以后,等一段时间才能上架。这时,如果还有新的代码提交,master分支就会与刚发布的版本不一致。另一个例子是,有些公司有发布窗口,只有指定时间才能发布,这也会导致线上版本落后于master分支。

# Z& d0 `! t1 _/ B
上面这种情况,只有master一个主分支就不够用了。通常,你不得不在master分支以外,另外新建一个production分支跟踪线上版本。
( H0 I6 n" Q# x% i

' V5 E# ~3 S" _! I; n四、Gitlab flow
Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点,既有适应不同开发环境的弹性,又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。
; B5 M  R; q( h+ B& R4 B0 M" U$ z! N
4.1 上游优先
Gitlab flow 的最大原则叫做”上游优先”(upsteam first),即只存在一个主分支master,它是所有其他分支的”上游”。只有上游分支采纳的代码变化,才能应用到其他分支。
Chromium项目就是一个例子,它明确规定,上游分支依次为:
  • Linus Torvalds的分支
  • 子系统(比如netdev)的分支
  • 设备厂商(比如三星)的分支
    ) \( @7 m7 q, F% {$ D4 b# v! M
4.2 持续发布
Gitlab flow 分成两种情况,适应不同的开发流程。
微信图片_20200616171111.jpg
对于”持续发布”的项目,它建议在master分支以外,再建立不同的环境分支。比如,”开发环境”的分支是master,”预发环境”的分支是pre-production,”生产环境”的分支是production。
! I* Z2 v& R+ i; b- m+ K) ?" d
开发分支是预发分支的”上游”,预发分支又是生产分支的”上游”。代码的变化,必须由”上游”向”下游”发展。比如,生产环境出现了bug,这时就要新建一个功能分支,先把它合并到master,确认没有问题,再cherry-pick到pre-production,这一步也没有问题,才进入production。
8 I6 ~6 v3 G$ e' ~$ Z3 ~. X% Q% E! d
只有紧急情况,才允许跳过上游,直接合并到下游分支。

' {% ]' B0 X1 U, v5 G! g4.3 版本发布
微信图片_20200616171145.jpg

4 e3 g$ Y+ J# D8 _2 g
对于”版本发布”的项目,建议的做法是每一个稳定版本,都要从master分支拉出一个分支,比如2-3-stable、2-4-stable等等。
以后,只有修补bug,才允许将代码合并到这些分支,并且此时要更新小版本号。

0 E- M7 n- P5 h6 J+ u% m
五、一些小技巧0 b0 X! \8 D; Y7 U0 _8 l/ f
$ o$ ~' P" f  j/ F
5.1 Pull Request
! }# Y% y, B/ j  G/ n% V
微信图片_20200616171211.png
/ x+ X) @# P* c% o# |
功能分支合并进master分支,必须通过Pull Request(Gitlab里面叫做 Merge Request)。
$ v0 a% y8 D6 I
前面说过,Pull Request本质是一种对话机制,你可以在提交的时候,@相关人员或团队,引起他们的注意。
( i2 ?# w( ~: }! \
5.2 Protected branch
/ k4 H, ^! R' ~# Q& p
, {: ]5 K% f" \2 x( U
master分支应该受到保护,不是每个人都可以修改这个分支,以及拥有审批 Pull Request 的权力。
$ ?4 g( |5 o% O0 N
Github 和 Gitlab 都提供”保护分支”(Protected branch)这个功能。

4 O" o& @: a' s' z: l5.3 Issue" N, R8 W. x+ Q/ H, B  i0 z% U

9 f6 \6 w* F/ A: S3 d
Issue 用于 Bug追踪和需求管理。建议先新建 Issue,再新建对应的功能分支。功能分支总是为了解决一个或多个 Issue。
功能分支的名称,可以与issue的名字保持一致,并且以issue的编号起首,比如”15-require-a-password-to-change-it”。
微信图片_20200616171329.png

+ O: e5 v4 D% @+ @; Q% c0 U4 d
开发完成后,在提交说明里面,可以写上”fixes #14”或者”closes #67”。Github规定,只要commit message里面有下面这些动词 + 编号,就会关闭对应的issue。
$ v" @, j0 L/ T
  • close
  • closes
  • closed
  • fix
  • fixes
  • fixed
  • resolve
  • resolves
  • resolved

    4 v# @1 ], z, w, M, {  ~
这种方式还可以一次关闭多个issue,或者关闭其他代码库的issue,格式是username/repository#issue_number。

  f- D( z+ x8 G$ c$ K  c
Pull Request 被接受以后,issue关闭,原始分支就应该删除。如果以后该issue重新打开,新分支可以复用原来的名字。

" A' r# |/ s* t" M9 l6 D5.4 Merge节点
- Z% a/ i' g, S3 G
Git有两种合并:一种是”直进式合并”(fast forward),不生成单独的合并节点;另一种是”非直进式合并”(none fast-forword),会生成单独节点。
! d' F4 n. M+ e# q) p. t7 U
前者不利于保持commit信息的清晰,也不利于以后的回滚,建议总是采用后者(即使用—no-ff参数)。只要发生合并,就要有一个单独的合并节点。
5.5 Squash 多个commit

+ k7 Z, ?! Y; f7 w) R, |; S1 V) d
为了便于他人阅读你的提交,也便于cherry-pick或撤销代码变化,在发起Pull Request之前,应该把多个commit合并成一个。(前提是,该分支只有你一个人开发,且没有跟master合并过。)
微信图片_20200616171420.png
8 I' |3 r0 s- H
' ^9 c5 e6 _: G
这可以采用rebase命令附带的squash操作,具体方法请参考我写的《Git 使用规范流程》。
  M' U& \  B0 X1 I0 e8 `- o; g) q
来源:http://www.ruanyifeng.com/blog/2 ... ?bsh_bid=2219775734




上一篇:11
下一篇:大话Devops之监控神器
您需要登录后才可以回帖 登录 |

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、DevOps专家认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号-1 )|网站地图

Baidu

GMT+8, 2021-6-16 14:42 , Processed in 0.179361 second(s), 32 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表