文档章节

git版本控制开发流程小结笔记(一)

何良瑞Nyanko君
 何良瑞Nyanko君
发布于 2014/05/29 11:03
字数 1805
阅读 18445
收藏 25

前言

说来有幸,这次实习入职的时间点非常巧,时间点正好是team刚把代码从svn迁移到git上,所以就利用这个契机好好学习了一下在git下的项目开发流程,在本篇博客中将会简单介绍git下最基本最常用的开发流程。

相关分支

首先,我们需要明确一点的是,在git repo下,我们一般将某个项目的所有分支分为以下几条主线。

1. Master

顾名思义,既然名字叫Master,那么该分支就是主分支的意思。在git repo下主分支的职责主要就是负责记录stable版本的迭代,当在beta版本的项目或是开发版本的项目得到了充分的验证之后,我才能将分支并入master分支。master分支永远是production-ready的状态,即稳定可产品化发布的状态。

2. Develop

这个分支就是我们平常开发的一个主要分支了,不管是要做新的feature还是需要做bug fix,都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本,即完成了某个feature或者修复了某个bug后的开发稳定版本。

3. Feature branches

这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当我在一个大的develop的迭代之下,往往我们会把每一个迭代分成很多个功能点,并将功能点分派给不同人的人员去开发。每一个人员开发的功能点就会形成一个feature分支,当功能点开发测试完毕之后,就会合并到develop分支去。

4. release branches

同样,这也是有多个分支组成的一个分支系列。这个分支系列从develop分支出来,也就是预发分支。在预发状态下,我们往往会进行预发环境下的测试,如果出现缺陷,那么就在该release分支下进行修复,修复完毕测试通过后,即分别并入master分支后develop分支,随后master分支做正常发布。

5. Hotfix branches

这个分支系列也就是我们常说的紧急线上修复,当线上出现bug且特别紧急的时候,就可以从master拉出分支到这里进行修复,修复完成后分别并入master和develop分支。


下面这张图将完整展示这一个流程


分支管理策略

接下来,我将会以简单例子和命令的方式演示几个主要开发流程。

1. 准备工作

首先我们得建立一个用于练习的项目

mkdir gitFlow
cd ./gitFlow/
touch 1.txt
touch 2.txt
git init
git add -A
git commit -m 'master init'

我们首先建立项目文件目录,也就是gitFlow,然后git init进行初始化.git文件操作,之后生成两个文件作为基础并添加进track list,最后commit到本地。于是我们第一个版本的master分支下的commit就建立好了。我可以通过git log以及git branch来查看一下当前的状况就一目了然了。

$ git log
commit 2ea6fb8ba4f873bb08dfeaeabd473793211c37eb
Author: nyankosama <825138000@qq.com>
Date:   Wed Oct 16 19:30:03 2013 +0800

    master init

$ git branch
* master

然后我们从master分支中拉出develop分支

$ git checkout -b develop
Switched to a new branch 'develop'

如图

当前develop和master的head都指向同一个节点,那么我们最简单的准备工作就已经完成了。

2. 功能点开发

接下来将会展示当有新的需求或功能点需要开发时的一个开发流程。首先假设现在有一个功能点,指派给A同学进行开发了,那么A同学应该怎么做呢?首先,他应该从最新develop分支中拉出一个feature分支,假设为该feature分支命名为feature1。

$ git checkout -b feature1
Switched to a new branch 'feature1'
$ git branch
  develop
* feature1
  master

于是,我们便创建并切换到了feature1分支。

$ ls
1.txt  2.txt
$ echo "feature1" >> 1.txt

于是现在A同学开始了他的开发,他将feature1写入了1.txt,这样他就完成了该功能点。那么之后他应该进行commit,并提交QA进行相应的功能测试。

$ git status
# On branch feature1
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   1.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git add -A
$ git commit -m 'feature1'

提交之后,我们可以很容易的看到当前的一个分支节点网络的情况,如图。

A同学开发的feature1分支有了更新,已经超前于develop分支,因此我们现在需要对feature1分支进行合并操作。

$ git checkout develop
Switched to branch 'develop'
$ git merge feature1
Updating 2ea6fb8..8d30443
Fast-forward
 1.txt | 1 +
 1 file changed, 1 insertion(+)

因为当前我们并没有发生冲突,所以develop分支的head只是单纯的forward到了feature1分支的节点上。于是,我便完成了分支的合并,当前的分支网络如下图。

develop分支和feature1分支的head都在同一个节点,A同学的本次开发任务已经完成。

3. 处理冲突

接下来将展示如何处理冲突,现在我们假设又有两个功能点指派给A同学和B同学开发,两位分别将feature2 和 feature3 字符串写入2.txt,然后提交到自己的分支中。

$ git checkout -b feature2
Switched to a new branch 'feature2'
$ echo "feature2" >> 2.txt
$ git add -A
$ git commit -m 'feature2'
[feature2 aaf2653] feature2
 1 file changed, 1 insertion(+)

$ git checkout develop
Switched to branch 'develop'
$ git checkout -b feature3
Switched to a new branch 'feature3'
$ echo "feature3" >> 2.txt
$ git add -A
$ git commit -m 'feature3'
[feature3 060c9d0] feature3
 1 file changed, 1 insertion(+)

好了,让我们切换回develop分支进行merge。

$ git checkout develop
Switched to branch 'develop'
$ git merge feature2
Updating 96f1771..aaf2653
Fast-forward
 2.txt | 1 +
 1 file changed, 1 insertion(+)

我们merge到feature2时,还未出现冲突,因为develop只是forward到了feature2的节点,而此时feature3的节点已经无法有develop直接forward过来,所以当我们merge feature3分支时就会出现冲突。

$ git merge feature3
Auto-merging 2.txt
CONFLICT (content): Merge conflict in 2.txt
Automatic merge failed; fix conflicts and then commit the result.

让我们来看看冲突的2.txt

<<<<<<< HEAD
feature2
=======
feature3
>>>>>>> feature3


显而易见,我们需要手动将文件冲突的部分进行修改。我们删除掉git为我们添加的冲突指示,并让feature2和feature3字符串同时保留在2.txt中后提交。

$ cat 2.txt
feature2
feature3
$ git add 2.txt
$ git commit
[develop f5cb288] Merge branch 'feature3' into develop


好了,让我们来观察一下分支节点图


如图所示,feature2和feature3便已经顺利地合并到了develop分支中。

  [1]: http://static.oschina.net/uploads/space/2014/0529/102737_T9YC_1781981.jpg

  [2]: http://static.oschina.net/uploads/space/2014/0529/103631_xmDb_1781981.png

  [3]: http://static.oschina.net/uploads/space/2014/0529/103821_gnR6_1781981.png

  [4]: http://static.oschina.net/uploads/space/2014/0529/103848_y10l_1781981.png

  [5]: http://static.oschina.net/uploads/space/2014/0529/104054_3UN1_1781981.png


© 著作权归作者所有

共有 人打赏支持
何良瑞Nyanko君
粉丝 7
博文 5
码字总数 5913
作品 1
南京
加载中

评论(3)

r
renfengmei
我也很想知道这个这个流程图是用什么工具画的, 知道的求回复下
杨延庆
杨延庆
你这里说的基于feature分支的测试是否不太妥,应该是基于develop分支的测试吧
白凡
白凡
你好, 请问你的git流程图是用什么工具画的?
git版本控制开发流程小结笔记(二)

接前篇git版本控制开发流程小结笔记(一),我们接着展示其他的开发流程。 4. 预发 那么接下来,完成了几个功能点的开发之后,develop分支已经达到了一个可以发布的状态,显然按照传统的流程...

何良瑞Nyanko君
2014/05/29
0
1
git文章列表

关于gitlab默认clone协议 Git实现从本地添加项目到远程仓库 翻翻git之---一个简单的标签控件 LabelView (随手发了两张小宝宝的玩耍照) Git 项目推荐 | Java 版微信普通号机器人 翻翻git之---...

d_watson
2016/04/20
26
0
g4e基础篇#1 为什么要使用版本控制系统

g4e 是 Git for Enterprise Developer的简写,这个系列文章会统一使用g4e作为标识,便于大家查看和搜索。 章节目录 前言 1. 基础篇: 为什么要使用版本控制系统 Git 分布式版本控制系统的优势...

leixu
01/02
0
0
好代码是管出来的——Git的分支工作流与Pull Request

  上一篇文章好代码是管出来的——使用Git来管理源代码 介绍了常用的版本控制工具以及git的基本用法,从基本用法来看git与其它的版本控制工具好像区别不大,都是对代码新增、提交进行管理,...

dotNET跨平台
06/25
0
0
《持续交付-发布可靠软件的系统方法》读书笔记-持续集成

《持续交付-发布可靠软件的系统方法》全书51.2万字,15章,384页。本次阅读第三章持续集成,大概42页。 持续交付 持续集成最早出现在Kent Beck写的《解析极限编程》一书中,主要思想:既然经...

转型实践者
2017/11/25
0
0

没有更多内容

加载失败,请刷新页面

加载更多

992. Sort Array By Parity II - LeetCode

Question 992. Sort Array By Parity II Solution 题目大意:给一个int数组,一半是奇数一半是偶数,分别对偶数数和奇数数排序并要求这个数本身是偶数要放在偶数位上 思路:把奇数数和偶数数...

yysue
10分钟前
0
0
Snackbar源码分析

目录介绍 1.最简单创造方法 1.1 Snackbar作用 1.2 最简单的创建 1.3 Snackbar消失的几种方式 2.源码分析 2.1 Snackbar的make方法源码分析 2.2 对Snackbar属性进行设置 2.3 Snackbar的show显示...

潇湘剑雨
42分钟前
1
0
分布式作业系统 Elastic-Job-Lite 源码分析 —— 作业数据存储

分布式作业系统 Elastic-Job-Lite 源码分析 —— 作业数据存储 摘要: 原创出处 http://www.iocoder.cn/Elastic-Job/job-storage/ 本文基于 Elastic-Job V2.1.5 版本分享 1. 概述 本文主要分享...

DemonsI
48分钟前
1
0
jmockit demo

1、@Mocked,标识一个指定的class的实例或被测对象的参数被Mock掉。 2、@Capturing,标识一个被Mock的对象,从该对象派生的子类也被Mock了。 3、@Injectable,标识只有一个指定的被测对象的内...

我的老腰啊
今天
1
0
内容换行

用 <textarea>13611112222 这里想换行 13877779999</textarea><textarea>13611112222 13877779999</textarea>...

小黄狗
今天
1
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部