1. 集中式VS分布式集中式CVS、SVN速度慢必须联网版本库在中央服务器中使用简单分布式Git速度快无需联网安全性高每个人的电脑都有完整的版本库中央服务器用来交换大家的改动分支管理强大使用较复杂注 GitHub免费提供Git存储。提供Git仓库托管服务充当用于交换的免费中央服务器。远程仓库实际上和本地仓库没啥不同纯粹为了7x24小时开机并交换大家的修改2. 版本回退和前进版本回退/前进重置HEAD指针git reset --hard HEAD~回退到上一个版本git reset --hard 91588fb回退到指定版本Git的版本回退速度非常快因为Git在内部有个指向当前版本的HEAD指针当你回退版本的时候Git仅仅是把HEAD从指向某个版本即可。git reset命令既可以回退版本也可以把暂存区的修改回退到工作区。当我们用HEAD时表示最新的版本.查看历史操作记录git reflog用git reflog查看命令历史以便确定要回到未来的哪个版本git log -n 3查看最新三条提交日志3.工作区和暂存区工作区有一个隐藏目录.git这个不算工作区而是Git的版本库。Git的版本库里存了很多东西其中最重要的就是称为stage或者叫index的暂存区还有Git为我们自动创建的第一个分支master以及指向master的一个指针叫HEAD前面讲了我们把文件往Git版本库里添加的时候是分两步执行的第一步是用git add把文件添加进去实际上就是把文件修改添加到暂存区第二步是用git commit提交更改实际上就是把暂存区的所有内容提交到当前分支。因为我们创建Git版本库时Git自动为我们创建了唯一一个master分支所以现在git commit就是往master分支上提交更改。你可以简单理解为需要提交的文件修改通通放到暂存区然后一次性提交暂存区的所有修改。4. 管理修改Git跟踪并管理的是修改而非文件。你会问什么是修改比如你新增了一行这就是一个修改删除了一行也是一个修改更改了某些字符也是一个修改删了一些又加了一些也是一个修改甚至创建一个新文件也算一个修改。Git管理的是修改当你用git add命令后在工作区的第一次修改被放入暂存区准备提交但是在工作区的第二次修改并没有放入暂存区所以git commit只负责把暂存区的修改提交了也就是第一次的修改被提交了第二次的修改不会被提交。git diff HEAD -- xx.txt比较xx.txt文件本地和仓库最新的区别。Git是跟踪修改的每次修改如果不用git add到暂存区那就不会加入到commit中所以提交的过程是本地工作区-暂存区stage-版本库4.撤销修改git checkout -- readme.txt让这个文件回到最近一次git commit或git add时的状态git checkout其实是用版本库里的版本替换工作区的版本无论工作区是修改还是删除都可以“一键还原”。--很重要没有--就变成了“切换到另一个分支”的命令git reset HEAD xx.txt取消暂存区的修改到工作区。git reset命令既可以回退版本也可以把暂存区的修改回退到工作区。当我们用HEAD时表示最新的版5.分支管理git checkout -b dev我们创建dev分支然后切换到dev分支,等价于git branch dev和git checkout dev两条命令git branch命令查看当前分支git checkout master切换到master分支git merge dev命令用于合并指定分支到当前分支dev分支的最新提交是完全一样的。注意到上面的Fast-forward信息Git告诉我们这次合并是“快进模式”也就是直接把master指向dev的当前提交所以合并速度非常快git merge --no-ff -m merged bug fix 101 issue-101通常合并分支时如果可能Git会用Fast forward模式但这种模式下删除分支后会丢掉分支信息。如果要强制禁用Fast forward模式--no-ffGit就会在merge时生成一个新的commit这样从分支历史上就可以看出分支信息git branch -d dev就可以放心地删除dev分支了我们注意到切换分支使用git checkout 而前面讲过的撤销修改则是git checkout – filename同一个命令有两种作用确实有点令人迷惑git log --graph --prettyoneline -abbrev-commit看到分支的合并情况,可以看到分支树结构。当Git无法自动合并分支时就必须首先解决冲突。解决冲突后再提交合并完成。解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容再提交。git log --graph命令可以看到分支合并图如下图内容比较丰富。分支策略在实际开发中我们应该按照几个基本原则进行分支管理首先master分支应该是非常稳定的也就是仅用来发布新版本平时不能在上面干活那在哪干活呢干活都在dev分支上也就是说dev分支是不稳定的到某个时候比如1.0版本发布时再把dev分支合并到master上在master分支发布1.0版本你和你的小伙伴们每个人都在dev分支上干活每个人都有自己的分支时不时地往dev分支上合并就可以了。所以团队合作的分支看起来就像这样git stash当前工作现场“储藏”起来等以后恢复现场后继续工作之后用git status查看工作区就是干净的除非有没有被Git管理的文件因此可以放心地创建分支来修复bug。git stash list查看保存起来的工作现场恢复工作现场用git stash apply恢复但是恢复后stash内容并不删除你需要用git stash drop来删除用git stash pop恢复的同时把stash内容也删了git stash apply stash{0}有多次stash选择性恢复git cherry-pick 4c805e2复制合并一个特定的提交内容到当前分支一般用于bug修复完成后需要把这个改动合并到其他分支。git remoteorgit remote -v查看远程库的信息。你从远程仓库克隆时实际上Git自动把本地的master分支和远程的master分支对应起来了并且远程仓库的默认名称是origingit push origin master把该分支上的所有本地提交推送到远程库git pull获取最新提交6.标签发布一个版本时我们通常先在版本库中打一个标签tag这样就唯一确定了打标签时刻的版本。将来无论什么时候取某个标签的版本就是把那个打标签的时刻的历史版本取出来。所以标签也是版本库的一个快照。Git的标签虽然是版本库的快照但其实它就是指向某个commit的指针跟分支很像对不对但是分支可以移动标签不能移动所以创建和删除标签都是瞬间完成的.tag就是一个让人容易记住的有意义的名字它跟某个commit绑在一起git tag v1.0默认标签是打在最新提交的commit上的默认为HEADgit tag v0.9 f52c633对某次提交打标签git tag查看标签git show tagName查看某个标签的信息git tag -a v0.1 -m version 0.1 released 1094adb还可以创建带有说明的标签用-a指定标签名-m指定说明文字git tag -d v0.1删除标签git push origin tagname推送某个标签到远程git push origin --tags一次性推送全部尚未推送到远程的本地标签如果标签已经推送到远程要删除远程标签就麻烦一点先从本地删除git tag -d v0.9然后从远程删除。删除命令也是push但是格式如下git push origin :refs/tags/v0.97.忽略特殊文件有些时候你必须把某些文件放到Git工作目录中但又不能提交它们比如保存了数据库密码的配置文件啦等等每次git status都会显示Untracked files ...有强迫症的童鞋心里肯定不爽。好在Git考虑到了大家的感受这个问题解决起来也很简单在Git工作区的根目录下创建一个特殊的.gitignore文件然后把要忽略的文件名填进去Git就会自动忽略这些文件。不需要从头写.gitignore文件GitHub已经为我们准备了各种配置文件只需要组合一下就可以使用了。所有配置文件可以直接在线浏览https://github.com/github/gitignore略文件的原则是忽略操作系统自动生成的文件比如缩略图等忽略编译生成的中间文件、可执行文件等也就是如果一个文件是通过另一个文件自动生成的那自动生成的文件就没必要放进版本库比如Java编译产生的.class文件忽略你自己的带有敏感信息的配置文件比如存放口令的配置文件。8.参考文献官方文档常用命令Git教程