Git 工作流程 - 阮一峰的网络日志

标签: | 发表时间:2020-03-22 22:13 | 作者:
出处:http://www.ruanyifeng.com

Git 作为一个源码管理系统,不可避免涉及到多人协作。

协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。"工作流程"在英语里,叫做"workflow"或者"flow",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。

本文介绍三种广泛使用的工作流程:

  • Git flow
  • Github flow
  • Gitlab flow

如果你对Git还不是很熟悉,可以先阅读下面的文章。

一、功能驱动

本文的三种工作流程,有一个共同点:都采用 "功能驱动式开发"(Feature-driven development,简称FDD)。

它指的是,需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(hotfix branch)。完成开发后,该分支就合并到主分支,然后被删除。

二、Git flow

最早诞生、并得到广泛采用的一种工作流程,就是 Git flow

2.1 特点

它最主要的特点有两个。

首先,项目存在两个长期分支。

  • 主分支 master
  • 开发分支 develop

前者用于存放对外发布的版本,任何时候在这个分支拿到的,都是稳定的分布版;后者用于日常开发,存放最新的开发版。

其次,项目存在三种短期分支。

  • 功能分支(feature branch)
  • 补丁分支(hotfix branch)
  • 预发分支(release branch)

一旦完成开发,它们就会被合并进 developmaster,然后被删除。

Git flow 的详细介绍,请阅读我翻译的中文版 《Git 分支管理策略》

2.2 评价

Git flow的优点是清晰可控,缺点是相对复杂,需要同时维护两个长期分支。大多数工具都将 master当作默认分支,可是开发是在 develop分支进行的,这导致经常要切换分支,非常烦人。

更大问题在于,这个模式是基于"版本发布"的,目标是一段时间以后产出一个新版本。但是,很多网站项目是"持续发布",代码一有变动,就部署一次。这时, master分支和 develop分支的差别不大,没必要维护两个长期分支。

三、Github flow

Github flow是Git flow的简化版,专门配合"持续发布"。它是 Github.com 使用的工作流程。

3.1 流程

它只有一个长期分支,就是 master,因此用起来非常简单。

官方推荐的 流程如下。

第一步:根据需求,从 master拉出新分支,不区分功能分支或补丁分支。

第二步:新分支开发完成后,或者需要讨论的时候,就向 master发起一个 pull request(简称PR)。

第三步:Pull Request既是一个通知,让别人注意到你的请求,又是一种对话机制,大家一起评审和讨论你的代码。对话过程中,你还可以不断提交代码。

第四步:你的Pull Request被接受,合并进 master,重新部署后,原来你拉出来的那个分支就被删除。(先部署再合并也可。)

3.2 评价

Github flow 的最大优点就是简单,对于"持续发布"的产品,可以说是最合适的流程。

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

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

上面这种情况,只有 master一个主分支就不够用了。通常,你不得不在 master分支以外,另外新建一个 production分支跟踪线上版本。

四、Gitlab flow

Gitlab flow是 Git flow 与 Github flow 的综合。它吸取了两者的优点,既有适应不同开发环境的弹性,又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。

4.1 上游优先

Gitlab flow 的最大原则叫做"上游优先"(upsteam first),即只存在一个主分支 master,它是所有其他分支的"上游"。只有上游分支采纳的代码变化,才能应用到其他分支。

Chromium项目就是一个例子,它明确规定,上游分支依次为:

  1. Linus Torvalds的分支
  2. 子系统(比如netdev)的分支
  3. 设备厂商(比如三星)的分支

4.2 持续发布

Gitlab flow 分成两种情况,适应不同的开发流程。

对于"持续发布"的项目,它建议在 master分支以外,再建立不同的环境分支。比如,"开发环境"的分支是 master,"预发环境"的分支是 pre-production,"生产环境"的分支是 production

开发分支是预发分支的"上游",预发分支又是生产分支的"上游"。代码的变化,必须由"上游"向"下游"发展。比如,生产环境出现了bug,这时就要新建一个功能分支,先把它合并到 master,确认没有问题,再 cherry-pickpre-production,这一步也没有问题,才进入 production

只有紧急情况,才允许跳过上游,直接合并到下游分支。

4.3 版本发布

对于"版本发布"的项目,建议的做法是每一个稳定版本,都要从 master分支拉出一个分支,比如 2-3-stable2-4-stable等等。

以后,只有修补bug,才允许将代码合并到这些分支,并且此时要更新小版本号。

五、一些小技巧

5.1 Pull Request

功能分支合并进 master分支,必须通过Pull Request(Gitlab里面叫做 Merge Request)。

前面说过,Pull Request本质是一种对话机制,你可以在提交的时候, @相关 人员团队,引起他们的注意。

5.2 Protected branch

master分支应该受到保护,不是每个人都可以修改这个分支,以及拥有审批 Pull Request 的权力。

GithubGitlab都提供"保护分支"(Protected branch)这个功能。

5.3 Issue

Issue 用于 Bug追踪和需求管理。建议先新建 Issue,再新建对应的功能分支。功能分支总是为了解决一个或多个 Issue。

功能分支的名称,可以与issue的名字保持一致,并且以issue的编号起首,比如"15-require-a-password-to-change-it"。

开发完成后,在提交说明里面,可以写上"fixes #14"或者"closes #67"。Github规定,只要commit message里面有下面这些 动词+ 编号,就会关闭对应的issue。

  • close
  • closes
  • closed
  • fix
  • fixes
  • fixed
  • resolve
  • resolves
  • resolved

这种方式还可以一次关闭多个issue,或者关闭其他代码库的issue,格式是 username/repository#issue_number

Pull Request被接受以后,issue关闭,原始分支就应该删除。如果以后该issue重新打开,新分支可以复用原来的名字。

5.4 Merge节点

Git有两种合并:一种是"直进式合并"(fast forward),不生成单独的合并节点;另一种是"非直进式合并"(none fast-forword),会生成单独节点。

前者不利于保持commit信息的清晰,也不利于以后的回滚,建议总是采用后者(即使用 --no-ff参数)。只要发生合并,就要有一个单独的合并节点。

5.5 Squash 多个commit

为了便于他人阅读你的提交,也便于 cherry-pick或撤销代码变化,在发起Pull Request之前,应该把多个commit合并成一个。(前提是,该分支只有你一个人开发,且没有跟 master合并过。)

这可以采用 rebase命令附带的 squash操作,具体方法请参考我写的 《Git 使用规范流程》

(完)

相关 [git 工作流程 网络日志] 推荐:

Git 工作流程 - 阮一峰的网络日志

- -
Git 作为一个源码管理系统,不可避免涉及到多人协作. 协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去. "工作流程"在英语里,叫做"workflow"或者"flow",原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡. 本文介绍三种广泛使用的工作流程:.

理解Git的工作流程

- - 博客 - 伯乐在线
如果你不理解Git的设计动机,那你就会处处碰壁. 知道足够多的命令和参数后,你就会强行让Git按你想的来工作,而不是按Git自己的方式来. 这就像把螺丝刀当锤子用;也能把活干完,但肯定干的差极了,花费很长时间,还会弄坏螺丝刀. 想想常见的Git工作流程是怎么失效的吧. 从Master创建一个分支,写代码,然后把这个分支合并回Master.

Git基础

- Wolf - 潘魏增
上个月末在公司内部作了一次《Git基础》的主题分享. 这里把分享内容公布出来,希望对一些朋友有用. 如果之前没有接触过Git,wikipedia上面已经有非常好的介绍. pdf格式:http://panweizeng.com/download/git-basics-meituan.pdf. keynote格式:http://panweizeng.com/download/git-basics-meituan.key.

Git-rebase 小筆記

- lepture - YORKXIN×YORKXIN
最近剛好有個機會整理很亂的 Git commit tree,終於搞懂了 rebase 的用法,筆記一下. 大家都知道 Git 有個特色就是 branch 開很大開不用錢,但很多 branches 各自開發,總要在適當時機 merge 進去 master. 看過很多 git 操作指南都告訴我們,可以妥善利用 rebase 來整理看似很亂或是中途可能不小心手滑 commit 錯的 commits ,甚至可以讓 merge 產生的線看起來比較簡單,不會有跨好幾十個 commits 的線.

Git 简明教程

- satoru - python.cn(jobs, news)
Git 是一款强大的分布式版本控制系统.在他的官网可以找到已经有很多著名的项目正在使用. Like most other modern version control systems, Git gives each developer a local copy of the entire development history, and changes are copied from one such repository to another.

git架构图解

- - CSDN博客研发管理推荐文章
  最近又遇到Git了,发现网络上Git的资料确实不咋滴,难懂不全面. 至于Git是什么我就不多说了,相比svn上手确实更难. 与svn集中版本库相比较,Git被称作分布式版本库,在分布式的版本库中任何一个库都可以作为中心库看待. 如果说svn是颗树,那么Git就像一张网. Svn在每个目录都有一个.svn文件夹存放信息,而git只在根目录才有,这就决定了svn可以单独拉取某个子目录或者某个文件,而git需要全部拉取.

一些 Git 設定偏好

- dylan - ihower { blogging }
讓 command line 指令列顯示目前處在哪一個 Git Brnach,最早是在 RGBA 看到這一招,非常方便. 請修改家目錄的 ~/.bashrc 或 ~/.bash_profile 檔案:. 記得打開 Git 的 color 設定,這樣 Git 指令的輸出結果才會加上顏色,像是 git status 等:.

Git和Mercurial(Hg)的分析

- gOODiDEA - 译言-电脑/网络/数码科技
来源Analysis of Git and Mercurial. 原文地址:http://code.google.com/p/support/wiki/DVCSAnalysis. (译者注:Mercurial以下简称Hg). 注:这篇分析完成于2008年夏季,当时我们正第一次为Google Code支持DVCS而作的研究工作.

GoogleCode 的 git 使用小记

- Fstone - Gracecode.com
早先就知道 GoogleCode 支持 git,不过一直没时间体验. 近期实在受不了频繁的 svn commit 加上公司的联通网络访问 GoogleCode 实在是慢得让人无法忍受,于是咬咬牙想把 GoogleCode 中那陈年的代码迁移到 git 控制中. 总得来讲,设置 GoogleCode 项目中新的版本控制方案并不复杂,只需要在管理中点击需要的版本控制系统就行.

理解Git工作流

- joyoner - FeedzShare
来自: 黑客志 - FeedzShare  . 发布时间:2011年08月04日,  已有 2 人推荐. 如果你不了解Git背后的设计初衷,那么你正处在危险境地,当然有很多参数可以强迫Git按照你的意愿行事,但这并不是Git被设计的工作方式,这就好比你可以把改锥当锤子使用,并且它也可以完成工作,但这对改锥没什么好处.