Git系列
目录
一、分支管理
分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。
但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。
二、创建于合并分支
主分支，即此前提及的master分支。
1、原理部分
HEAD指针严格来讲不是指向提交，而是指向master，master是指向提交的。
HEAD指向的是当前分支。
每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。
当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：
你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！
不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：
所以Git合并分支也很快！就改改指针，工作区内容也不变！
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
2、实践
（1）创建dev分支，然后切换到dev分支：
git checkout -b dev相当于：
git branch dev
git checkout dev
（2）用git branch查看当前分支
当前分支前有*号。
（3）提交当前分支
（4）切换回master分支
切换回master分支后查看此前修改的文件，发现修改不见了。因为那个提交在dev分支上，而master分支此刻的提交点没有变。
（5）分支合并
将dev分支的工作成果合并到master分支上。
再查看修改的文件，发现文件已经修改完成。
Fast-forwar表示直接把master指向dev的当前提交。还有其他合并方式。
（6）删除分支
完成合并后，dev分支没用了。所以，删除。
git checkout <branch>和git checkout --<file>命令有区别。
切换分支命令可以使用switch。
3、命令总结
三、解决冲突
1、准备新的分支feature1，继续分支开发。
继续修改文件后commit，然后切换回master
提示当前master分支比远程master分支超前1个提交。
修改master分支的文件。（和刚才feature1分支修改同意一个文件，并提交）。
所以现在在master分支和feature1分支各自都有新的提交。
这时候无法执行“fast forward”，只能试图把各自的修改合并起来，但这种合并可能会存在冲突。
发生冲突，添加了一个文件.txt文件存在冲突，必须手动解决冲突后再提交。git status
直接查看文件，发现分别标注了master和feature1上的修改。
（Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：）
修改这个文件后，再次提交
此时分支变为：
用带参数的git log可以查看分支合并情况。
删除feature1分支。
四、分支管理策略
通常，合并分支时，如果可能，Git会用Fast forward模式，这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，git就会在merge时生成一个新的分支，这样，从分支历史上就可以看出分支信息。
创建git分支。
git checkout -b dev修改文件并提交后，切换回master分支。
准备合并dev分支， --no-ff参数，表示禁用fast forward:
本次合并要新建一个commit，所以加上-m参数，把commit描述写进去。
git status
git stash list命令查看工作现场。
恢复现场：
git log查看
分支管理策略：
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
五、 Bug分支（stash功能,cherry-pick）
https://www.liaoxuefeng.com/wiki/896043488029600/900388704535136
软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交，此时要用stash功能，保存现场，等以后恢复现场继续工作。
恢复指定stash：
$git stash apply stash@{0}复制一个特定的提交到当前分支：
六、Feature分支
用于添加功能时，每添加一个新的功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除feature分支。
摘自：https://www.liaoxuefeng.com/wiki/896043488029600/900394246995648
添加一个新功能，可以开一个feature分支，完成功能后与主分支进行合并。
如果进行功能开发时要舍弃该分支：
git branch -d feature当输入上述命令时，会报错。
类似这样的错误，所以要强行删除。
git branch -D feature七、多人协作
当从远程仓库克隆时，实际上git自动把本地的master分支和远程的master分支对应起来，并且，远程仓库默认名称为origin。
要查看远程库信息，用
上面显示了可以抓取和推送的origin地址。如果没有推送权限，就看不到push地址。
1、推送分支
推送分支，就是把该分支上所有本地提交推送到远程库。推送时，要指定本地分支，这样，git就会把该分支推送到远程库对应的远程分支上：
git push origin master如果要推送到其他分支，如dev，则
git push origin dev并不是一定要把本地分支往远程推送。
master分支是主分支，因此要时刻与远程同步。
dev是 开发分支，团队所有成员都需要在上面工作，因此也要远程同步。
bug分支只用于在本地修复bug，所以无需推送；
feature分支是否推送取决于你是否和小伙伴合作开发。
2、抓取分支
多人协作时，大家都会往master和dev分支上推送各自的修改。
在从远程仓库clone到本地另一个目录，然后查看branch，发现只能看到master。
而在原来的目录中可以看到，有dev，有master。
当我在新的项目中的dev分支上进行开发，必须创建远程origin的dev分支到本地。
git checkout -b dev origin/dev然后在dev分支上做一些修改：
在原项目的dev分支上搞事，然后试图push，出现了故障：
因为两边的提交有冲突，所以现在需要解决，用git pull把最新的提交从origin/dev抓下来，然后在本地合并解决冲突后，再push
git pull失败了，因为没有指定本地dev分支与远程origin/dev分支的链接。
所以根据提示：
上面需要解释以下为什么要合并……解释完之后，似乎合并成功了。（冲突解决于分支管理中的冲突解决相同）
特别注意，上面的合并是使用“recursive”策略合并的。合并策略转https://blog.csdn.net/chaoguo1234/article/details/81277475
解决之后，再push。
可以查看git log，发现上次冲突解决之后，
多了这样一个合并版本。
重新push，成功。
所以我们来看一下版本更新合并的图：
（因为比较菜，所以这些说明，瞎看吧，具体项目中要规范！）
所以综上所述！多人协作工作流程就是：
-
首先，可以试图用
git push origin <branch-name>推送自己的修改； -
如果推送失败，则因为远程分支比你的本地更新，需要先用
git pull试图合并； -
如果合并有冲突，则解决冲突，并在本地提交；
-
没有冲突或者解决掉冲突后，再用
git push origin <branch-name>推送就能成功！
如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。
八、Rebase——git rebase
上面的蜜汁分支图看起来不大舒服，所以如何将git提交历史变成干净的直线？
来自：廖雪峰官方网站。
https://www.liaoxuefeng.com/wiki/896043488029600/1216289527823648
算了，这个太复杂，直接廖雪峰官方网站看吧，传送：
https://www.liaoxuefeng.com/wiki/896043488029600/1216289527823648
总结：
rebase 操作可以把本地未push的分叉提交历史整理成直线；
rebase的目的是使我们在看历史提交的变化时更容易，因为分叉的提交需要三方对比。
直接git rebase！
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
