提交与查看状态
git init
//当前目录下生成.git仓库
git add . /git add xxx.txt ..... 将文件添加到暂存区
git commit -m "modified" 把暂存区的内容提交到当前分支
git status 查看工作区（working tree）的状态
git diff （如果git status告诉你有文件被修改过，用git diff可以查看修改内容）
版本回退
git log 命令显示从最近到最远的提交(commit)日志，可以加--pretty=oneline更漂亮的显示。
git reset --hard HEAD^ 回退到上一个版本
git reset --hard HEAD^^回退到上两个....
git reset --hard HEAD~100回退到上100个。
git reset --hard 935ff....回退到这个commit id的版本。
用git reflog来查看自己的命令记录，以便控制恢复到最新版本。
工作区与暂存区
撤销修改
git checkout -- filename
(实际操作时先使用git status这时git会有提示说明，按操作做就可以了。主要分为下面三种情况)
当你改乱了工作区某个文件的内容，用命令git checkout -- file。
当你改乱了工作区某个文件的内容，还添加到了暂存区时，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。
已经提交了不合适的修改到版本库时，想要撤销本次提交，使用版本回退。（前提是没有推送到远程库）
在工作区新建一个文件然后右键删除它，接下来使用git status查看，git rm用于删除一个文件。
如果一个文件已经被提交到版本库，那么不用担心误删，但是要注意只能恢复文件到最新版本，会丢失最近一次提交之后修改的内容。
连接远程仓库
git remote add origin git@github.com:eret9616/.....
git remote -v 查看远程仓库
git push -u origin master (-u参数将本地master分支与远程master分支关联了起来，在以后推送或拉取时可以简化命令直接用git push origin master)
git clone git@github.com:eret9616/...
分支管理
每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点，每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长：
当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：
Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化，
不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：
所以Git合并分支也很快！就改改指针，工作区内容也不变！
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
git branch dev 创建dev分支
git checkout dev 切换到dev分支
（这两句等同于 git checkout -b dev）
git branch -d dev 删除dev分支
git branch 查看所有分支
git merge dev 将dev分支合并到当前分支
推荐一个查看图形化分支的带参数的命令： git log --graph --pretty=oneline --abbrev-commit
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
例如：git merge --no-ff -m "merge with no-ff" dev
分支策略
在实际开发中，应该按照几个基本原则进行分支管理：
master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
干活应该在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。所以，团队合作的分支看起来就像这样：
Bug分支
当你想修复某个bug时，当前在dev分支上的工作还没有提交。
输入git status发现还有待commit或者已修改待add的文件内容。
git提供了一个stash（贮藏）的功能
git stash Saved working directory and index state WIP on dev: 6224937 add merge HEAD is now at 6224937 add merge
（git satsh list 查看被stash的详细信息）
首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：
$ git checkout master
$ git checkout -b issue-101
现在修复bug，需要把“Git is free software ...”改为“Git is a free software ...”，然后提交：
$ git add readme.txt
$ git commit -m "fix bug 101"修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：
$ git checkout master
$ git merge --no-ff -m "merged bug fix 101" issue-101
$ git branch -d issue-101修复完成，现在是时候接着回到dev分支干活了
$ git checkout dev
$ git status
# On branch dev
nothing to commit (working directory clean)
用git stash list命令看看：
$ git stash list
stash@{0}: WIP on dev: 6224937 add merge需要恢复一下，有两个办法：
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash的内容也删了。
标签管理
-
命令
git tag <name>用于新建一个标签，默认为HEAD，也可以指定一个commit id； -
git tag -a <tagname> -m "blablabla..."可以指定标签信息； -
命令
git tag可以查看所有标签。 -
$ git log --pretty=oneline --abbrev-commit ..$ git tag v0.9 6224937 ...
-
命令
git push origin <tagname>可以推送一个本地标签； -
命令
git push origin --tags可以推送全部未推送过的本地标签； -
命令
git tag -d <tagname>可以删除一个本地标签； -
命令
git push origin :refs/tags/<tagname>可以删除一个远程标签。