GitHub 系列之「团队合作利器 Branch」

Git 相比于 SVN 最强大的一个地方就在于「分支」,Git 的分支操作简直不要太方便,而实际项目开发中团队合作最依赖的莫过于分支了,关于分支前面的系列也提到过,但是本篇会详细讲述什么是分支、分支的具体操作以及实际项目开发中到底是怎么依赖分支来进行团队合作的。

1.什么是分支?

我知道读者中肯定有些人对分支这个概念比较模糊,其实你们可以这么理解,你们几个人一起去旅行,中间走到一个三岔口,每条路可能有不同的风景,你们约定 3 天之后在某地汇聚,然后各自出发了。而这三条分叉路就可以理解成你们各自的分支,而等你们汇聚的时候相当于把你们的分支进行了合并。

2.分支的常用操作

通常我们默认都会有一个主分支叫 master ,下面我们先来看下关于分支的一些基本操作:

新建一个叫 develop 的分支

git branch develop  

这里稍微提醒下大家,新建分支的命令是基于当前所在分支的基础上进行的,即以上是基于 mater 分支新建了一个叫做 develop 的分支,此时 develop 分支跟 master 分支的内容完全一样。如果你有 A、B、C三个分支,三个分支是三位同学的,各分支内容不一样,如果你当前是在 B 分支,如果执行新建分支命令,则新建的分支内容跟 B 分支是一样的,同理如果当前所在是 C 分支,那就是基于 C 分支基础上新建的分支。

切换到 develop 分支

git checkout develop 

如果把以上两步合并,即新建并且自动切换到 develop 分支:

git checkout -b develop  

把 develop 分支推送到远程仓库

git push origin develop  

如果你远程的分支想取名叫 develop2 ,那执行以下代码:

git push origin develop:develop2  

但是强烈不建议这样,这会导致很混乱,很难管理,所以建议本地分支跟远程分支名要保持一致。

查看本地分支列表

git branch 

查看远程分支列表

git branch -r  

删除本地分支

git branch -d develop    

git branch -D develop (强制删除)  

删除远程分支

git push origin :develop  

如果远程分支有个 develop ,而本地没有,你想把远程的 develop 分支迁到本地:

git checkout develop origin/develop    

同样的把远程分支迁到本地顺便切换到该分支:

git checkout -b develop origin/develop  

3.基本的团队协作流程

一般来说,如果你是一个人开发,可能只需要 master、develop 两个分支就 ok 了,平时开发在 develop 分支进行,开发完成之后,发布之前合并到 master 分支,这个流程没啥大问题。

如果你是 3、5 个人,那就不一样了,有人说也没多大问题啊,直接可以新建 A、B、C 三个人的分支啊,每人各自开发各自的分支,然后开发完成之后再逐步合并到 master 分支。然而现实却是,你正在某个分支开发某个功能呢,这时候突然发现线上有一个很严重的 bug ,不得不停下手头的工作优先处理 bug ,而且很多时候多人协作下如果没有一个规范,很容易产生问题,所以多人协作下的分支管理规范很重要,就跟代码规范一样重要,以下就跟大家推荐一种我们内部在使用的一种分支管理流程 Git Flow。

4.Git Flow

我们都知道, 在 git 的分支功能相对 svn 确实方便许多,而且也非常推荐使用分支来做开发. 我的做法是每个项目都有2个分支, master 和 develop. master 分支是主分支, 保证程序有一个 稳定版本, develop 则是开发用的分支, 几乎所有的功能开发, bug 修复都在这个分支上, 完成后 再合并回 master.

但是情况并不是这么简单. 有时当我们正在开发一个功能, 但程序突然出现 bug 需要及时去修复的时候, 这时要切回 master 分支, 并基于它创建一个 hotfix 分支. 有时我们在开发一个功能时, 需要停下来去开发另一个功能. 而且所有这些问题都出现 的时候, 发布也会成为比较棘手问题.

也就是说, git branch 功能很强大,但是没有一套模型告诉我们应该怎样在开发的时候善用 这些分支。于是有人就整理出了一套比较好的方案 A successful Git branching model, 今天我们就一起来学习下这套方案.

准确的说 Git Flow 是一种比较成熟的分支管理流程,我们先看一张图能清晰的描述他整个的工作流程:

第一次看上面那个图是不是一脸懵逼?跟我当时一样,不急,我来用简单的话给你们解释下。

一般开发来说,大部分情况下都会拥有两个分支 master 和 develop,他们的职责分别是:

master:永远处在即将发布(production-ready)状态

develop:最新的开发状态

确切的说 master、develop 分支大部分情况下都会保持一致,只有在上线前的测试阶段 develop 比 master 的代码要多,一旦测试没问题,准备发布了,这时候会将 develop 合并到 master 上。

但是我们发布之后又会进行下一版本的功能开发,开发中间可能又会遇到需要紧急修复 bug ,一个功能开发完成之后突然需求变动了等情况,所以 Git Flow 除了以上 master 和 develop 两个主要分支以外,还提出了以下三个辅助分支:

feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop

release: 准备要发布版本的分支, 用来修复 bug,基于 develop,完成后 merge 回 develop 和 master

hotfix: 修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后 merge 回 master 和 develop

什么意思呢?

举个例子,假设我们已经有 master 和 develop 两个分支了,这个时候我们准备做一个功能 A,第一步我们要做的,就是基于 develop 分支新建个分支:

git branch feature/A   

看到了吧,其实就是一个规范,规定了所有开发的功能分支都以 feature 为前缀。

但是这个时候做着做着发现线上有一个紧急的 bug 需要修复,那赶紧停下手头的工作,立刻切换到 master 分支,然后再此基础上新建一个分支:

git branch hotfix/B  

代表新建了一个紧急修复分支,修复完成之后直接合并到 develop 和 master ,然后发布。

然后再切回我们的 feature/A 分支继续着我们的开发,如果开发完了,那么合并回 develop 分支,然后在 develop 分支属于测试环境,跟后端对接并且测试的差不多了,感觉可以发布到正式环境了,这个时候再新建一个 release 分支:

git branch release/1.0  

这个时候所有的 api、数据等都是正式环境,然后在这个分支上进行最后的测试,发现 bug 直接进行修改,直到测试 ok 达到了发布的标准,最后把该分支合并到 develop 和 master 然后进行发布。

以上就是 Git Flow 的概念与大概流程,看起来很复杂,但是对于人数比较多的团队协作现实开发中确实会遇到这么复杂的情况,是目前很流行的一套分支管理流程,但是有人会问每次都要各种操作,合并来合并去,有点麻烦,哈哈,这点 Git Flow 早就想到了,为此还专门推出了一个 Git Flow 的工具,并且是开源的:

GitHub 开源地址:https://github.com/nvie/gitflow

简单点来说,就是这个工具帮我们省下了很多步骤,比如我们当前处于 master 分支,如果想要开发一个新的功能,第一步切换到 develop 分支,第二步新建一个以 feature 开头的分支名,有了 Git Flow 直接如下操作完成了:

git flow feature start A  

这个分支完成之后,需要合并到 develop 分支,然而直接进行如下操作就行:

git flow feature finish A  

如果是 hotfix 或者 release 分支甚至会自动帮你合并到 develop、master 两个分支。

想必大家已经了解了这个工具的具体作用,具体安装与用法如下:

A successful Git branching model

主要分支

  • **master: **永远处在即将发布(production-ready)状态
  • **develop: **最新的开发状态

辅助分支

  • feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop
  • release: 准备要发布版本的分支, 用来修复 bug. 基于 develop, 完成后 merge 回 develop 和 master
  • hotfix:修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后 merge 回 master 和 develop

    作者还提供了 git-flow 命令工具:

$ git flow init

接着它会问你一系列的问题,蛋定!尽量使用它的默认值就好了:

No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

完成后当前所在分支就变成 develop. 任何开发都必须从 develop 开始:

git flow feature start some_awesome_feature

完成功能开发之后:

git flow feature finish some_awesome_feature

该命令将会把feature/some_awesome_feature合并到develope分支,然后删除功能(feature)分支。

将一个 feature 分支推到远程服务器:

git flow feature publish some_awesome_feature
或者
git push origin feature/some_awesome_feature

当你的功能点都完成时(需要发布新版本了),就基于develop创建一个发布(release)分支,然后升级版本号并在最后发布日期前把Bug Fix掉吧:

$ git flow release start v0.1.0

当你在完成(finish)一个发布分支时,它会把你所作的修改合并到master分支,同时合并回develop分支,所以,你不需要担心你的master分支比develop分支更加超前。

最后一件让git-flow显得威武的事情是它处理热修复(即时的BugFix)的能力,你可以像其他分支一样地创建和完成一个热修复分支,区别是它基于master分支,因此你可以在产品出现问题时快速修复,然后通过”finish”命令把修改合并回master和develop分支。

时间: 2024-11-10 07:42:02

GitHub 系列之「团队合作利器 Branch」的相关文章

【转载】从0开始学习 GITHUB 系列之「团队合作利器 BRANCH」

转载自http://stormzhang.com Git 相比于 SVN 最强大的一个地方就在于「分支」,Git 的分支操作简直不要太方便,而实际项目开发中团队合作最依赖的莫过于分支了,关于分支前面的系列也提到过,但是本篇会详细讲述什么是分支.分支的具体操作以及实际项目开发中到底是怎么依赖分支来进行团队合作的. 1. 什么是分支? 我知道读者中肯定有些人对分支这个概念比较模糊,其实你们可以这么理解,你们几个人一起去旅行,中间走到一个三岔口,每条路可能有不同的风景,你们约定 3 天之后在某地汇聚,

从0开始学习 GitHub 系列之「GitHub 常见的几种操作」

之前写了一个 GitHub 系列,反响很不错,突然发现竟然还落下点东西没写,前段时间 GitHub 也改版了,借此机会补充下. 我们都说开源社区最大的魅力是人人多可以参与进去,发挥众人的力量,让一个项目更完善,更强壮.那么肯定有人疑问,我自己目前还没有能力开源一个项目,但是想一起参与到别的开源项目中,该怎么操作呢?那么今天,就来给大家一起介绍下 GitHub 上的一些常见的操作,看完之后你就知道方法了. 我们姑且以 Square 公司开源的 Retrofit 为例来介绍. 打开链接: https

从0開始学习 GitHub 系列之「07.GitHub 常见的几种操作」

之前写了一个 GitHub 系列,反响非常不错,突然发现居然还落下点东西没写,前段时间 GitHub 也改版了,借此机会补充下. 我们都说开源社区最大的魅力是人人多能够參与进去,发挥众人的力量,让一个项目更完好.更强壮.那么肯定有人疑问,我自己眼下还没有能力开源一个项目,可是想一起參与到别的开源项目中.该怎么操作呢?那么今天,就来给大家一起介绍下 GitHub 上的一些常见的操作,看完之后你就知道方法了. 我们姑且以 Square 公司开源的 Retrofit 为例来介绍. 打开链接: http

【转载】从0开始学习 GITHUB 系列之「向GITHUB 提交代码」

转载自http://stormzhang.com 之前的这篇文章「从0开始学习 GitHub 系列之「Git速成」」相信大家都已经对 Git 的基本操作熟悉了,但是这篇文章只介绍了对本地 Git 仓库的基本操作,今天我就来介绍下如何跟远程仓库一起协作,教你们向 GitHub 上提交你们的第一行代码! 1. SSH 你拥有了一个 GitHub 账号之后,就可以自由的 clone 或者下载其他项目,也可以创建自己的项目,但是你没法提交代码.仔细想想也知道,肯定不可能随意就能提交代码的,如果随意可以提

【转载】从0开始学习 GITHUB 系列之「初识 GITHUB」

转载自http://stormzhang.com 1. 写在前面 我一直认为 GitHub 是程序员必备技能,程序员应该没有不知道 GitHub 的才对,没想到这两天留言里给我留言最多的就是想让我写关于 GitHub 的教程,说看了不少资料还是一头雾水,我转念一想,我当初接触 GitHub 也大概工作了一年多才开始学习使用,我读者里很多是初学者,而且还有很多是在校大学生,所以不会用 GitHub 也就不奇怪了,所以我觉得写一写关于 GitHub 的教程就非常有必要了! 2. 为什么还要造轮子 很

GitHub 系列之「怎样使用 GitHub?」

1.写在前边的话,为什么要写CitHub? 跟朋友在交流的时候听到求职的时候发现有些公司要附Github帐号,一个优秀的 GitHub 账号当然能让你增色不少.自己之前听说过,但没有花时间研究,最后花了时间看了CitHub的文档,还有一些程序员写的的blog,就写下来了. 2.GitHub 是什么? gitHub是一个面向开源及私有软件项目的托管平台,因为只支持git 作为唯一的版本库格式进行托管,故名gitHub. GitHub Logo 全球顶级科技公司纷纷加入 GitHub ,并贡献他们自

GitHub 系列之「Git速成」

1.什么是Git? Git 是 Linux 发明者 Linus 开发的一款新时代的版本控制系统,那什么是版本控制系统呢?怎么理解?网上一大堆详细的介绍,但是大多枯燥乏味,对于新手也很难理解,这里我只举几个例子来帮助你们理解. 熟悉编程的知道,我们在软件开发中源代码其实是最重要的,那么对源代码的管理变得异常重要: 比如为了防止代码的丢失,肯定本地机器与远程服务器都要存放一份,而且还需要有一套机制让本地可以跟远程同步: 又比如我们经常是好几个人做同一个项目,都要对一份代码做更改,这个时候需要大家互不

【转载】从0开始学习 GitHub 系列之「Git 进阶」

转载自http://stormzhang.com 关于 Git 相信大家看了之前一系列的文章已经初步会使用了, 但是关于Git还有很多知识与技巧是你不知道的,今天就来给大家介绍下一些 Git 进阶的知识. 1. 用户名和邮箱 我们知道我们进行的每一次commit都会产生一条log,这条log标记了提交人的姓名与邮箱,以便其他人方便的查看与联系提交人,所以我们在进行提交代码的第一步就是要设置自己的用户名与邮箱.执行以下代码: git config --global user.name "storm

GitHub 系列之「Git 进阶」

1.用户名和邮箱 我们知道我们进行的每一次 commit 都会产生一条 log,这条 log 标记了提交人的姓名与邮箱,以便其他人方便的查看与联系提交人,所以我们在进行提交代码的第一步就是要设置自己的用户名与邮箱.执行以下代码: git config --global user.name "stormzhang" git config --global user.email "[email protected]" 以上进行了全局配置,当然有些时候我们的某一个项目想要