git的使用

 

提交与查看状态

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>可以删除一个远程标签。