分布式版本控制系统

好处：
1，记录每次改动时间
2，多人协作同一个项目
3，可以恢复指定某一个时间点的文件
4，自己电脑永远是最新，修改时直接改，不需要从类似中央服务器先更新在改
5，强大分支管理（远远把svn抛在后面）



历史：
git是linux的创始人写的



比较：
svn和git比较
svn需要类似中央服务器，要在自己电脑修改时，先从中央服务器更新才能修改，
所以前提是需要联网后才能继续工作。


git不需要联网就能工作，不需要中央服务器，自己本机上的文件最新的，断网可以继续工作。
多个用户修改同一个文件，只需要把自己修改的部分推送给对方即可，这样每个人电脑又都是最新的了。




安全性：
git没有中央服务器就不怕黑客攻击，就算某个用户被黑了，代码可以在从其他人电脑获取最新的。 



弥补不足：
之前说了要保证大家的文件保持最新的就要大家同时在线推送自己修改的部分给其他人，在实际中不现实
为了方便大家推送自己修改的部分给其他人，还是需要一个“中央服务器”，这里的“中央服务器”
仅仅是方便大家交换自己修改的部分而已，没它我们可以照样工作。



开始教程：
(声明图片、视频、Microsoft的Word格式， git只能知道变化大小，不知道具体改变了什么)
注意：不要使用Windows自带的记事本编辑任何文本文件。



创建版本库又名仓库：
git init



增：
git add file1.txt  //提交单个
git add file2.txt file3.txt  //提交多个
git status //最后查看有什么修改又漏了add提交的
git commit -m "写点有意义的注释"  //一次性提交之前add的文件到仓库，如果修改文件后没add,就算commit也不会提交成功的

git branch xx //创建一个xx分支

git merge xx  //将xx分支和当前分支合并 （将当前分支的代码和xx分支的代码合并） 
git merge --no-ff -m "注释" xx  //合并，禁用Fast forward模式，可以看出合并历史

git stash  //存储正在工作还没完成的项目（目的是另一个bug更急着去修改）
           //如果当前工作的分支是dev
           //使用git stash把未完成的dev分支工作进度保存，去修改其他分支bug
           //如果其他分支bug修改完成，切回dev分支git checkout dev
           //使用git stash pop切回dev之前的工作进度并删除之前的git stash历史记录

git push origin master  //将本地master推送到远程master。推送其他分支git push origin xx

git push origin v1.0 //推送指定标签名到远程
git push origin --tags //推送所有已经设置标签名到远程

git add -f App.class //强制添加文件到暂存区，针对.gitignore设置



删：
git rm test.txt  //删除（其实还没有真正删除，撤回之前的删除git checkout -- test.txt）
git commit -m "remove test.txt"  //真正的从仓库中删除

git branch -d xx  //删除分支
git branch -D feature-vulcan  //强行删除没有合并的分支

git tag -d v0.1 //删除某个写错的标签名

如果上传错误的标签名删除顺序是：
git tag -d v0.9 //先删除本地标签名
git push origin :refs/tags/v0.9 //先删除远程标签名


改：
git reset --hard HEAD^   //退回一个版本
git reset --hard HEAD^^  //退回上上一个版本
git reset --hard HEAD~100  //退回到上第100个版本
git reset --hard 3628164  //切换到底指定版本


git checkout -- readme.txt //撤销，
   情况1，如果没add，就退回到最近的一次版本（最近的一次git commit）
   情况2，如果有add，就退回到最近的那次add到暂存区的版本（最近的一次git add）

   撤回遇到情况1还好，如果遇到情况2，要怎么撤回add呢？
   git reset HEAD readme.txt
   接着
   git checkout -- readme.txt
   之前提交到修改的并且提交到暂存区的全部退回到最近一次版本，退回到最近的一次git commit

git checkout master  //切换指定分支

git merge xx  //将xx分支和当前分支合并 （如果当前切换到master分支使用此命令，就是把xx分支和master分支合并） 

git stash apply stash@{0}  //我们可以多次使用git stash，要恢复指定历史记录使用git stash list

git tag v1.0 //为某commit id设置标签名，就要先切换到到某标签git checkout 

git tag v0.9 6224937  //为某具体commit id设置标签名
git tag -a v0.1 -m "注释" 3628164  //为某commit id设置标签名同时设置注释





查：
git status   //查看当前仓库的文件是否修改、或未提交的

git diff HEAD 文件名.txt  //查看当前文件具体修改了什么内容

git log  //查看每次提交所修改的什么详细内容，方便回到从前
git log --pretty=oneline  //简要的显示每次修改内容，方便回到从前

git reflog  //查看所有提交commit id，方便回到未来

git branch   //查看所有分支

git stash list  //查看stash列表

git remote -v  //查看远程仓库克隆

git log --pretty=oneline --abbrev-commit  //查看全部commit id和注释

git tag  //查看所有为commit id设置的标签名

git show v0.9 //查看具体标签信息

git check-ignore -v xx.class  //查看.gitignore文件里是否含有xx.class




Git版本库
就是仓库里面的隐藏目录.git



工作区
就是我们创建的仓库，除了隐藏目录.git



暂存区
暂存区就在仓库里面隐藏的.git目录中，还有Git为我们自动创建的第一个分支master
git add 实际上就是把文件修改添加到暂存区




分支
我们创建仓库时同时创建了Git版本库，Git在版本库里面自动为我们创建了唯一一个master分支
git commit 实际上就是把暂存区的所有内容提交到master当前分支。





添加远程库
git remote add origin git@server-name:path/repo-name.git  //要关联一个远程库，使用命令
git push -u origin master   //第一次推送master分支的所有内容到远程库
git push origin master  //此后，每次本地提交后，只要有必要，就可以使用命令
git push origin dev  //推送dev分支



下载远程库
git clone git@github.com:michaelliao/gitskills.git
多人合作只需要下载本地库




分支管理
它的存在是什么？
当你完成一个50%的项目上传远程库后，别人在下载基于你的50%项目不能正常运行给别人造成麻烦，
但又怕不上传万一丢失数据。
可以创建一个分支保存工作的个个进度状况，别人看不到你的分支，最后再一次性合并分支。



快捷键设置
git config --global alias.st status

git status
等同
git st





多人合作：
首先，可以试图用git push origin branch-name推送自己的修改；

如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

如果合并有冲突，则解决冲突，并在本地提交；

没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功！

如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。





建议：
1，主分支master一般都是稳定项目，即能正常工作的。所以一般我们开发在develop开发
2，每次为项目添加一个新功能，就创建一个新分支，完成后合并，最后，删除该分支。
3，master分支是主分支，因此要时刻与远程同步；
   dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
   bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
   feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
   （总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！）