git版本控制开发流程

前言

说来有幸,这次实习入职的时间点非常巧,时间点正好是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 gitFlowcd ./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 logcommit 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分支。

$ ls1.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..8d30443Fast-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..aaf2653Fast-forward
 2.txt | 1 +
 1 file changed, 1 insertion(+)

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

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

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

<<<<<<< HEADfeature2=======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

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

发表评论

电子邮件地址不会被公开。