首先假设我们的仓库有两个远程分支，请看下图：
远程分支
为什么要两个远程分支，那就要说下分支策略了，这里我们借用大神的内容：
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
分支策略
上图中的master和dev就是我们第一张图中的两个远程分支，而michael、bob等就是每个人工作的分支，到时候都会合并到dev或者master上面去。当然，还会有诸如bugfix-22022等等等等的分支。但是，每一个远程分支都会有对应到你机器的本地分支才行，当然，图省事，你也可以就有一个对应远程dev分支的本地分支，我们也给它起名叫dev吧。
1. 查看本地分支
$ git branch
本地分支
标*号的即为目前所在的分支
2. 查看远程分支
$ git branch -r
远程分支
3. 查看所有分支
$ git branch -a
所有分支
4. 切换分支
$ git checkout -b dev origin/dev
1中本地的dev分支是怎么来的呢，就是通过上面的命令生成的，过程是checkout远程的dev分支，在本地起名为dev分支，并切换到本地的dev分支。
5. 合并分支
$ git checkout master
$ git merge dev
上面的语句是将dev分支合并入master分支。注意哦，合并前要先切回要并入的分支。
5. 删除分支
$ git branch -d bug-220200
合并完，没有用的分支就可以删掉了
7. 本地分支合并冲突
往往你会遇到这种情况，假设在本地的dev分支和master分支上你都修改了一个文件而且修改点不一样，并且你还在这两个分支上都完成了commit操作，当你merge时会出现一个报错：
合并冲突
提示很明显，<Live/CSV_Config_PUB.csv>这个文件中有冲突存在，除非解决，否则不能合并。
我们看下这个文件：
冲突文件内容
GIT还是很友好的，它把冲突的行都显示出来了，我们只要决定怎么改就行了。修改完文件，进行正常的提交操作即可：
$ git add <file>
$ git commit -m "conflict fixed"
$ git push
8. 协作上传远程分支冲突
多人协作时，大家都会往远程分支提交代码，我们在这里假设分支是origin/dev，A和B两个人都可以往这个分支push代码。
场景是A修改了文件1并完成了push，之后B在没有git pull的情况下也修改了文件1并进行push操作，很明显会出现问题。
解决这个问题，B需要这么做：
$ git pull
合并有冲突时，需要手动解决，解决的方法和8中做的完全一样
$ git commit -m "conflict fixed"
$ git push
9. stash、cherry-pick、rebase
- 当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；
- 在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。
- rebase操作可以把本地未push的分叉提交历史整理成直线，目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。
网友评论