版本控制系统之Git学习四

分支管理

使用Git进行工作时，可以创建一个属于自己的分支，别人看不到这个分支，你可以在自己的分支上进行工作（这项工作可能需要较长时间，而你把未完成的工作放在主分支上，别人clone下来并不能工作），随时将自己的工作进行保存，这样既安全，也不会影响别人的工作。

创建和合并分支

首先，创建banana分支，并切换到banana分支：

git checkout -b banana

或使用以下命令

git branch banana
git checkout banana

或者使用switch（这种方式更科学，最新版本的git提供了switch）

git switch -c banana

成功后，可以查看当前分支

git branch

可以看到，当前有两个分支，master为创建仓库时默认创建的分支，banana是新创建的分支，并且当前分支是banana，用*标示。
现在，所有的操作都是在banana分支上进行，
对file.txt文件进行修改，同时进行提交，然后，使用命令切换回master分支：

git checkout master

或使用命令

git switch master

查看file文件，发现刚才的更改不见了，这是因为刚才的提交是在banana分支上，master分支并没有改变。
在banana分支上的工作完成后，将其合并到master分支上，然后删除：

git merge banana
git branch -d banana

注意到输出信息有个fast-forward，git告诉我们这次合并是‘快进模式’。
查看file文件的内容，发现刚才的修改出现了，同时使用git branch查看分支，发现只剩下master分支：

解决冲突

当合并两个分支时出现冲突

这一般出现以下情况：
创建了一个新的分支，在该分支下对文件进行了修改并提交，然后切换回主分支后，又对文件进行了修改并提交，此时合并的话就会出现冲突。
解决冲突的方法：
1）打开文件

git 标记了不同分支的内容。
2）把这一段文字修改为想要的内容，然后再进行提交。
3）删除新建的分支
至此，冲突解决完成。
可以使用带参数的git log看到分支的合并情况：

git log --graph --pretty=oneline --abbrev-commit

用git log --graph可以查看分支合并图。

分支管理策略

前面讲过，使用git合并分支时，git回使用Fast forward模式，这种合并模式下，删除分支后，分支的信息也被丢失了。
如果要禁用该模式，可以使用命令：

git merge --no-ff -m "merge with no-off" dev

由于使用这种方式的merge，git在合并时会生成一个新的commit（这样在分支历史上就可以看出分支信息），因此，在合并时使用-m参数把commit描述写进去。
使用命令

git log --graph --pretty=oneline --abbrev-commit

可以看到git合并的信息。

分支策略：
在工作时要保证master分支是稳定的，每个人平时的工作都应该提交到一个共同的分支（如dev分支上，不能是master分支），而且每个人都需要创建一个自己的分支。团队合作的分支看起来就像下图

当所有的工作完成后，将dev分支合并到master分支，分支合并时应该使用参数来选择普通合并模式，这样的话，合并的历史就可以查看，便于之后的查错。

bug分支

当我们在工作时（在dev分支上进行工作），需要修复master分支上的bug，需要做的步骤：
1）保存当前分支的工作，并使用命令

git stash

将当前的工作现场“储藏”起来，等以后恢复现场后继续进行工作。
2）切换到master分支下，创建一个新的分支用于修复bug

git checkout master
git checkout -b issue-101

然后进行bug修复工作，并进行提交

git add file.txt
git commit -m "fix bug 101"

接着切换到master分支，将新建分支的bug修复工作合并到master分支下

git checkout master
git merge --no-ff -m "merged fix bug 101" issue-101

删除新建的分支

git branch -d issue-101

3）恢复dev分支的工作现场
使用命令

git stash list

查看工作现场的内容。
恢复工作现场有以下两种情况：
（1）工作现场只有一个

git stash pop

恢复的同时也把stash中的内容也删除了。
（2）工作现场有多个

git stash apply stash@{0}
git stash drop

第一个命令是选择恢复需要的工作现场，第二个命令是删除stash的内容。

4)bug修复完成，切换到dev分支，并在dev分支修复同样的bug（dev分支是早期从master分支出来的，因此，这个bug在dev分支也存在）
使用命令

git cherry-pick f24fa8c

其中，f24fa8c是修复bug时使用命令git commit -m "fix bug 101"返回的commit id。
这个命令的功能是复制一个特定的提交（f24fa8c）提交到当前分支，这样就不需要在dev分支上手动把修复bug的过程重复一遍。

也可以在dev分支上创建一个新的分支进行bug修复，然后在master分支上使用git cherry-pick 进行bug修复复制，当然需要注意⚠️的是，在修复bug之前，需要将工作现场使用git stash来隐藏。

Feature分支

在工作过程中，通常会需要创建新的分支来添加新功能，一般过程是新建新分支feature，然后在新分支下进行工作，工作完成后，提交，然后切换到dev分支，将feature分支合并，然后将feature分支删除。
分支删除命令：

git branch -d feature

若此时还没有进行合并就需要进行分支删除，使用上述命令，会提示未合并删除失败，此时，需要使用命令：

git branch -D feature

对分支进行强制删除。

多人协作

当从远程仓库clone时，Git自动把本地的master分支与远程的master分支对应起来，且远程仓库的默认名称为origin。
可以使用命令：

git remote

查看远程库的信息。

git remote -v

查看远程库的详细信息。

推送分支

默认是将本地的所有提交推送到远程master分支：

git push origin master

若想推送到其他分支（如dev，若远程仓库还没有这个分支，使用下面的命令后会自动创建一个dev分支），则使用命令：

git push origin dev

在本地创建一个与远程分支对应的分支，使用：

git checkout -b dev origin/dev

dev:本地分支
origin/dev:远程仓库分支

抓取分支

抓取分支可以使用命令

git clone git@github.com:123banana/learn_git.git

git clone后的地址是用抓取远程仓库的SSH地址或https地址。
在多人协作的情况下，若你要推送分支的内容被其他小伙伴修改、提交并推送，此时你的修改推送到远程仓库会出现推送失败：

此时，可以按照提示先使用git pull把最新的提交抓取下来，然后在本地合并，解决冲突，再次推送，但是，当使用git pull命令后出现以下报错：

可以按照提示设置本地dev分支与远程origin/dev分支进行链接：

git branch --set-upstream-to=origin/dev dev

再次使用命令git pull，进行抓取最新内容，此时会出现合并冲突：

可以使用上面写过的解决冲突的方法来实现，解决后，提交并进行push。

推送分支和抓取分支在多人协作中工作模式中最重要的两个部分。

Rebase

命令

git rebase

可以使原本分叉的提交整理成一条直线，即把本地未push到远程的分叉提交历史整理成一条直线，目的是使我们在查看历史提交的变化时更容易。
使用上述命令后，可以使用命令

git log --graph --pretty=oneline --abbrev-commit

查看提交历史图形模式。