Git 分支管理与冲突处理

Git 分支管理

创建与合并冲突

分支管理

1.在原有master基础上，创建dev分支：

​ $ git branch dev

切换到dev分支：

​ $ git checkout dev

2.之后在dev分支上正常提交add、commit，dev分支的工作完成；

3.切回master分支，把dev分支的工作成果合并到master分支上：

​ $ git checkout master

​ $ git merge dev

git merge 命令用于合并指定分支到当前分支，查看文件是否提交成功；

4.合并完成后，则可以放心的删除dev分支：

​ $ git branch -d dev

5.删除后，查看branch，就只剩下master分支了。

​ $ git branch

switch

切换分支：git checkout

撤销修改：git checkout –

这两个命令有时会让人迟疑迷惑，于是使用switch来切换分支也可以：

1.创建并切换到新的dev分支，可以使用：

$ git switch -c dev

2.直接切换到已有的master分支，可以使用：

$ git switch master

小结

Git鼓励大量使用分支：

查看分支：git branch

创建分支：git branch

切换分支：git checkout 或者git switch

创建+切换分支：git checkout -b 或者git switch -c

合并某分支到当前分支：git merge

删除分支：git branch -d

解决冲突

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

用git log --graph命令可以看到分支合并图。

分支管理策略

分支策略

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

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

小结

合并分支时，Git会使用Fast forward模式，这种模式下删除分支后，会丢掉部分分支信息，因此，在团队协作开发项目时，加上–no–ff参数就可以用普通模式合并，合并后的历史有分支，能看出分支历史，而fast forward合并就看不出来曾经做出合并。

Bug分支

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

正在工作，接到修复一个bug任务101时，想创建一个分支issue-101来修复它，可是当前正在dev上进行的工作还没有提交，如果工作只进行到一半无法提交，可需要紧急修复该bug，此时：

Git还提供了一个stash功能，

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

​ $ git stash

2.确定bug在哪个分支，就在那个分支下创建临时分支；假设在master分支下，就从master创建临时分支：

​ $ git checkout master

​ $ git checkout -b issue-101

3.修复bug后，提交，add-commit

4.切回master分支，删除issue-101分支，注意是–no–ff模式

​ $ git switch master

​ $ git merge --no-ff -m “merged bug fix 101” issue-101

5.切回原来工作的dev分支，查看工作区,找不见原来的工作现场很慌？往下看

​ $ git switch dev

​ $ git status

6.用git stash list查看工作现场，应该还在

​ $ git stash list

7.恢复工作现场方式A：git stash apply恢复，git stash drop删除stash内容

​ 方式B：git stash pop 恢复同时把stash内容删除

8.用git stash list查看stash内容，果然没了。也可以多次stash，恢复的时候先用git stash list查看，然后恢复指定的stash，用命令：

​ $ git stash apply stash@{0}

在master分支上修复完bug后，由于dev分支是早期从master分支分出来的，应该存在想相同的bug，如果此时重复操作一遍还有些繁琐，Git提供比较方便的方法：cherry-pick命令，能复制一个特定的提交到当前分支：（刚刚修复的提交为4c805e2 fix bug 101 ）(4c805e2为刚刚的提交代号，后面的为提交说明解释)

$ git branch

$ git cherry-pick 4c805e2

此时Git自动给dev分支做了一份提交，这次的提交commit是新的代号，并不是原来master分支提交的代号4c805e2，两次commit虽然改动相同，但确实两个不同的commit。

如果在dev上修复bug，在master分支上也有相同的bug，此时操作方法与上面相同。注意一定要git stash保存当前工作现场。

小结

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

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

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

Feature 分支

在软件开发中，总要添加新的功能，一般不建议在maste上支直接添加实验性的功能代码，通常会新建feature分支，完成后合并，删除feature分支。

多人协作

当从远程仓库克隆时，实际上Git自动把master分支和远程的master分支对应起来了。远程仓库默认名称为origin。

查看远程库信息;

​ $ git remote

或者，git remote -v更为详细，显示了可以抓取和推送的origin的地址，如果没有推送权限，就看不见push的地址。

推送分支

就是把所有本地提交推送到远程库。推送时，要指定本地分支。这样，git就会把该分支推送到远程库对应的分支上：

$ git push origin master //推送本地master分支

$ git push origin dev //推送本地dev分支

抓取分支

多人协作工作时，大家都会往master和dev分支上推送各自的修改。