git分支操作

初始化项目

初始化一个git仓库，做一次提交操作

创建分支

git branch #创建指定名称的分支

查看分支

git branch #查看所有分支，* 号代表当前工作分支
git branch -v #查看分支详情，包括分支指向的commitId及提交信息

示例：新建一个dev分支，查看分支信息

切换分支

git checkout #切换到指定分支
git checkout -b #创建并切换到指定分支

示例：切换到dev分支，然后添加dev.txt文件并进行提交

在dev分支上创建并切换到test分支

删除分支

git branch -d
.#删除一个干净的分支(即相对当前分支而言该分支没有新的提交记录)
git branch -D
.#强制删除一个分支，该分支有没有合并到当前分支的提交记录
注意：删除分支前都需要先切换到其他分支才能进行删除操作

示例：在dev分支上删除test分支，test分支相对于dev来说是干净的分支，所以可以直接删除，然后切换到master分支，删除dev分支，此时需要进行强制删除。

分支恢复

思路：对于已经有提交记录的分支删除后，实际上只是删除指针，commit记录还保留，如果想恢复，需要使用git reflog查找该分支指向的commitId，然后根据commitId创建新的分支
git branch #根据指定commit创建新分支

示例：恢复已经删除的dev分支，该分支新增了dev.txt文件

重命名分支

git branch -m newname

分支合并

git merge #将指定分支合并到当前分支
如果两个分支没有产生分叉情况，那么会进行快速合并，即fast-forward方式，它并不会产生新的commitId，只是改变了指针的指向，产生分叉合并可能会有冲突情况。

示例：合并pro分支到master分支，此时合并为fast-forward方式

分支合并细节

git merge --no-ff -m "msg" #合并分支时禁用Fast forward模式
我们知道如果使用fast-forward方式进行分支合并，只是简单改变了分支指针，而不会产生新的commit记录。
为了保证合并数据的完整性，我们也可以在合并时指定不使用fast-forward方式，使用 --no-ff 选项。这样，在merge时就会生成一个新的commit，从日志上就可以看到分支合并记录了。

示例：我们在pro分支上新增一次提交，然后合并到master分支上，git log查看最新一次的提交记录，显示的正是我们合并分支时的记录

冲突解决

当对分叉分支进行合并时，如果两个分支都对同一文件进行了修改，那么合并时就有可能会产生冲突情况。
如果两个分支对同一文件的修改是有规律的，比如对不同地方的修改，那么git工具可以实现自动合并，如果无法自动合并，则需要对冲突文件进行手动修改，修改完成后使用git add表示冲突已经解决，然后使用git commit进行提交

示例：在master分支上对两个文件进行修改提交，分别在dev文件的第一行和readme文件的最后一行添加内容。

然后切换到pro分支上对两个文件进行修改提交，分别在dev文件的最后一行和readme文件的最后一行添加内容。

此时进行合并分支操作，提示说readme文件产生了合并冲突(merge conflict)，dev文件由于修改的是不同地方，所以自动合并。
我们查看readme文件的内容，==上面和下面的内容分别代表了不同分支的修改内容，将冲突标记去掉，然后内容根据需求进行恰当的修改，然后进行一次提交即完成了冲突的解决。

分支暂存

git stash #将工作暂存
git stash list #列出所有的暂存状态
从暂存区之中进行恢复，有两种处理方式：
1.先恢复，而后再删除暂存
git stash apply
git stash drop
2.恢复的同时也将stash内容删除
git stash pop
当我们在分支上进行代码开发时，有可能会接到突发需求，而当前的代码尚未完成，所以还不能直接提交。
为了解决这样的问题，git就提供了分支暂存的机制，可以将开发一半的分支进行保存，在适当的时候进行代码恢复。

示例：在pro分支上新建文件，然后添加到暂存区表示尚未完成的任务，对当前分支进行暂存，git status显示工作空间是干净的。此时应该切换到master分支上创建新的分支完成突发需求(这里就不做演示了)，然后进行分支恢复。