在Windows上安装Git
安装完成后，在开始菜单里找到“Git”->“Git Bash”，蹦出一个类似命令行窗口的东西，就说明Git安装成功！
安装完成后，还需要最后一步设置，在命令行输入：
$ git config --global user.name "Your Name"
$ git config --global user.email "[email protected]"创建版本库
（a）初始化一个Git仓库，使用 git init 命令。
（b）添加文件到Git仓库，分两步：
1、使用命令 git add ，注意，可反复多次使用，添加多个文件；
2、使用命令git commit -m ，完成。
查看版本状态及不同
工作区的状态，使用 git status 命令。
如果git status告诉你有文件被修改过，用 git diff 可以查看修改内容。(git diff用在为刚编辑过，未add的时候)
版本回退
HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令 git reset –hard commit_id。
回退前，用 git log 可以查看提交历史，以便确定要回退到哪个版本。
要重返未来，用 git reflog查看命令历史，以便确定要回到未来的哪个版本。
工作区和暂存区
版本库（Repository）
１、工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
2、Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
Git版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。（你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。）
撤销修改
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout – file。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD ，就回到了场景1，第二步按场景1操作。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。
删除文件
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
添加远程库
１、要关联一个远程库，使用命令
git remote add origin git@server-name:path/repo-name.git
2、关联后，使用命令
git push -u origin master第一次推送master分支的所有内容；
此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；
分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步，真是太方便了！
从远程库克隆
要克隆一个仓库，首先必须知道仓库的地址，然后使用
git clone 仓库地址命令克隆。
Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。
创建与合并分支
Git鼓励大量使用分支：
查看分支：git branch
创建分支：git branch
切换分支：git checkout
创建+切换分支：git checkout -b
合并某分支到当前分支：git merge
删除分支：git branch -d
解决冲突
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
用git log --graph命令可以看到分支合并图。
分支管理策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来
小结
Git分支十分强大，在团队开发中应该充分应用。
合并分支时，加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并．
Bug分支
在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
Git提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。
Feature分支
添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。
开发一个新feature，最好新建一个分支；如果要丢弃一个没有被合并过的分支，可以通过 git branch -D 强行删除。
多人协作
当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
1、要查看远程库的信息：git remote
2、显示更详细的信息：git remote -v
推送分支
推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
git push origin master如果要推送到其他分支，比如dev，就改成
git push origin dev哪些分支需要推送：
1、master分支是主分支，因此要时刻与远程同步；
2、dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
3、bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
4、feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。
抓取分支
从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。
因此，多人协作的工作模式通常是这样：
１、可以试图用git push origin 推送自己的修改；
2、如果推送失败，则因为远程分支比你的本地更新，需要先用 git pull 试图合并；
3、如果合并有冲突，则解决冲突，并在本地提交；
4、没有冲突或者解决掉冲突后，再用 git push origin 推送就能成功！
5、如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令 git branch –set-upstream-to origin/
rebase
rebase操作可以把本地push的分叉提交历史整理成直线。
rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方比对。
其实原理非常简单。我们注意观察，发现Git把我们本地的提交“挪动”了位置
git rebase
创建标签
命令git tag 用于新建一个标签，默认为HEAD，也可以指定一个commit id；
命令git tag -a -m “blablabla…”可以指定标签信息；
命令git tag可以查看所有标签