之前我们讲到使用git add .可以把工作区的修改提交到stage：暂存区，之后再通过git commit -m"描述"把代码提交到分支上，如此一个链路便形成了一个版本。
在上一节里我们只知道有分支这个东西，代码被推倒分支上就可以形成一个新的版本，并返回一个版本号，但分支是什么呢？我们好像从来没有主动去创建过分支，那么他是从哪里来的呢？这节课我们来揭开分支的迷雾，完成多人开发的需求。
我们在使用git init创建一个git仓库时，git就为我们自动创建了一个叫做master的分支（master分支是主分支）。
创建分支：
git branch 分支名称
切换分支：
git switch 分支名称
以上两部操作可以进行合并：
# 这行命令表示的是创建一个分支并切换到这个分支
git switch -c 分支名称
查看分支：
# 查看一共有多少个分支和现在在哪一个分支上，当前分支的前边有一个*
git branch
如果当前分支是a，此时你创建了一个b分支，那么b分支里的代码将会和a分支一模一样，例：
# 假设现在在master(主)分支上
git switch -c dev
# 此时我们在master的基础上创建了一个dev分支，并切换到了dev分支如果对比代码我们将发现，两个分支上的代码一模一样
在切换出的dev分支上完成开发后，把代码提交到dev分支：
git add .
git commit -m"版本信息"
代码提交到dev分支后，此时master分支上并没有最新的代码，这是我们需要把dev分支上的代码合并到master分支上，合并分支使用命令：
git merge 分支名称
删除分支：
git branch -d 分支名称
其实不是每一次合并分支的时候都是一帆风顺的，比如我们现在需要修改一个bug，我们从master分支上切了一个新的分支dev，我们在dev分支上完成修改后进行提交，切回master分支，对master分支也做了修改，修改之后提交，接着我们去合并dev分支上的代码，发现合并失败。在这种情况下git无法对两个分支进行合并，只能尝试把各自的修改合并起来，这种合会出现冲突，我们需要手动去解决冲突。解决完冲突之后:
# 手动解决冲突之后，再master分支上：
git add .
git commit -m"版本信息"
# 接着再删除dev分支就可以了。
git switch dev
git branch -d dev
而在实际开发中，master分支应该是非常稳定的，也就是仅用来发布最新版本，平时不能在上面干活。
而合并分支我们有两种方式：
git merge 分支名称
# 如果用git merge来合并的话我们是查看不到分支的合并历史的，因为 git merge是快进模式。
# 除了git merge之外还有一种普通合并的模式，使用命令：
git merge --no-ff -m"版本信息" 分支名称
#上边这条命令为什么要加-m参数呢？因为普通合并模式下，git就会在merge时生成一个新的提交，
# 这样，就可以从分支历史上查看的到。而使用git merge是查看不到合并的历史的，那我们如何查看分支
# 历史呢？使用：
git log --graph --pretty=oneline --abbrev-commit
分别使用两种不同的合并方式合并分支时，我们打印出来的分支历史是不一样的。
在实际开发中，bug就像家常便饭一样。有了bug就需要修复，在使用git的时候，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
加入你现在正在开发一个新功能，突然接到一个紧急任务，让你修复一个代号为101的bug，很自然得，你想创建一个分支issue-101来修复它，但是你开发新功能的代码还没有提交，并不是你不想提交，而是工作只进行到一半，还没法提交，幸好git还提供了一个临时存储功能，可以帮你把没有提交的代码临时藏起来，等需要的时候再拿给你：
# 使用git stash命令可以把之前写的代码暂时隐藏起来
git stash
那么修复完bug之后我如何把隐藏起来的代码再回复回来呢？
# 查看被隐藏起来的代码
git stash list
# 恢复代码使用
git stash pop
这是针对单次的隐藏，如果针对多次隐藏呢？使用：
git stash apply stash@{}
# 接着删除某个隐藏
git stash drop stash@{}
# git stash pop可以同时完成这两步但是不适合多个隐藏
刚刚我们在master分支上修改了一个bug，而我们现在开发新功能的分支就是从master上切换出来的，那么也就是说master分支上的bug现在也存在于开发新功能的分支上，为了避免重复操作，我们可以使用:
# 这条命令只会把修复master分支bug的代码合并过来
git cherry-pick 版本号(这里的版本号指的是刚修复master分支bug后提交的版本号)
在软件开发中，总是有做不完的新功能，在开发新功能的时候必定要取修改原来的代码，这样如果最后遇到bug整个项目就game over了，所以每添加一个新功能，最好创建一个新的分支，开发成功后合并再删除新分支就可以了。但是有的产品经理太傻比了，真他吗的傻比，跟你说开发一个新功能，功能开发完了他又说要把这个新功能给剪掉，开发之前脑子让门挤了吗？不过还好我们并没有把新功能分支上的代码合并到主分支上，那么我们这次使用：
git branch -d 分支名称
# 这是git给我们报错说这个分支的代码提交后没有合并，因此我们不能删除，不过我们可以强制删除
git branch -D 分支名称
我们在向远程仓库推代码的时候使用的是：
git push origin 分支名称
可是问题来了，我们和其他小伙伴都在开发，分别开发不同的功能，这样不同的人往一个仓库的同一个分支推送东西就产生一种情况，就是我们本地的代码和远程仓库里的代码不同步，如果你的小伙伴比你推送的时间早，那么你再推的时候就推不上去了，因为你你小伙伴最新提交和你视图推送的提交有冲突，解决办法很简单：
# 使用git pull拉去最新的代码，然后在本地合并解决冲突后再推送，
git pull origin 分支名称
# 如果拉去失败，说明本地的这个分支和远程的这个分支没有建立连接，那么我们要手动的建立这个链接
git branch --set-upstream-to=origin 远程分支名称 本地分支名称
# 接着再使用 git pull就可以了
git pull origin 远程分支名称
# 我们从远程分支拉去最新代码后如果产生冲突，则需要手动解决冲突，冲突解决之后需要提交再推
git commit -m"提交信息"
git push origin 分支名称
所以在多人协作的时候流程大概是这样的：
- 视图把本地的代码推送到远程分支上
git push origin 分支名称，结果推送失败。 - 接着从远程分支拉去代码，
git pull origin 分支名称，如果有冲突手动合并冲突。 - 使用
git push origin 分支名称。 - 所以每次提交前先
git pull一下是个好习惯。
标签：
假如你的leader（领导）问你要某个版本的代码，发给你了一串类似于a10996b的版本号，那么接下来你可能要进行的操作是：
git log # 结果返回了一大推的版本号
而要找到这个叫做a10996b可能头都找破了也没找到，这时要是给每次提交都打一个简单的标签，必须：v1.0，那么你的boss可能对你说的是，小王，把那个0.9版本的代码发我一下，那么你只要找到提交时被标记了v0.9的版本给他就可以了，这个操作在git中可不可以实现呢？当然是可以的，怎么做呢？
# 先切换到指定分支
git switch 分支名称
# 接着
git tag v1.0
# 这样就ok了，那怎么查看有多少个版本呢？使用：
git tag
#上边这条命令会返回所有的版本号
# 那如果上次的版本我忘记打标签了呢？没关系，先使用 git log查找到历史
git log --pretty=oneline --abbrev-commit
# 找到版本号之后
git tag v0.9 版本号
# 如果标签打错了，也可以删除
git tag -d v1.0
