Git 分支 + gitflow

分支

在Git里，master分支为主分支。
HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
HEAD的指向就是当前编辑的分支。

---

创建分支

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

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

用git branch命令查看当前分支：

$ git branch
* dev
  master

git branch命令会列出所有分支，当前分支前面会标一个*号。
继续对test.txt修改为：

ABCDEFD
EF
A

然后提交

$ git add test.txt

$ git commit -m "dev 1"
[dev 59f88ff] dev 1
 1 file changed, 2 insertions(+), 1 deletion(-)

然后切换为原来的master分支：

$ git checkout master
Switched to branch 'master'

查看test.txt：

$ cat test.txt
ABCDEFD
EF

还是原来的内容，因为刚刚是在dev分支上提交的，master分支并没有操作。

现在，我们把dev分支的工作成果合并到master分支上：

$ git merge dev
Updating 308670f..59f88ff
Fast-forward
 test.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

git merge命令用于合并指定分支到当前分支。合并后，再查看test.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

$ cat test.txt
ABCDEFD
EF
A

合并完成后，就可以放心地删除dev分支了：

$ git branch -d dev
Deleted branch dev (was 59f88ff).

删除后，查看branch，就只剩下master分支了：

$ git branch
* master

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

---

冲突问题

准备新的feature1分支，继续我们的新分支开发：

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

修改test.txt，改为：

ABCDEFD
EF
A
test

在feature分支上提交：

$ git add test.txt 
$ git commit -m "test"
[feature 3e10bba] test
 1 file changed, 2 insertions(+), 1 deletion(-)

切换到master分支：

$ git checkout master
Switched to branch 'master'

在master分支上把test.txt文件的最后一行改为：

test2

提交：

$ git add test.txt

$ git commit -m "test2"
[master e38be0f] test2
 1 file changed, 2 insertions(+), 1 deletion(-)

现在，master分支和feature分支各自都分别有新的提交，变成了这样：

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

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

果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:   test.txt

no changes added to commit (use "git add" and/or "git commit -a")

我们可以直接查看test.txt的内容：

$ cat test.txt
ABCDEFD
EF
A
<<<<<<< HEAD
test2
=======
test
>>>>>>> feature

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：

ABCDEFD
EF
A
test3

再提交：

$ git add test.txt

$ git commit -m "test3"
[master aeb90e2] test3

现在，master分支和feature分支变成了下图所示：

用带参数的git log也可以看到分支的合并情况：

$ git log --graph --pretty=oneline --abbrev-commit
*   aeb90e2 (HEAD -> master) test3
|\
| * 3e10bba (feature) test
* | e38be0f test2
|/
* 59f88ff dev 1
* 308670f start
* 07605be add F
* e3f073c write a test

最后，删除feature1分支：

$ git branch -d feature
Deleted branch feature (was 3e10bba).

---

分支管理

合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

下面我们实战一下–no-ff方式的git merge
请注意–no-ff参数，表示禁用Fast forward：

$ git merge --no-ff -m "no-ff" dev
Merge made by the 'recursive' strategy.
 test.txt | 1 +
 1 file changed, 1 insertion(+)

用git log看看分支历史

$ git log --graph --pretty=oneline --abbrev-commit
*   9e9b552 (HEAD -> master) no-ff
|\
| * 0c37b1f (dev) add A
|/
*   aeb90e2 test3
|\
| * 3e10bba rest
* | e38be0f test2
|/
* 59f88ff dev 1
* 308670f start
* 07605be add F
* e3f073c write a test

---

隐藏未添加或未提交的内容

Git Stash
切换分支之前先git stash一下，它会把你的修改隐藏起来，这样切换分支时就不会有问题。
在其他分支修改完之后，回来可以通过git stash list看到你的隐藏记录，并且通过git stash apply stash@{0}这样的方式把修改拿回来。

首先修改内容，然后git stash

$ git status
On branch master
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:   test.txt

no changes added to commit (use "git add" and/or "git commit -a")

$ git stash
Saved working directory and index state WIP on master: 9e9b552 no-ff

$ git status
On branch master
nothing to commit, working tree clean

然后状态就变为没有改动，内容也没有改动。

查看历史：

$ git stash list
stash@{0}: WIP on master: 9e9b552 no-ff

有一个历史编辑，可以恢复

$ git stash apply stash@{0}
On branch master
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:   test.txt

no changes added to commit (use "git add" and/or "git commit -a")

继续查看历史记录的话还是有那一条记录的 需要用git stash drop删除

$ git stash list
stash@{0}: WIP on master: 9e9b552 no-ff

$ git stash drop stash@{0}
Dropped stash@{0} (c1e9b0196aece29ff82e7e2e44d9cbc0ae66f046)

还有一种方法就是用git stash pop恢复：

$ git stash pop
On branch master
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:   test.txt

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (ba5fcc71496ab6d18f069fe0d077c07bfca5717f)

---

强制删除分支

如果一个分支已经写了好多东西，但是现在已经不需要了，现在还没有合并，如果要删除，需要强制删除

$ git branch -D feature-vulcan
Deleted branch feature-vulcan (was 756d4af).

---

gitflow

Git的优点很多，但是这里只列出我认为非常突出的几点。

由于是分布式，所有本地库包含了远程库的所有内容。
优秀的分支模型，打分支以及合并分支，机器方便。
快速，在这个时间就是金钱的时代，Git由于代码都在本地，打分支和合并分支机器快速，使用个SVN的能深刻体会到这种优势。
感兴趣的，可以去看一下Git本身的设计，内在的架构体现了很多的优势，不愧是出资天才程序员Linus (Linux之父) 之手

版本管理的挑战

虽然有这么优秀的版本管理工具，但是我们面对版本管理的时候，依然有非常大得挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下：

如何开始一个Feature的开发，而不影响别的Feature？

由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？
哪些分支已经合并回了主干？
如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员可以继续开发新的功能？
线上代码出Bug了，如何快速修复？而且修复的代码要包含到开发人员的分支以及下一个Release?
大部分开发人员现在使用Git就只是用三个甚至两个分支，一个是Master, 一个是Develop, 还有一个是基于Develop打得各种分支。这个在小项目规模的时候还勉强可以支撑，因为很多人做项目就只有一个Release, 但是人员一多，而且项目周期一长就会出现各种问题。

Git Flow

就像代码需要代码规范一样，代码管理同样需要一个清晰的流程和规范

Vincent Driessen 同学为了解决这个问题提出了 A Successful Git Branching Model

下面是Git Flow的流程图

上面的图你理解不了？ 没关系，这不是你的错，我觉得这张图本身有点问题，这张图应该左转90度，大家应该就很用以理解了。

Git Flow常用的分支
Production 分支
也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改

Develop 分支
这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支

Feature 分支
这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release

Release分支
当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支

Hotfix分支
当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release

Git Flow如何工作
初始分支
所有在Master分支上的Commit应该Tag

Feature 分支
分支名 feature/*

Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，但是我们也可以保留

Release分支
分支名 release/*

Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)

发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。

维护分支 Hotfix
分支名 hotfix/*

hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag

Git Flow代码示例
a. 创建develop分支

git branch develop
git push -u origin develop 

b. 开始新Feature开发

git checkout -b some-feature develop
# Optionally, push branch to origin:
git push -u origin some-feature    

# 做一些改动    
git status
git add some-file
git commit    

c. 完成Feature

git pull origin develop
git checkout develop
git merge --no-ff some-feature
git push origin develop

git branch -d some-feature

# If you pushed branch to origin:
git push origin --delete some-feature    

d. 开始Relase

git checkout -b release-0.1.0 develop

# Optional: Bump version number, commit
# Prepare release, commit

e. 完成Release

git checkout master
git merge --no-ff release-0.1.0
git push

git checkout develop
git merge --no-ff release-0.1.0
git push

git branch -d release-0.1.0

# If you pushed branch to origin:
git push origin --delete release-0.1.0   


git tag -a v0.1.0 master
git push --tags

f. 开始Hotfix

git checkout -b hotfix-0.1.1 master    
g. 完成Hotfix

git checkout master
git merge --no-ff hotfix-0.1.1
git push


git checkout develop
git merge --no-ff hotfix-0.1.1
git push

git branch -d hotfix-0.1.1

git tag -a v0.1.1 master
git push --tags

Git flow工具
实际上，当你理解了上面的流程后，你完全不用使用工具，但是实际上我们大部分人很多命令就是记不住呀，流程就是记不住呀，肿么办呢？

总有聪明的人创造好的工具给大家用, 那就是Git flow script.