分支在实际中的作用：

假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

Git的分支与众不同，无论创建、切换和删除分支， 无论你的版本库是1个文件还是1万个文件，Git都能很快完成。

创建、合并分支

每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

                                                 ![git-br-initial](https://www.liaoxuefeng.com/files/attachments/919022325462368/0)

创建并切换到新的<name>分支

1
$ git switch -c dev

创建 的分支

1
git branch <name>

切换到分支

1
2
git switch <name>	或
git checkout <name>

查看分支树

1
git branch

会列出所有分支，当前分支前面会标一个*号。

合并分支 假设这里存在 master ，dev分支

  1. 切换到要保留的分支——这里是master

    1
    git switch master

  2. 把dev分支的工作成果合并到master分支上 

1
git merge dev

删除分支

1
git branch -d <name>

解决冲突

如果主分支和其他分支各自有了新的提交（commit），变为：

                            ![git-br-feature1](https://www.liaoxuefeng.com/files/attachments/919023000423040/0)

Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。 必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件。

查看readme.txt的内容：

1
2
3
4
5
6
7
8
9
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

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

1
Creating a new branch is quick and simple.

再提交：

1
2
3
$ git add readme.txt 
$ git commit -m "conflict fixed"
[master cf810e4] conflict fixed

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

git-br-conflict-merged

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ git log --graph --pretty=oneline --abbrev-commit
*   cf810e4 (HEAD -> master) conflict fixed
|\  
| * 14096d0 (feature1) AND simple
* | 5dc6824 & simple
|/  
* b17d20e branch test
* d46f35e (origin/master) remove test.txt
* b84166e add test.txt
* 519219b git tracks changes
* e43a48b understand how stage works
* 1094adb append GPL
* e475afc add distributed
* eaadf4e wrote a readme file

注意：输入git log显示结果太长,结尾只是这样需要按ctrl+c退出，linux下按q退出。

最后，删除feature1分支即可。

分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

                                 ![git-br-ff-merge](https://www.liaoxuefeng.com/files/attachments/919022412005504/0)

禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。 

                        ![git-no-ff-mode](https://www.liaoxuefeng.com/files/attachments/919023225142304/0)

首先，创建并切换dev分支：$ git switch -c dev, 修改readme.txt文件，并提交一个新的commit。切换回master：$ git switch master。

准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：

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

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。

--no--ff 模式其实就是相当于master指针new了一个跟dev指针一样的空间并且放了相同的内容然后指向这个空间。而原来的快速模式，就是简单将master指针指向dev指针指向的内容而已，并没有自己创造空间。

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活； 干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本； 你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

git-br-policy

Bug分支

在Git中，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；

在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick 命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

储存工作现场

在分支下进行的工作，如果不commit的话，回到master，就会显示出你在分支下你添加的工作。这个时候，你在master下修改完bug提交后，正在分支进行的工作也会提交了。为了避免这个情况，你就在分支下，git stash将工作隐藏，这个时候，切换到master时候，修改了bug，提交。分支的内容不会被提交上去。

Git提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

1
2
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge

现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

1
2
3
4
5
6
7
$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git checkout -b issue-101
Switched to a new branch 'issue-101'

修复bug并commit后，切换到master分支，并完成合并，最后删除issue-101分支：

1
2
3
4
5
6
7
8
9
$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

现在，是时候接着回到dev分支干活了！

1
2
$ git switch dev
Switched to branch 'dev'

现在工作区是干净的，现在可以用两个方法恢复：

  • 用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
  • 用git stash pop，恢复的同时把stash内容也删了：

再用git stash list查看，就看不到任何stash内容了：

1
$ git stash list

你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

1
$ git stash apply stash@{0}

stash就像是把当前的WIP压栈(这里WIP的含义就是所有修改了但未commit的数据)然后再一个一个取出来,默认的git stash pop是按照自栈顶开始的顺序依次出栈,也可以使用git stash pop stash@{num}的方式取出指定的WIP 我们可以用git stash list查看当前压栈了多少个WIP

注意:git stash不能将未被追踪的文件(untracked file)压栈,也就是从未被git add过的文件,也就是你在使用git status命令看到的提示Untracked files所列出的文件,所以在git stash之前一定要用git status确认没有Untracked files

修改同样的bug

在master分支上修复了bug后，因为dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。

同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。

cherry-pick命令，让我们能复制一个特定的提交到当前分支：

1
2
3
4
5
6
$ git branch
* dev
  master
$ git cherry-pick 4c805e2		//commit的bug修改的ID号
[master 1d4b803] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。

直接在dev分支上修复bug，然后在master分支上“重放”也可以，不过你仍然需要git stash命令保存现场，才能从dev分支切换到master分支。

强制删除

如果要丢弃一个没有被合并过的分支，可以通过git branch -D 强行删除。

多人协作

  • 查看远程库信息，使用git remote -v；
  • 本地新建的分支如果不推送到远程，对其他人就是不可见的；
  • 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
  • 在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
  • 建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
  • 从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

推送分支

就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：$ git push origin master。如果要推送其他分支，比如dev，就改成：

1
$ git push origin dev

在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

抓取分支

模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆：

1
$ git clone git@github.com:michaelliao/learngit.git

当你的小伙伴从远程库clone时，默认情况下，他只能看到本地的master分支。 现在，他要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是可以用用这个命令创建本地dev分支：

1
$ git checkout -b dev origin/dev

现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：

1
2
3
4
5
$ git add env.txt

$ git commit -m "add env"

$ git push origin dev

如果你的提交和你的小伙伴推送的提交有冲突，解决办法也很简单，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：

1
2
$ git pull
...

失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：

1
2
$ git branch --set-upstream-to=origin/dev dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.

再pull：$ git pull即可。 但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push： 

1
2
3
4
$ git commit -m "fix env conflict"
...
$ git push origin dev
...

因此，多人协作的工作模式通常是这样：

  1. 首先，可以试图用git push origin 推送自己的修改；
  2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
  3. 如果合并有冲突，则解决冲突，并在本地提交；
  4. 没有冲突或者解决掉冲突后，再用git push origin 推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name> 。

如果远程仓库存在dev分支，而你的本地不存在dev，那么最好是先git pull一下，然后再执行：

1
$ git checkout -b dev origin/dev

就可以自动关联分支，而不需要：

1
$ git branch --set-upstream-to dev origin/dev

上面这条命令是在你本地已经建立了dev分支，但是还没有和远程dev分支关联的时候采用

rebase(变基)

http://gitbook.liuhui998.com/4_2.html

https://www.cnblogs.com/pinefantasy/articles/6287147.html