下午篇
踉踉跄跄，辗转到了下午篇。恬静的午后，掠去浮华，清风含香，不妨泡杯茗茶，来首--Look At Me(Alan Jackson)，像青草一样呼吸。在下午篇中我们会讲到分支管理的序章，git github在实际项目中的应用。
编码的过程有时就是一个不断处理BUG的过程。比如前天你接到一个任务，需要开发一个新功能，这时你建了一个新分支，名为formerly，昨天开发完了，将其合到master分支上，然后push到远程仓库。今天你正在做另一个功能，并重建分支future，还没有完成(还没有add)，不能提交。此时领导告诉你昨天的代码有BUG，即使你心中有一万头草泥马，你改或者不改，BUG就在那里。我们的处理方法是
分支管理的序章
将当前工作现场保存起来：$ git stash
确定需要在哪个分支上修复BUG，就切换到哪个分支上创建临时分支，git checkout master(假定在master分支)；git checkout -b <临时branch name>；修改file后；git add <filename>;git commmit -m "solve bug";git checkout master;git merge --no-ff-m "" <临时branch name>;git branch -d <临时branch name>;git checkout funture(工作现场被保存起来的分支);
刚才的工作现场：$ git stash list
恢复被保存的现场并干掉stash: $git stash pop
因为已经经过朝阳篇，上午篇，中午篇，这里就不再一次敲命令了。只要思路清晰，命令不敲错，应该没问题的。
至于为什么我们需要将正在进行未add的文件工作现场保存起来，一是当前分支(funture)的功能未开发完，在多人协同工作时，若将未完成的代码上传会影响别人的工作。二是，在大型项目中，你当前分支（funture）,有许多代码未提交（要切换分支必须commit之后），不建议你commit当前分支，因为如果把你现在修改的文件(一般都不止一个)提交的话 之后 你再回来找哪些代码是完成了一半就提交了，那些是真正提交的区分起来就会很麻烦；另外一个原因就是，虽然commit可以一次性提交多个add,但是commit之前的add，你需要把文件一个个add，麻烦不言而喻。还不如把当前工作现场存储起来。问：为什么切换分支必须commit，见下图
问，为什么修改一个bug需要重建一个分支，我个人觉得是安全吧，不影响其他分支工作，完成后合并分支，最后删除该分支，思路比较清晰。
工作流二三技
查看远程信息:$ git remote -v (显示可以抓取和推送的origin的地址)
推送分支：$ git push origin <分支name>
抓取分支：$ git clone git@github.com:xiakejie/remotegit.git (这里的remotegit并不是指本地仓库，二是你要克隆的远程仓库)<另外，此操作只克隆到远程仓库remotegit的master分支>
抓取远程仓库的其他分支：$ git checkout -b branchname origin/branchname (即在本地创建远程分支对应的分支)。
注意，用git命令克隆前，克隆的目录一定要是git可管理的目录。
抓取其他分支
抓取前README.md的内容如下：
打开本地MEADME.md文件添加两句话，add some words,push to origin dev，执行如图命令
然后刷新hubgit，打开gitskill仓库，选择dev分支，打开README.md文件，查看前后变化。本地目录也有变化。
更新代码:git pull
在push前，一定要先pull
现在我们的 git github小白看过来 就全部梳理完了。如有不懂，请回看前几篇。