如何避免GIT的短处？发挥GIT的长处？使用GIT的正确知识。

我用了TortoiseGIT两天，SourceTree一天。看GIT文档加起来快五天，我认为GIT复杂了，复杂到他爹都不认识他了。

心得总结

1. 文件file
   就是物理文件，又写作file、blob，对应版本库里的树叶，没有下级。它自身带有物理目录属性。物理目录不是文件，空目录不能提交。这一点GIT有点恶心。物理磁盘目录在版本库里面没有对应概念，物理磁盘目录是文件blob带的一种属性。
2. 提交commit
   对应版本库里的树枝，它往往指向0到多个其他commit和文件，它是版本库里面的树枝，其中最重要的是：每个子提交都有父提交，能回溯找出所有祖先提交。只有根提交没有父。commit有一个非常重要的属性，ID标识号，是根据这个commit文件内容的一个运算SHA1。例如35674ed5275c9b1aa5b47a57deb4d0000e93961d。其中sha1=0000000000000000000000000000000000000000 特指本地工作副本，还没有提交所以没有算出sha1。SourceTree软件的版本库修改日志里一般只显示sha1的前几位。
3. 分支branch
   其实就是指向两个commit的东西，首先它会记录出生地的分支祖宗commit，然后它还指向分支末世孙commit，祖宗commit永远不变，末世孙的指向随着提交的变化而不断的变化，永远是指向最后。另外末世孙能唯一回溯找到出生祖宗commit。GIT世界约定主分支、根分支命名叫做master。
   特别注意TortoiseGIT里面，克隆一个空仓库下来后，先commit到本地master，然后把本地master推送到远程仓库。否则刚开始本地仓库和远程仓库都是找不到master分支的。
4. 本地工作副本 Working Tree, Working Copy
   就是我们人类感受到的物理文件树。本地工作副本唯一对应本地仓库里某个分支的某个commit。那个指向的本地分支commit称为本地HEAD。注意不要和remote/head、orgin/head等混淆。
   远程HEAD不知有啥用，不知它是否指的是另一个机器上个工作副本对应的commit（所以是origin/head、remote/HEAD)。BARE REPO应和这个有关，我们不用过多关心。
   HEAD还有一些奇技淫巧，例如HEAD表示本地工作分支的最新commit，HEAD^和HEAD~1表示次新commit, HEAD^^和HEAD~2表示次次新commit等...
5. 暂存stash，GIT把它实现成一个本地临时分支。这个概念是垃圾，千万别用。它是给你添乱的。用一个包含所有最新修改的commit代替，写好注释就不会带来混乱。
6. BASE、LOCAL、REMOTE、MERGE
   LOCAL是本地工作副本（如果本地修改全部入了最新本地commit，那么它也是本地HEAD）
   REMOTE是远程对应分支的最新commit
   BASE是LOCAL和REMOTE的共同祖先最近祖先
   MERGE需要合并、解决冲突的最终工作副本里面的物理文件。
   
7. Origin、Remote
   就是指的远程，origin有特殊意义，GIT命令行参数里可以用，表示远程。Remote再图形GUI工具里也出现的不少。
8. 概念模型
   本地工作副本 《==》 本地库  《===》 远程库
   本地副本 WORK <==> HEAD 《====》 本地某个分支的某个commit 叫LOCAL<==> 远程同名分支REMOTE
   其中对于一个具体的本地库，WORK永远只有一份。当然你可以开多个GIT本地库对应远程的一个库，例如本机不同目录，不同机器的目录等。
   其中对于一个具体的本地库，REMOTE也只有一份，注意GIT的设计理念，这个本地LOCAL和REMOTE的功能高度雷同，地位平等。我们使用时把REMOTE人为加大它的重要性，大家都汇集到REMOTE库中交换修改。其实本机和伙伴机也能协助，TORTOISEGIT中可以把本地库设置为后台服务进程（Daemon），可用作别人库的REMOTE。
   可以没有远程库。REMOTE有时没有，例如你创建本地库，不用REMOTE库一个人也能作用的很好，就怕硬盘坏而已。一个唯一REMOTE可以对应多个计算机、同级器中的多个本地库。
9. Fetch, Pull, Push
   Fetch把REMOTE分支的最新版本拉下来和本地副本比较，没有冲突就顺利合并，有冲突必须先解决冲突才能Fetch成功
   Pull就是把REMOTE分支最新拉下来，和本地工作副本直接合并，合并不了的就在工作目录中留下三来源合并依据记录文件。在TortoiseGIT中，有中止合并功能，不要慌，能自动回到Pull之前的最新Work状态，不会丢失工作状态。
   Push，把本地库的head提交到远程库对于分支中。本地库的head就是本地工作副本的对应的那个最新提交。
   
10. 分支切换check out
    分支是GIT吹牛逼最厉害的地方，其实SVN的分支和这个没啥实质的区别，SVN和GIT的概念差异最大的地方在于GIT在Work Copy和Remote中间插了一个本地库(Local Repository），避免了过于依赖服务器和服务器的垃圾提交过多的问题。至于啥性能优劣等，那都不是事。学习曲线很陡峭倒是GIT的一个很大的短处。
    切换分支时，为了避免夜长梦多，一定要先把本地Work的全部修改提交到本地库，不要用那个垃圾暂存（Stash）功能，要使用本地提交来保住你的贞操，很宝贵的。会这一招你就能节约生命去撸管把妹探望父母朋友玩游戏。
    全部完整commit后，随便你怎么Check out都可以。注意这个Check out指的是check本地库的分支，如果需要Check 远程库，实际上GIT的实现可理解成先把远程commit、branch和本地commit、branch先汇总，Check out永远Check的是本地库的分支，本地库就是远程库的副本。
11. 分支合并merge
    所谓合并指的是任意两个commit都可以合并，也可以是修改过程中的成果和别的commit合并（特别不提倡这样搞，先完全提交后合并，就回到了两个纯commit合并）。分支合并一般指的是本地工作分支的最新commit和另外一个分支合并。
    使用情形流程：
    例如服务器和本地都已有master分支，现在需增加一个功能，可在本地添加一个分支feature1，代码工作完成后，全部完整commit到feature1中去。然后切换到本地master《切换后这时work=head=local master》，然后可以：
    1）把本地master和远程master同步《fetch获取、pull拉取》，然后合并feature1《注意本地work在合并前后都是对应master》，有冲突解决冲突，测试完全，就把本地master提交push。
    2）把本地master和feature先合并，然后把本地master和远程master同步，有冲突还需要再次提交本地work到本地分支，然后push一个本地分支的最新commit过去。
    这个分支合并，自己可以演练一下，麻烦的地方在于合并时的冲突解决，SVN也有这个问题，冲突都需要人来干预修改取舍。
12. 分支reset
    就是把当前work修改成某一个历史时刻的commit。注意本地一定要全部先commit到本地对硬分支去，然后硬reset（就是不保留本地任何修改），如果需要和稍先前的工作合并，就用分支合并（也就是用很具体的两个commit合并，历史时刻commit算一个，最近提交的算另一个）。这个流程没有中间工作成果在外面飘，怎么折腾都不出大事。
13. 分支变基rebase
    分支合并时，一般指的是那个把父分支checkout，然后mergere临时工作分支，然后提交到本地父分支，本地父分支回出现一个合并提交。变基就是消灭这个父分支的合并提交，使得最后看起来父分支是线性推进提交。这样做可以在当前work的分支合并回父分支时，父分支少一个分支环出现，比较清爽。Git - 分支的变基 https://git-scm.com/book/zh/v1/Git-分支-分支的变基。本地还没提交到远程的本地合并提交适合执行变基，已经提交到远程的不适合变基。
    
14. 务必要熟练掌握分支日志漫游，commit和工作副本的比较，commit和commit的比较等，还有三路合并，冲突解决。TortoiseGIT，你值得拥有。GitHub和SourceTree貌似不咋的。细粒度的对比控制差强人意，Win上SourceTree中文支持也不咋好。
15. 如果你用命令行+GIT，老哥，恭喜你呀，要么你正在入门，要么你有高薪稳定无可替代工作，不用在乎业绩压力。

总结一句话：不要用垃圾无比的暂存STASH功能，切换分支时一定要先全部commit所有修改到原来分支，并且提交注释写清楚一点。之后再切换、摆弄、秀逼格、滴蜡、皮鞭等等等等。不要带着修改中间过程副本去切换、合并，那样可能导致正在修改的痕迹就再也找不回来。

毕竟，解决冲突、三路合并大多数人都不能一次顺利成功的。常在河边走，哪能不湿鞋，湿一次鞋，丢了中间工作成果，后果大部分就是重新开发实现功能。

那时往往失了魂，丢了钱，头昏眼花，腰腿痛，前列腺肿大，尿道结石，恶心呕吐，心悸冷汗，腰间盘突出，颈椎病，鼻歪眼青脸肿，不举不孕，性冷淡等等。