工具-Git与GitHub-分支管理（99.5.2）

@

1.分支介绍

创建了一个属于自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上

2.基本使用分支

注意
所有的操作都基于已经使用git的文件夹（工程目录）

1.查看分支

git branch

2.创建一个分支dev并切换到其上进行工作

git checkout -b dev

此时状态指针状态

3.在dev分支中变更已经追踪的文件，并进行提交

#添加到stage（假如工作区已经修改这个文件）
git add 1.txt 
#提交到版本库
git commit -m "dev分支第一次"

此时状态指针状态

4. dev分支的工作完成，可以切换回master分支

git checkout master

此时状态指针状态

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

git merge dev

这次合并是“快进模式”(Fast-forward)，也就是直接把master指向dev的当前提交，所以合并速度非常快。因为此时master没有更改，所以直接指向就完事

此时状态指针状态

6.合并完成后删除dev分支了

git branch -d dev

3.解决冲突

此时指针状态（master，dev都有修改），此时去merge。git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。此时合并会生成一个新的提交，假设现在已经在master分支使用fast合并了一次，没有成功(git merge dev)，提示必须在master手动解决冲突文件再提交

1.查看冲突文件（就是两边都有修改的文件）

git status

2.手动修改冲突文件，再加入缓存区，提交

#添加到stage（假如工作区已经解决这个冲突文件）
git add 1.txt 
#提交到版本库
git commit -m "解决master和dev的冲突"

此时指针状态

3.查看状态，在命令行以图的方式查看

git log --graph

4.合并完成后删除dev分支了

git branch -d dev

3.分支管理策略

通常合并分支时，如果可能，git会用fast forward模式，但是有些快速合并不能成而且合并时没有冲突，这个时候会合并之后并做一次新的提交。

1.切换到dev分支下，并新建了一个文件提交到dev版本库

#在master分支下运行，创建dev分支并且切换过去
git checkout -b dev
#加入暂存区（创建2.txt后）
git add 2.txt
#提交到版本库
git commit -m "dev创建了2.txt"

2.切换回master分支，编辑1.txt并进行一个提交

#切换到master
git checkout master
#加入暂存区（修改1.txt后）
git add 1.txt
#提交到版本库
git commit -m "master更改1.txt"

3.合并dev分支的内容到master分支

#切换到master
git checkout master
#加入暂存区（修改1.txt后）
git add 1.txt
#提交到版本库
git commit -m "master更改1.txt"

4.删除dev分支

git branch -d dev

4.强制禁用fast forward模式

前提使用merge的时候没有冲突

git merge --no-ff -m "强制合并dev和master" dev

5. Bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。假如当前在dev分区干活

1.把当前工作现场“储藏”起来，等以后恢复现场继续工作

git stash

2.假定需要在master分支上修复，就从master创建临时分支

git checkout -b bug_master_001

3.修复完成提交

4.回到dev分支还原现场

git checkout dev
git stash pop

关于作者

个人博客网站
个人GitHub地址
个人公众号：

转载于:https://www.cnblogs.com/simon-idea/p/11437762.html