1.创建版本库:
$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit
pwd
命令用于显示当前目录。在我的Mac上,这个仓库位于/Users/michael/learngit
。
如果你使用Windows系统,为了避免遇到各种莫名其妙的问题,请确保目录名(包括父目录)不包含中文。
第二步,通过git init
命令把这个目录变成Git可以管理的仓库:
$ git init
.git
的目录,这个目录是Git来跟踪管理版本库的,没事千万不要手动修改这个目录里面的文件,不然改乱了,就把Git仓库给破坏了。
.git
目录,那是因为这个目录默认是隐藏的,用
ls -ah
命令就可以看见。
2.把文件添加到版本库:
learngit
目录下(子目录也行),因为这是一个Git仓库,放到其他地方Git再厉害也找不到这个文件。
第一步,用命令git add
告诉Git,把文件添加到仓库:
$ git add readme.txt
第二步,用命令git commit
告诉Git,把文件提交到仓库:
$ git commit -m "wrote a readme file"
[master (root-commit) cb926e7] wrote a readme file
1 file changed, 2 insertions(+)
create mode 100644 readme.txt
-m
后面输入的是本次提交的说明,可以输入任意内容,当然最好是有意义的,这样你就能从历史记录里方便地找到改动记录。
add
,
commit
一共两步呢?因为
commit
可以一次提交很多文件,所以你可以多次
add
不同的文件,比如:
$ git add file1.txt
$ git add file2.txt file3.txt
git status
命令可以让我们时刻掌握仓库当前的状态,
git diff
:
顾名思义就是查看difference;查看修改的内容
git log
命令显示从最近到最远的提交日志,
如果嫌输出信息太多,看得眼花缭乱的,
git log --graph
--pretty=oneline --abbrev-commit
HEAD
表示当前版本,上一个版本就是
HEAD^
,上上一个版本就是
HEAD^^
,当然往上100个版本写100个
^
比较容易数不过来,所以写成
HEAD~100
。
$ git reset --hard HEAD^
HEAD is now at ea34578 add distributed
git reset
命令:
append GPL
,就必须找到
append GPL
的commit id。Git提供了一个命令
git reflog
用来记录你的每一次命令:
$ git reflog
ea34578 HEAD@{0}: reset: moving to HEAD^
3628164 HEAD@{1}: commit: append GPL
ea34578 HEAD@{2}: commit: add distributed
cb926e7 HEAD@{3}: commit (initial): wrote a readme file
$ git reset --hard 3628164
HEAD is now at 3628164 append GPL
3.管理修改:
现在,假定你已经完全掌握了暂存区的概念。下面,我们要讨论的就是,为什么Git比其他版本控制系统设计得优秀,因为Git跟踪并管理的是修改,而非文件。
你会问,什么是修改?比如你新增了一行,这就是一个修改,删除了一行,也是一个修改,更改了某些字符,也是一个修改,删了一些又加了一些,也是一个修改,甚至创建一个新文件,也算一个修改。
为什么说Git管理的是修改,而不是文件呢?我们还是做实验。第一步,对readme.txt做一个修改,比如加一行内容:
$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes.
然后,添加:
$ git add readme.txt
$ git status
# On branch master# Changes to be committed:# (use "git reset HEAD <file>..." to unstage)## modified: readme.txt#
然后,再修改readme.txt:
$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
提交:
$ git commit -m "git tracks changes"
[master d4f25b6] git tracks changes
1 file changed, 1 insertion(+)
提交后,再看看状态:
$ 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 add
-> 第二次修改 -> git commit
你看,我们前面讲了,Git管理的是修改,当你用git add
命令后,在工作区的第一次修改被放入暂存区,准备提交,但是,在工作区的第二次修改并没有放入暂存区,所以,git commit
只负责把暂存区的修改提交了,也就是第一次的修改被提交了,第二次的修改不会被提交。
提交后,用git diff HEAD -- readme.txt
命令可以查看工作区和版本库里面最新版本的区别:
$ git diff HEAD -- readme.txt
diff --git a/readme.txt b/readme.txt
index 76d770f..a9c5755 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,4 +1,4 @@
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
-Git tracks changes.
+Git tracks changes of files.
可见,第二次修改确实没有被提交。
那怎么提交第二次修改呢?你可以继续git add
再git commit
,也可以别着急提交第一次修改,先git add
第二次修改,再git commit
,就相当于把两次修改合并后一块提交了:
git add
-> 第二次修改 ->
git add
->
git commit;
4.撤销修改:
git checkout -- readme.txt
意思就是,把
readme.txt
文件在工作区的修改全部撤销,这里有两种情况:
readme.txt
自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
readme.txt
已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
git commit
或
git add
时的状态。
git checkout -- file
命令中的
--
很重要,没有
--
,就变成了“切换到另一个分支”的命令,我们在后面的分支管理中会再次遇到
git checkout
命令。
5.删除文件:
rm
命令删了:
$ git checkout -- test.txt
6.添加远程仓库:
$ git remote add origin git@github.com:michaelliao/learngit.git
michaelliao
替换成你自己的GitHub账户名
$ git push -u origin master
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (19/19), done.
Writing objects: 100% (19/19), 13.73 KiB, done.
Total 23 (delta 6), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
* [new branch] master -> master
git push
命令,实际上是把当前分支
master
推送到远程。
master
分支时,加上了
-u
参数,Git不但会把本地的
master
分支内容推送的远程新的
master
分支,还会把本地的
master
分支和远程的
master
分支关联起来,在以后的推送或者拉取时就可以简化命令。
从现在起,只要本地作了提交,就可以通过命令:
$ git push origin master
7.从远程库克隆:
gitskills
:
git clone
克隆一个本地库:
README.md
https://github.com/michaelliao/gitskills.git
这样的地址。实际上,Git支持多种协议,默认的
git://
使用ssh,但也可以使用
https
等其他协议。
8.创建与合并分支:
首先,我们创建dev
分支,然后切换到dev
分支:
$ git checkout -b dev
Switched to a new branch 'dev'
git branch
命令查看当前分支:
$ git branch
* dev
master
dev
分支上正常提交
,比如对readme.txt做个修改,加上一行:
$ git add readme.txt
$ git commit -m "branch test"
[dev fec145a] branch test
1 file changed, 1 insertion(+)
现在,dev
分支的工作完成,我们就可以切换回master
分支:
$ git checkout master
Switched to branch 'master'
master
分支后,再查看一个readme.txt文件,刚才添加的内容不见了!因为那个提交是在
dev
分支上,而
master
分支此刻的提交点并没有变:
现在,我们把dev
分支的工作成果合并到master
分支上:
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
git merge
命令用于合并指定分支到当前分支。合并后,再查看readme.txt的内容,就可以看到,和dev
分支的最新提交是完全一样的。
dev
分支了:
$ git branch -d dev
Deleted branch dev (was fec145a).
删除后,查看branch
,就只剩下master
分支了:
$ git branch
* master
10.分支管理策略:
--no-ff
参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而
fast forward
合并就看不出来曾经做过合并。
分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本;
你和你的小伙伴们每个人都在dev
分支上干活,每个人都有自己的分支,时不时地往dev
分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
11.多人协作:
master
分支和远程的
master
分支对应起来了,并且,远程仓库的默认名称是
origin
。
git remote -v
显示更详细的信息:
$ git remote -v
origin git@github.com:michaelliao/learngit.git (fetch)
origin git@github.com:michaelliao/learngit.git (push)
上面显示了可以抓取和推送的origin
的地址。如果没有推送权限,就看不到push的地址。
推送分支:
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上:
$ git push origin master
如果要推送其他分支,比如dev
,就改成:
$ git push origin dev
但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?
-
master
分支是主分支,因此要时刻与远程同步;q -
dev
分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步; -
bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
-
feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
如果标签打错了,也可以删除:
$ git tag -d v0.1Deleted tag 'v0.1' (was e078af9)
因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地安全删除。
如果要推送某个标签到远程,使用命令git push origin <tagname>
:
$ git push origin v1.0Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
* [new tag] v1.0 -> v1.0
或者,一次性推送全部尚未推送到远程的本地标签:
$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 554 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:michaelliao/learngit.git
* [new tag] v0.2 -> v0.2
* [new tag] v0.9 -> v0.9
如果标签已经推送到远程,要删除远程标签就麻烦一点,先从本地删除:
$ git tag -d v0.9Deleted tag 'v0.9' (was 6224937)
然后,从远程删除。删除命令也是push,但是格式如下:
$ git push origin :refs/tags/v0.9To git@github.com:michaelliao/learngit.git
- [deleted] v0.9
小结
初始化一个Git仓库,使用git init
命令。
添加文件到Git仓库,分两步:
-
第一步,使用命令
git add <file>
,注意,可反复多次使用,添加多个文件; -
第二步,使用命令
git commit
,完成。
-
要随时掌握工作区的状态,使用
git status
命令。 - 如果
git status
告诉你有文件被修改过,用git diff
可以查看修改内容 -
HEAD
指向的版本就是当前版本,因此,Git允许我们在版本的历史之间穿梭,使用命令git reset --hard commit_id
。 -
穿梭前,用
git log
可以查看提交历史,以便确定要回退到哪个版本。 - 要重返未来,用
git reflog
查看命令历史,以便确定要回到未来的哪个版本。
又到了小结时间。
场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令
场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git checkout -- file
。(注意空格)git reset HEAD file
,就回到了场景1,第二步按场景1操作。
场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考 版本回退 一节,不过前提是没有推送到远程库。$ git reset HEAD readme.txt Unstaged changes after reset: M readme.txt
要关联一个远程库,使用命令git remote add origin git@server-name:path/repo-name.git
;
关联后,使用命令git push -u origin master
第一次推送master分支的所有内容;
git push origin master
推送最新修改;
拉: git puLL origin master
git branch
git branch <name>
git checkout <name>
git checkout -b <name>
git merge <name>
git branch -d <name>
-
命令
git tag <name>
用于新建一个标签,默认为HEAD
,也可以指定一个commit id; -
git tag -a <tagname> -m "blablabla..."
可以指定标签信息; -
git tag -s <tagname> -m "blablabla..."
可以用PGP签名标签; - 命令
git tag
可以查看所有标签。