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 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好了，让我们来观察一下分支节点图
