learning_git_from_Liao
安装
windows git 直接去官网就行,地址如下: https://git-scm.com
安装完成后,在开始菜单里找到“Git”->“Git Bash”,蹦出一个类似命令行窗口的东西,就说明Git安装成功!
安装后,要进行配置:
git config --global user.name "Your Name"
git config --global user.email "email@example.com"
注意 git config 命令的 --global 参数,用了这个参数,表示你这台机器上所有的 Git 仓库都会使用这个配置,当然也可以对某个仓库指定不同的用户名和 Email 地址。
在项目根目录下进行单独配置
git config user.name "Your Name"
git config user.email "email@xx.com"
git config --list 查看当前配置, 在当前项目下面查看的配置是全局配置+当前项目的配置, 使用的时候会优先使用当前项目的配置
创建版本库
什么是版本库呢?版本库又名仓库,英文名repository,你可以简单理解成一个目录,这个目录里面的所有文件都可以被Git管理起来,每个文件的修改、删除,Git都能跟踪,以便任何时刻都可以追踪历史,或者在将来某个时刻可以“还原”。
第一步,选择一个合适的地方,创建一个空目录:
$ mkdir learngit
$ cd learngit
第二步,通过git init
命令把这个目录变成Git可以管理的仓库:
$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/
如果你没有看到.git
目录,那是因为这个目录默认是隐藏的,用ls -ah
命令就可以看见。
把文件添加到版本库
首先这里再明确一下,所有的版本控制系统,其实只能跟踪文本文件的改动,比如TXT文件,网页,所有的程序代码等等,Git也不例外。版本控制系统可以告诉你每次的改动,比如在第5行加了一个单词“Linux”,在第8行删了一个单词“Windows”。而图片、视频这些二进制文件,虽然也能由版本控制系统管理,但没法跟踪文件的变化,只能把二进制文件每次改动串起来,也就是只知道图片从100KB改成了120KB,但到底改了啥,版本控制系统不知道,也没法知道。
不幸的是,Microsoft的Word格式是二进制格式,因此,版本控制系统是没法跟踪Word文件的改动的。
言归正传,现在我们编写一个readme.txt
文件,内容如下:
Git is a version control system.
Git is free software.
一定要放到learngit
目录下(子目录也行),因为这是一个Git仓库,放到其他地方Git再厉害也找不到这个文件。
和把大象放到冰箱需要3步相比,把一个文件放到Git仓库只需要两步。
- 第一步,用命令
git add
告诉Git,把文件添加到仓库:
#可用命令行,也可右键 Git Bash Here
#在git目录下运行
$ git add readme.txt
#git add . 添加所有改动
- 第二步,用命令
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
简单解释一下git commit
命令,-m
后面输入的是本次提交的说明,可以输入任意内容,当然最好是有意义的,这样你就能从历史记录里方便地找到改动记录。嫌麻烦不想输入-m "xxx"
行不行?确实有办法可以这么干,但是强烈不建议你这么干,因为输入说明对自己对别人阅读都很重要。
git commit
命令执行成功后会告诉你,1个文件被改动(我们新添加的readme.txt文件),插入了两行内容(readme.txt有两行内容)。
时光机穿梭
我们已经成功地添加并提交了一个readme.txt文件,现在,是时候继续工作了,于是,我们继续修改readme.txt文件,改成如下内容:
Git is a distributed version control system.
Git is free software.
现在,运行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 status
命令可以让我们时刻掌握仓库当前的状态,上面的命令告诉我们,readme.txt被修改过了,但还没有准备提交的修改。
虽然Git告诉我们readme.txt被修改了,但如果能看看具体修改了什么内容,自然是很好的。比如你休假两周从国外回来,第一天上班时,已经记不清上次怎么修改的readme.txt,所以,需要用git diff
这个命令看看:
$ git diff readme.txt
diff --git a/readme.txt b/readme.txt
index 46d49bf..9247db6 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@
-Git is a version control system.
+Git is a distributed version control system.
Git is free software.
git diff
顾名思义就是查看difference,显示的格式正是Unix通用的diff格式,可以从上面的命令输出看到,我们在第一行添加了一个“distributed”单词。
知道了对readme.txt作了什么修改后,再把它提交到仓库就放心多了,提交修改和提交新文件是一样的两步,第一步是git add
:
$ git add readme.txt
同样没有任何输出。在执行第二步git commit
之前,我们再运行git status
看看当前仓库的状态:
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: readme.txt
#
git status
告诉我们,将要被提交的修改包括readme.txt,下一步,就可以放心地提交了:
$ git commit -m "add distributed"
[master ea34578] add distributed
1 file changed, 1 insertion(+), 1 deletion(-)
提交后,我们再用git status
命令看看仓库的当前状态:
$ git status
# On branch master
nothing to commit (working directory clean)
Git告诉我们当前没有需要提交的修改,而且,工作目录是干净(working directory clean)的。
版本回退
现在,你已经学会了修改文件,然后把修改提交到Git版本库,现在,再练习一次,修改readme.txt文件如下:
Git is a distributed version control system.
Git is free software distributed under the GPL.
然后尝试提交:
$ git add readme.txt
$ git commit -m "append GPL"
[master 3628164] append GPL
1 file changed, 1 insertion(+), 1 deletion(-)
现在,我们回顾一下readme.txt文件一共有几个版本被提交到Git仓库里了:
版本1:wrote a readme file
Git is a version control system.
Git is free software.
版本2:add distributed
Git is a distributed version control system.
Git is free software.
版本3:append GPL
Git is a distributed version control system.
Git is free software distributed under the GPL.
当然了,在实际工作中,我们脑子里怎么可能记得一个几千行的文件每次都改了什么内容,不然要版本控制系统干什么。版本控制系统肯定有某个命令可以告诉我们历史记录,在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
git log
命令显示从最近到最远的提交日志,我们可以看到3次提交,最近的一次是append GPL
,上一次是add distributed
,最早的一次是wrote a readme file
。如果嫌输出信息太多,看得眼花缭乱的,可以试试加上--pretty=oneline
参数:
$ git log --pretty=oneline
3628164fb26d48395383f8f31179f24e0882e1e0 append GPL
ea34578d5496d7dd233c827ed32a8cd576c5ee85 add distributed
cb926e7ea50ad11b8f9e909c05226233bf755030 wrote a readme file
需要友情提示的是,你看到的一大串类似3628164...882e1e0
的是commit id
(版本号)。为什么commit id
需要用这么一大串数字表示呢?因为Git是分布式的版本控制系统,后面我们还要研究多人在同一个版本库里工作,如果大家都用1,2,3……作为版本号,那肯定就冲突了。
每提交一个新版本,实际上Git就会把它们自动串成一条时间线。如果使用可视化工具查看Git历史,就可以更清楚地看到提交历史的时间线:
好了,现在我们启动时光穿梭机,准备把readme.txt回退到上一个版本,也就是“add distributed”的那个版本,怎么做呢?
首先,Git必须知道当前版本是哪个版本,在Git中,用HEAD
表示当前版本,也就是最新的提交3628164...882e1e0
(注意我的提交ID和你的肯定不一样),上一个版本就是HEAD^
,上上一个版本就是HEAD^^
,当然往上100个版本写100个^
比较容易数不过来,所以写成HEAD~100
(建议用第二种方法)。
现在,我们要把当前版本“append GPL”回退到上一个版本“add distributed”,就可以使用git reset
命令:
$ git reset --hard HEAD^
HEAD is now at ea34578 add distributed
--hard
参数有啥意义?这个后面再讲,现在你先放心使用。
看看readme.txt的内容是不是版本add distributed
:
$ cat readme.txt #window: type readme.txt
Git is a distributed version control system.
Git is free software.
果然。
还可以继续回退到上一个版本wrote a readme file
,不过且慢,然我们用git log
再看看现在版本库的状态:
$ git log
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
最新的那个版本append GPL
已经看不到了!好比你从21世纪坐时光穿梭机来到了19世纪,想再回去已经回不去了,肿么办?
办法其实还是有的,只要上面的命令行窗口还没有被关掉,你就可以顺着往上找啊找啊,找到那个append GPL
的commit id
是3628164...
,于是就可以指定回到未来的某个版本:
$ git reset --hard 3628164
HEAD is now at 3628164 append GPL
版本号没必要写全,前几位就可以了,Git会自动去找。当然也不能只写前一两位,因为Git可能会找到多个版本号,就无法确定是哪一个了。
再小心翼翼地看看readme.txt的内容:
$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
果然,我胡汉三又回来了。
现在,你回退到了某个版本,关掉了电脑,第二天早上就后悔了,想恢复到新版本怎么办?找不到新版本的commit id
怎么办?
在Git中,总是有后悔药可以吃的。当你用$ git reset --hard HEAD^
回退到add distributed
版本时,再想恢复到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
终于舒了口气,第二行显示append GPL
的commit id是3628164
,现在,你又可以乘坐时光机回到未来了。
现在总结一下:
HEAD
指向的版本就是当前版本,因此,Git允许我们在版本的历史之间穿梭,使用命令git reset --hard commit_id
。- 穿梭前,用
git log
可以查看提交历史,以便确定要回退到哪个版本。 - 要重返未来,用
git reflog
查看命令历史,以便确定要回到未来的哪个版本。
工作区和暂存区
我们把文件往Git版本库里添加的时候,是分两步执行的:
第一步是用git add
把文件添加进去,实际上就是把文件修改添加到暂存区;
第二步是用git commit
提交更改,实际上就是把暂存区的所有内容提交到当前分支
git diff <file> #是工作区(work dict)和暂存区(stage)的比较
#当暂存区是空时,返回工作区和分支的比较?
git diff --cached #是暂存区(stage)和分支(master)的比较
git diff HEAD -- <file> #查看工作区和版本库里面最新版本的区别
撤销修改
git checkout -- <file> #把文件在工作区的修改全部撤销,这里有两种情况:
#一种是readme.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
#一种是readme.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
git checkout -- file
命令中的--
很重要,没有--
,就变成了“切换到另一个分支”的命令
--
的名称叫做double dash,是bash的内置命令,用来标记可选命令选项的结束。即在它后面的带--
的字符串,不被当做是一个命令选项。举例:在 grep 命令中
-V
原本是一个可选的命令参数(options),打印出 grep 命令的版本。但结合
--
后,以下命令表示在 d1.txt 文件中查找 "-V" 字符串grep -- -V d1.txt
Git 的一些命令中,借鉴了这种用法。使用
--
去隔离开“树”与“路径”。例如,你想还原 一个文件
path/to/file.txt
,在Git中使用如下命令
git checkout path/to/file.txt
但是天杀的居然有一个文件名字就叫做 "master"如果你套用上面的命令,想还原“master”文件
git checkout master
最终起的效果是变成切换到了master分支上。
正确的做法是使用
--
,这样它后面的字符串不会当做“树”,而认为是文件路径。
git checkout -- master
git reset HEAD file
可以把暂存区的修改撤销掉(unstage),重新放回工作区(没改变工作区内容?)。
git reset
命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD
时,表示最新的版本。
文件删除
第一种情况:的确要把文件删除
git rm <file> #相当于 rm <file> + git add <file>
#git rm <file>,是同时删除了工作区的test.txt文件,并且将删除的动作提交到了暂存区。
git commit -m "note" #版本库和工作区的内容一致,全部都删除了文件。
第二种情况:误删
这是只执行了 git rm <file>
还没有提交,可以执行git checkout <file>
将文件恢复。
添加远程库
要关联一个远程库,使用命令git remote add origin git@github.com:someone/repo-name.git
;
关联后,使用命令git push -u origin master
第一次推送master分支的所有内容;
此后,每次本地提交后,只要有必要,就可以使用命令git push origin master
推送最新修改。
从远程库克隆
要克隆一个仓库,首先必须知道仓库的地址,然后使用git clone
命令克隆。
Git支持多种协议,包括https
,但通过ssh
支持的原生git
协议速度最快。
本地clone的仓库在哪里取决于你运行
$ git clone git@github.com:someone/repo-name.git
的时候所在的目录。
创建于合并分支
查看分支:git branch
,列出所有分支,当前分支前面会标一个*
号。
创建分支:git branch <name>
切换分支:git checkout <name>
创建+切换分支:git checkout -b <name>
合并某分支__到当前分支__:git merge <name>
删除分支:git branch -d <name>
解决冲突
当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。
用git log --graph
命令可以看到分支合并图。
分支管理策略
合并分支时,加上--no-ff
参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward
合并就看不出来曾经做过合并。
git merge --no-ff -m "merge with no-ff" dev
因为本次合并要创建一个新的commit,所以加上-m
参数,把commit描述写进去。
Bug分支
修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;
当手头工作没有完成时,先把工作现场git stash
一下,然后去修复bug,修复后,再git stash pop
,回到工作现场。
Feature分支
开发一个新的Feature,最好新建一个分支;
如果要丢弃一个没有被合并过的分支,可以通过git branch -D <name>
强行删除。
多人协作
当你从远程仓库克隆时,实际上Git自动把本地的master
分支和远程的master
分支对应起来了
- 查看远程库信息,使用
git remote -v
; - 本地新建的分支如果不推送到远程,对其他人就是不可见的;
- 从本地推送分支,使用
git push origin branch-name
,如果推送失败,先用git pull
抓取远程的新提交; - 在本地创建和远程分支对应的分支,使用
git checkout -b branch-name origin/branch-name
,本地和远程分支的名称最好一致; - 建立本地分支和远程分支的关联,使用
git branch --set-upstream branch-name origin/branch-name
; - 从远程抓取分支,使用
git pull
,如果有冲突,要先处理冲突,并在本地提交。
创建标签
- 命令
git tag <name>
用于新建一个标签,默认为HEAD
,也可以指定一个commit id; git tag -a <tagname> -m "blablabla..."
可以指定标签信息;git tag -s <tagname> -m "blablabla..."
可以用PGP签名标签;- 命令
git tag
可以查看所有标签; git show <tagname>
查看标签信息。
操作标签
- 命令
git push origin <tagname>
可以推送一个本地标签; - 命令
git push origin --tags
可以推送全部未推送过的本地标签; - 命令
git tag -d <tagname>
可以删除一个本地标签; - 命令
git push origin :refs/tags/<tagname>
可以删除一个远程标签(先要从本地删除)。
使用GitHub
如何进行 pull request ? 首先将你相中的项目,fork 到自己的仓库,然后运行 gitbash clone 到本地进行修改,提交并 push 到远程仓库,然后在自己的仓库发起 pull request 。OK,等待项目管理者处理。
自定义Git
git config --global color.ui true #文件名会表上颜色
忽略特殊文件
- 忽略某些文件时,需要编写
.gitignore
; .gitignore
文件本身要放到版本库里,并且可以对.gitignore
做版本管理!
配置文件使用可参考 https://github.com/github/gitignore
在git
中如果想忽略掉某个文件,不让这个文件提交到版本库中,可以使用修改根目录中.gitignore
文件的方法(如无,则需自己手工建立此文件)。这个文件每一行保存了一个匹配的规则例如:
# 此为注释 – 将被 Git 忽略
*.cs # 忽略所有 .cs 结尾的文件
!ABC.cs # 但 ABC.cs 除外
/BLL # 仅仅忽略项目根目录下的 BLL 文件,不包括 subdir/BLL
build/ # 忽略 build/ 目录下的所有文件
doc/*.txt # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
规则很简单,不做过多解释,但是有时候在项目开发过程中,突然心血来潮想把某些目录或文件加入忽略规则,按照上述方法定义后发现并未生效,原因是.gitignore
只能忽略那些原来没有被track的文件,如果某些文件已经被纳入了版本管理中,则修改.gitignore
是无效的。那么解决方法就是先把本地缓存删除(改变成未track状态),然后再提交:
git rm -r --cached .
git add .
git commit -m 'update .gitignore'