01 . Git常用命令及方法和分支管理 (3)

创建一个修补bug的分支

git checkout -b fixbug-0.1 master

修补结束后,合并到master分支

git checkout master git merge --no-ff fixbug-0.1 git tag -a 0.1.1

再合并到develop分支

git checkout develop git merge --no-ff fixbug-0.1

删除'修改bug'分支

git branch -d fixbug-0.1 版本回退-撤销文件修改 工作区修改一个文件,又想回到修改前(git add前)

1.当然可以直接手动在工作区中将文件修改回去

2.修改后,通过git status查看

git status # On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a") # 此时Git会告诉你, git checkout -- file可以丢弃工作区的修改 git checkout -- readme.txt

Note

1 . git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。

2 . 命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。总之，就是让这个文件回到最近一次git commit或git add时的状态。

工作区修改文件还git add到暂存区(但是在commit之前)

用git status查看一下,修改只是添加到了暂存区,还没有提交

git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # modified: readme.txt

Git同样告诉我们，用命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区：

git reset HEAD readme.txt Unstaged changes after reset: M readme.txt

git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。再用git status查看一下，现在暂存区是干净的，工作区有修改。

然后丢弃工作区的修改

git checkout -- readme.txt git status # On branch master nothing to commit (working directory clean) 修改了文件还从暂存区提交commit到版本库-版本回退

版本回退可以回退到上一个版本。不过，这是有条件的，就是你还没有把自己的本地版本库推送到远程。Git是分布式版本控制系统。

在工作中对某个文件（如readme.txt）进行多次修改交commit。

可以通过版本控制系统命令告诉我们提交的历史记录，在Git中，我们用git log命令查看：

git log commit 3628164fb26d48395383f8f31179f24e0882e1e0 Author: Michael Liao <askxuefeng@gmail.com> Date: Tue Aug 20 15:11:49 2013 +0800 append GPL commit ea34578d5496d7dd233c827ed32a8cd576c5ee85 Author: Michael Liao <askxuefeng@gmail.com> Date: Tue Aug 20 14:53:12 2013 +0800 add distributed commit cb926e7ea50ad11b8f9e909c05226233bf755030 Author: Michael Liao <askxuefeng@gmail.com> Date: Mon Aug 19 17:51:55 2013 +0800 wrote a readme file

Note

1 . git log命令显示从最近到最远的提交日志，我们可以看到3次提交，最近的一次是append GPL，上一次是add distributed，最早的一次是wrote a readme file。

2 . 如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数：

$ git log --pretty=oneline

3628164fb26d48395383f8f31179f24e0882e1e0 append GPL

ea34578d5496d7dd233c827ed32a8cd576c5ee85 add distributed

cb926e7ea50ad11b8f9e909c05226233bf755030 wrote a readme file

3 . 你看到的一大串类似3628164...882e1e0的是commit id（版本号），和SVN不一样，Git的commit id不是1，2，3……递增的数字，而是一个SHA1计算出来的一个非常大的数字，用十六进制表示，而且你看到的commit id和我的肯定不一样，以你自己的为准。为什么commit id需要用这么一大串数字表示呢？因为Git是分布式的版本控制系统，后面我们还要研究多人在同一个版本库里工作，如果大家都用1，2，3……作为版本号，那肯定就冲突了。