Git学习(第七天) 我们在合并分支时，Git会用到”Fast forward“模式，在这种模式下删除分支后会丢掉分支信息。如果我们要强制禁用”Fast forward“模式，Git就会在merge时生存一个新的commit，这样从分支历史上就可以看出分支信息。那么，如何强制禁用”Fast forward“模式呢？在merge时 加上参数 --no-ff 即可。创建并切换一个分支dev：$ git checkout -b dev Switched to a new branch 'dev' 修改readme.txt文件并提交：$ git add readme.txt $ git commit -m '修改readme' [dev c835981] 修改readme 1 file changed, 1 insertion(+) 提交完成后切换至master：$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 7 commits. (use "git push" to publish your local commits) 现在开始合并dev分支到master，在使用merge时使用--no-ff禁用”Fast forward“：$ git merge --no-ff -m '禁用fast forward方式合并文件' dev Merge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+) 因为本次禁用了”Fast forward“合并会创建一个新的commit，所以在后面加上了-m参数，把commit描述写进去。合并后可以使用git log查看分支历史：$ git log --graph --pretty=oneline --abbrev-commit * 068ed5b (HEAD -> master) 禁用fast forward方式合并文件 |\ | * c835981 (dev) 修改readme |/ * da26543 修改文件内容 |\ | * cfc178e 修改Git为git * | 898bd79 修改文字为繁体字，修改标点符号为英文 |/ * e235cf1 一个新的版本 * 081fd0d 修改后的文件 |\ | * 3b0631c 分支冲突解决学习1 * | 607fe21 修改的今天修改的内容【学习分支冲突解决方法】 |/ * cde8ce3 (GitGo/master) 添加测试文件 * 742b3d0 新增许可证描述文件；修改项目说明文件； * 53b0c21 添加了一段文字 Add Time:2017-01-05 * 4b7b169 修改描述文档 * 068eefe wrote a readme file 可以从上面的操作历史中看到，不使用"Fast forward"模式，merge后就像这样：分支策略：通常在实际的开发中，我们应该按照几个基本原则进行分支管理：首先，master分⽀应该是非常稳定的，也就是仅用来发布新版本，平时不能在上⾯干活；那在哪干活呢？干活都在dev分支上，也就是说，dev分⽀是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分⽀发布1.0版本；你和你的⼩伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。所以，团队合作的分⽀支看起来就像这样：小结Git分支十分强大，在团队开发中应该充分应用。合并分支时，加上--no-ff参数就可以用普模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。BUG分支：软件开发中，产生BUG几乎是我们每天无法避免的一件事。当然，既然有了BUG那就需要修复。比如现有一个BUG需要马上进行修复处理。这个时候，就可以体现出Git中强大的分支管理了。我们可以通过一个临时分支来修复BUG，修复后合并分支，然后将临时分支删除。但接到一个修复的BUG任务，很自然地想到创建一个分支issue-105来修复他，但是我们当前正在dev上进行着开发工作，这部分代码还没有提交：$ git status On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt 由于我的功能开发到一半，预计开发完成至少还需要1天，很显然这个未完成的代码是不能提交的。但是目前必须需要在最短的时间内修复这个BUG，怎么办？强大的Git为我们提供了一个stash功能，可以把当前的工作现场”储藏“起来，等以后恢复现场继续工作：$ git stash Saved working directory and index state WIP on dev: c835981 修改readme 现在用git status查看工作区：$ git status On branch dev nothing to commit, working tree clean目前工作区是干净的（除还没有被Git管理的文件），因此可以放心的创建分支来修复Bug。首先得确认修复BUG是在那个分支上。假设我们需要在master上修复该BUG，就在master上创建临时的分支：$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 11 commits. (use "git push" to publish your local commits) $ git checkout -b issue-105 Switched to a new branch 'issue-105' 修改文件然后提交：$ git add test.txt $ git commit -m '修改BUG' [issue-105 05372b9] 修改BUG 1 file changed, 1 insertion(+), 1 deletion(-) 提交完成后，切换到master分支，合并issue-105分支，合并完成后删除issue-105分支：$ git checkout master Switched to branch 'master' Your branch is ahead of 'GitGo/master' by 11 commits. (use "git push" to publish your local commits) $ git merge --no-ff -m '修复BUG105' issue-105 Merge made by the 'recursive' strategy. test.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git branch -d issue-105 Deleted branch issue-105 (was 05372b9). 好的。BUG105我们已经修复并提交了master了。现在我们需要返回dev继续干刚才没有完成的活。$ git checkout dev Switched to branch 'dev' $ git status On branch dev nothing to commit, working tree clean 工作区我们刚刚在dev修改的文件，哪去了？不要着急。用git stash list 命令查看：$ git stash list stash@{0}: WIP on dev: c835981 修改readmedev的工作现场还在，Git只是把stash内容存放在某个地方了，但是需要恢复一下，有两个方法：1、 使用git stash apply 恢复，但是在恢复后，stash内容并没有删除，需要使用git stash drop 来删除；$ git stash apply On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt no changes added to commit (use "git add" and/or "git commit -a") $ git stash drop Dropped refs/stash@{0} (190f697d730a4a7816b3049acf7cf33d6d162162) 2、使用git stash pop，恢复的同时把stash内容也删除了：$ git stash pop On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt no changes added to commit (use "git add" and/or "git commit -a") Dropped refs/stash@{0} (62947f8efd82d5b72410cdabd47eaaffa4d53dca) 再用git stash list查看，就看不到任何的stash内容：$ git stash list可以多次stash，恢复的时候先用git stash list查看队列，然后恢复时指定stash序列；stash的队列是按照的时间的先后顺序倒叙排列的（即时间最新的在前，stash@{0}）;存在多个stash在不指明恢复序列，默认为队列第一个。$ git stash list stash@{0}: WIP on dev: c835981 修改readme stash@{1}: WIP on dev: c835981 修改readme stash@{2}: WIP on dev: c835981 修改readme $ git stash apply stash@{1} On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: LICENSE.txt no changes added to commit (use "git add" and/or "git commit -a") $ git stash drop stash@{1} Dropped refs/stash@{1} (159798b0499e0acf7cf33d6d162162a5fff64f0d) 修改BUG时，我们会通过创建新的BUG分支进行修复，然后合并，最后删除；当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复完成后，再git stash pop，重新回到工作现场。