Git系列二之数据管理
1.Git基本管理
git常用的基本操作
1.1提交数据
我们可以简单的把工作目录理解成是一个被Git服务程序管理的目录,Git会时刻的追踪目录内文件的改动,另外在安装好了Git服务程序后,默认就会创建好了一个叫做master的分支,我们直接可以提交数据到了
1.创建本地工作目录demo,并初始化为git工作目录
[root@git-node1 ~]# mkdir demo [root@git-node1 ~]# cd demo/ [root@git-node1 git-demo]# git init Initialized empty Git repository in /root/demo/.git/
2.创建readme.txt文件
[root@rabbitmq demo]# vi index.html welcome nulige
3.查看git状态
1
2
3
4
5
6
7
8
9
|
[root@rabbitmq demo]# git status # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: index.html # no changes added to commit (use "git add" and/or "git commit -a" ) |
4.提示使用git add添加文件至暂存区
1
2
3
4
5
6
7
8
9
|
[root@rabbitmq demo]# git add index.html #添加到暂存区 [root@rabbitmq demo]# git status #查看变更状态 # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: index.html # |
5.使用git cmmit提交暂存区文件至git版本仓库 -m:提交描述信息(提交至远程需添加远程仓库)
[root@git-node1 demo]# git commit -m "the first commit index.html" [master(根提交) 85bd268] the first commit index.html 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 index.html
1.2移除数据
有些时候会将已经添加到暂存区的文件移除,但仍然希望文件在工作目录中不丢失,换句话说,就是把文件从追踪清单中删除。
1.建立新文件
[root@git-node1 demo]# vi index.php
Hello nuloge
2.添加新文件至暂存区
[root@git-node1 demo]# git add index.php #添加到暂存区 [root@git-node1 demo]# git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: index.php #
3.将新文件从暂存区撤出(并不会删除工作目录内的数据)
[root@git-node1 demo]# git add index.php #文件添加到暂存区 [root@git-node1 demo]# git status #查看文件状态 # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: index.php [root@git-node1 demo]# git reset HEAD index.php #从暂存区撤消文件 [root@git-node1 demo]# git status //index.php #文件状态为未跟踪 fatal: '//index.php' is outside repository [root@git-node1 demo]# git status #查看文件状态 # On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) # # index.php nothing added to commit but untracked files present (use "git add" to track) #提交为空,但是存在尚未跟踪的文件(使用 "git add" 建立跟踪) #如果想将文件数据从git暂存区和工作目录一起删除,可以做如下操作。
[root@git-node1 demo]# git add index.php #添加文件到暂存区 [root@git-node1 demo]# git rm index.php #文件已经放入暂存区域,防止误删 error: 'index.php' has changes staged in the index #有变更已暂存至索引中 (use --cached to keep the file, or -f to force removal) #(使用 --cached 保存文件,或用 -f 强制删除) [root@git-node1 demo]# git rm -f index.php #使用追加强制删除-f参数或者-cache保存 rm 'index.php' [root@git-node1 demo]# git status #查看当前状态 # On branch master #位于分支 master nothing to commit (working directory clean) #无文件要提交,干净的工作区 [root@git-node1 demo]# ls #文件已经不存在 index.html
1.3移动数据
有些时候会将已经添加到暂存区的文件重新修改名称,可使用如下操作完成。
1.git重新命名文件名称,使用git mv操作。
[root@git-node1 demo]# ls index.html [root@git-node1 demo]# git mv index.html index.php
2.使用git status查看更改状态
[root@git-node1 demo]# git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # renamed: index.html -> index.php #
3.使用git commit 提交git仓库,并描述提交信息
[root@git-node1 demo]# git commit -m "chaned name index.html->index.php" [master ca24753] chaned name index.html->index.php 1 files changed, 0 insertions(+), 0 deletions(-) rename index.html => index.php (100%)
1.4历史数据
在提交了若干更新之后,想回顾下提交历史,可以使用 git log 命令查看提交历史记录。
1.查看提交历史记录
[root@git-node1 demo]# git log commit ca24753faac356ae926c89f6d8c2da2ee69d67ec Author: nulige <nulige@nulige.com> Date: Mon May 8 20:48:46 2017 +0800 chaned name index.html->index.php commit 90596d4d1fdcc37e175d18778e2f07a98c42f86b Author: root <root@git-node1.(none)> Date: Mon May 8 20:26:08 2017 +0800 the first commit index.html
2.查看历史1次提交记录
# -n (n是一个正整数),查看最近n次的提交信息
[root@git-node1 demo]# git log -1 commit ca24753faac356ae926c89f6d8c2da2ee69d67ec Author: nulige <nulige@nulige.com> Date: Mon May 8 20:48:46 2017 +0800 chaned name index.html->index.php commit 90596d4d1fdcc37e175d18778e2f07a98c42f86b Author: root <root@git-node1.(none)> Date: Mon May 8 20:26:08 2017 +0800 the first commit index.html
3.显示提交的内容差异,例如仅查看最近2次差异
[root@git-node1 demo]# git log -p -2 #显示最近二次更新 commit ca24753faac356ae926c89f6d8c2da2ee69d67ec Author: nulige <nulige@nulige.com> Date: Mon May 8 20:48:46 2017 +0800 chaned name index.html->index.php diff --git a/index.html b/index.html deleted file mode 100644 index 6e599f4..0000000 --- a/index.html +++ /dev/null @@ -1 +0,0 @@ -welcome nulige diff --git a/index.php b/index.php new file mode 100644 index 0000000..6e599f4 --- /dev/null +++ b/index.php @@ -0,0 +1 @@ +welcome nulige : commit ca24753faac356ae926c89f6d8c2da2ee69d67ec Author: nulige <nulige@nulige.com> Date: Mon May 8 20:48:46 2017 +0800 chaned name index.html->index.php diff --git a/index.html b/index.html deleted file mode 100644 index 6e599f4..0000000 --- a/index.html +++ /dev/null @@ -1 +0,0 @@ -welcome nulige diff --git a/index.php b/index.php new file mode 100644 index 0000000..6e599f4 --- /dev/null +++ b/index.php @@ -0,0 +1 @@ +welcome nulige commit 90596d4d1fdcc37e175d18778e2f07a98c42f86b Author: root <root@git-node1.(none)> Date: Mon May 8 20:26:08 2017 +0800 : 退出按 q
#--stat: 列出文件的修改行数
[root@git-node1 demo]# git log --stat commit ca24753faac356ae926c89f6d8c2da2ee69d67ec Author: nulige <nulige@nulige.com> Date: Mon May 8 20:48:46 2017 +0800 chaned name index.html->index.php index.html | 1 - index.php | 1 + 2 files changed, 1 insertions(+), 1 deletions(-) commit 90596d4d1fdcc37e175d18778e2f07a98c42f86b Author: root <root@git-node1.(none)> Date: Mon May 8 20:26:08 2017 +0800 the first commit index.html index.html | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
1 [root@git-node1 demo]# git log --pretty=oneline 2 95734131860ef7c9078b8a208ff6437d0952380b chnged name index.html->index.php 3 85bd2680bd4b70aeded9dbd230c07ab086712ff9 the first commit index.htm 4 可以使用format参数来指定具体的输出格式,这样非常便于后期编程的提取分析哦,常用的格式有: 5 %s 提交说明。 6 %cd 提交日期。 7 %an 作者的名字。 8 %cn 提交者的姓名。 9 %ce 提交者的电子邮件。 10 %H 提交对象的完整SHA-1哈希字串。 11 %h 提交对象的简短SHA-1哈希字串。 12 %T 树对象的完整SHA-1哈希字串。 13 %t 树对象的简短SHA-1哈希字串。 14 %P 父对象的完整SHA-1哈希字串。 15 %p 父对象的简短SHA-1哈希字串。 16 %ad 作者的修订时间。 17 定制详细的日志输出
18 [root@git-node1 demo]# git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset %cn"' --abbrev-commit --date=relative 19 * 5f3f588 - (HEAD, origin/master, –r, tt, master) merge branch linux readme.txt (68 分钟之前) xulia 20 |\ 21 | * 4580c3b - (linux) touch readme.txt (80 分钟之前) xuliangwei" 22 * | 4c7a145 - touch readme.txt (72 分钟之前) xuliangwei" 23 |/ 24 * 9573413 - (tag: v1.0.0) chnged name index.html->index.php (5 小时之前) xuliangwei" 25 * 85bd268 - the first commit index.html (5 小时之前) xuliangwei" 26 配置.git/config文件,增加如下2行,以后即可使用 git hlog代替如上复杂命令 27 [root@git-node1 demo]# tail -2 .git/config 28 [alias] 29 hlog = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset %cn' --abbrev-commit --date=relative 30 //以后使用git hlog即可实现复杂的命令 31
1.5还原数据(称为:回滚)
将文件hello boos写成了hello nulige,但是已经提交至远程仓库,现在想要撤回重新提交。
(本小结涉及远程仓库,可先学习后面章节,在回头学习本章节)
1.查看index.html文件
[root@git-node1 demo]# git checkout -b dev //内容存在dev分支 [root@git-node1 demo]# cat index.html hello boss [root@git-node1 demo]# echo "hello nulige" >> index.html
2.追加内容至index.html,并提交至远程仓库
[root@git-node1 demo]# git add index.html
[root@git-node1 demo]# git commit -m "hello nulige" [master 1941990] boss dou 1 file changed, 1 insertion(+)
[root@git-node1 demo]# git push origin dev Counting objects: 5, done. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 298 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To git@git-node1:root/git_demo.git 507bf99..1941990 dev -> dev
3.此时觉得写的不妥,想还原上一次提交的文件快照,找出历史信息
[root@git-node1 demo]# git log -2 * 1941990 - (HEAD, origin/dev, dev) boss dou (2 分钟之前) nulige * 507bf99 - hello (30 分钟之前) nulige
4.回滚:找到历史还原点的值后,就可以还原(值不写全,系统会自动匹配)
[root@git-node1 demo]# git reset --hard 507bf99 #从暂存区那个点,回滚到工作区 HEAD 现在位于 507bf99 hello [root@git-node1 nulige]# git push origin dev -f //强制推送至dev分支 [root@git-node1 demo]# cat index.html hello boss
5、git reflog 用来记录你的每一次命令
[root@git-node1 Bastion-of-machine]# git reflog 08f962f HEAD@{0}: commit (initial): first commit
1.6 删除操作
在Git中,删除也是一个修改操作,我们实战一下,先添加一个新文件test.txt到Git并且提交:
[root@git-node1 demo]# vi test.txt I am nulige
添加到暂存区
[root@git-node1 demo]# git add . [root@git-node1 demo]# git commit -m "add test.txt" [master ac0cb7b] add test.txt 2 files changed, 2 insertions(+), 0 deletions(-) create mode 160000 Bastion-of-machine create mode 100644 test.txt
一般情况下,你通常直接在文件管理器中把没用的文件删了,或者用rm
命令删了
[root@git-node1 demo]# rm test.txt rm:是否删除普通文件 "test.txt"? #回车
#这个时候,Git知道你删除了文件,因此,工作区和版本库就不一致了,git status
命令会立刻告诉你哪些文件被删除了: [root@git-node1 demo]# git status # On branch master # Changed but not updated: # (use "git add/rm <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # deleted: index.php # deleted: test.txt # no changes added to commit (use "git add" and/or "git commit -a")
现在你有两个选择,一是确实要从版本库中删除该文件,那就用命令git rm
删掉,并且git commit
:
[root@git-node1 demo]# ll 总用量 8 drwxr-xr-x 3 root root 4096 5月 8 22:12 Bastion-of-machine -rw-r--r-- 1 root root 12 5月 8 23:50 test.txt [root@git-node1 demo]# rm test.txt rm:是否删除普通文件 "test.txt"? [root@git-node1 demo]# git rm test.txt rm 'test.txt' [root@git-node1 demo]# git commit -m "remove test" [master 7b5310a] remove test 1 files changed, 0 insertions(+), 1 deletions(-) delete mode 100644 test.txt
现在,文件就从版本库中被删除了。
另一种情况是删错了,因为版本库里还有呢,所以可以很轻松地把误删的文件恢复到最新版本:
[root@git-node1 demo]# git checkout -- test.txt
git checkout
其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。
1.7、理解工作区和暂存区
Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。
先来看名词解释。
工作区(Working Directory)
就是你在电脑里能看到的目录,比如我的git_trainning文件夹就是一个工作区:
1
2
|
$ ls git_trainning/ first_git_file.txt |
版本库(Repository)
工作区有一个隐藏目录.git
,这个不算工作区,而是Git的版本库。
Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master
,以及指向master
的一个指针叫HEAD
。
分支和HEAD
的概念我们以后再讲。
前面讲了我们把文件往Git版本库里添加的时候,是分两步执行的:
第一步是用git add
把文件添加进去,实际上就是把文件修改添加到暂存区;
第二步是用git commit
提交更改,实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时,Git自动为我们创建了唯一一个master
分支,所以,现在,git commit
就是往master
分支上提交更改。
你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。
俗话说,实践出真知。现在,我们再练习一遍,先对first_git_file.txt
做个修改,比如加上一行内容:
1
2
3
4
5
6
|
First time using git, excited! update ... insert line here..改之前的. 第一次用git哈哈 insert line again haha... 加点新内容 update v5 |
然后,在工作区新增一个readme.md
文本文件(内容随便写)。
先用git status
查看一下状态:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
$ 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: first_git_file.txt Untracked files: (use "git add <file>..." to include in what will be committed) readme.md no changes added to commit (use "git add" and /or "git commit -a" ) |
Git非常清楚地告诉我们,first_git_file.txt
被修改了,而readme.md
还从来没有被添加过,所以它的状态是Untracked
。
现在,使用命令git add .
,再用git status
再查看一下:
1
2
3
4
5
6
7
8
9
|
$ git add . $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: first_git_file.txt new file : readme.md < /file > |
现在,暂存区的状态就变成这样了:
(盗图关系, 这里readme.txt = first_git_file.txt , LICENSE = readme.md)
所以,git add
命令实际上就是把要提交的所有修改放到暂存区(Stage),然后,执行git commit
就可以一次性把暂存区的所有修改提交到分支。
1
2
3
4
|
$ git commit -m "知道暂存区stage的意思了" [master 9d65cb2] 知道暂存区stage的意思了 2 files changed, 2 insertions(+) create mode 100644 readme.md |
一旦提交后,如果你又没有对工作区做任何修改,那么工作区就是“干净”的:
1
2
3
|
$ git status On branch master nothing to commit, working directory clean |
现在版本库变成了这样,暂存区就没有任何内容了:
(盗图关系, 这里readme.txt = first_git_file.txt , LICENSE = readme.md)
暂存区是Git非常重要的概念,弄明白了暂存区,就弄明白了Git的很多操作到底干了什么。
1.8、远程仓库
注册一个GitHub账号,就可以免费获得Git远程仓库。
由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的,所以,需要一点设置:
第1步:创建SSH Key。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsa
和id_rsa.pub
这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key:
[root@git-node1 demo]# ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: 16:02:9f:cd:58:e5:c1:7c:b2:e9:6b:51:87:e3:f8:2a root@git-node1 The key's randomart image is: +--[ RSA 2048]----+ | . .+o | | o * .+.. | | = + .= . | | . .o + . | | S. + o | | . + . | | + | | E o . | | o.. | +-----------------+ [root@git-node1 demo]# ls ~/.ssh/ id_rsa id_rsa.pub [root@git-node1 demo]# cat ~/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0twNMooyMj25MeCKQoBcarKeXpPSy3mGDnmFeE0qrZ+jqQ8O8DSqaQYXVUPov3axtDS6Sdq+J63fXmZksuMYAWIRzHXzqwyKgU/exu1HAf+
/UwN/nrS1wAVEPEZM5+yutFSnUpZG0Nr2lTyTHnNBugBXr/xyxDtJErOkSbKXwzJevVIYElcLOZMfsWvJBF/zqfgvdAr6bh7nmnyEguiXL6l5CmcC7k5A/WGqFUJRzhFtNK5hTGp6YBsMBv
j3fyr9+nPexMf7TuJO3HvGps0rW0EsXJD092EO4k8cUKwVtlNoonpRChKapyRDQW1kA9dewUGdU/uRsVcCamEyp98b8w== root@git-node1
可以在用户主目录里找到.ssh
目录,里面有id_rsa
和id_rsa.pub
两个文件,这两个就是SSH Key的秘钥对,id_rsa
是私钥,不能泄露出去,id_rsa.pub
是公钥,可以放心地告诉任何人。
第2步:登陆GitHub,打开“Account settings”,“SSH Keys”页面:
然后,点“Add SSH Key”,填上任意Title,在Key文本框里粘贴id_rsa.pub
文件的内容:
点“Add Key”,你就应该看到已经添加的Key
为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。
当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。
最后友情提示,在GitHub上免费托管的Git仓库,任何人都可以看到喔(但只有你自己才能改)。所以,不要把敏感信息放进去。
如果你不想让别人看到Git库,有两个办法,一个是交点保护费,让GitHub把公开的仓库变成私有的,这样别人就看不见了(不可读更不可写)。另一个办法是自己动手,搭一个Git服务器,因为是你自己的Git服务器,所以别人也是看不见的。这个方法我们后面会讲到的,相当简单,公司内部开发必备。
确保你拥有一个GitHub账号后,我们就即将开始远程仓库的学习。
1.9、分支管理
分支就是科幻电影里面的平行宇宙,当你正在电脑前努力学习Git的时候,另一个你正在另一个平行宇宙里努力学习SVN。
如果两个平行宇宙互不干扰,那对现在的你也没啥影响。不过,在某个时间点,两个平行宇宙合并了,结果,你既学会了Git又学会了SVN!
分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。
现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。
其他版本控制系统如SVN等都有分支管理,但是用过之后你会发现,这些版本控制系统创建和切换分支比蜗牛还慢,简直让人无法忍受,结果分支功能成了摆设,大家都不去用。
但Git的分支是与众不同的,无论创建、切换和删除分支,Git在1秒钟之内就能完成!无论你的版本库是1个文件还是1万个文件。
2.0、创建与合并分支
在学习版本回退部分时,你已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master
分支。HEAD
严格来说不是指向提交,而是指向master
,master
才是指向提交的,所以,HEAD
指向的就是当前分支。
下面开始实战。
首先,我们创建dev
分支,然后切换到dev
分支:
1
2
|
$ git checkout -b dev Switched to a new branch 'dev' |
git checkout
命令加上-b
参数表示创建并切换,相当于以下两条命令:
1
2
3
|
$ git branch dev $ git checkout dev Switched to branch 'dev' |
然后,用git branch
命令查看当前分支:
1
2
3
|
$ git branch * dev master |
git branch
命令会列出所有分支,当前分支前面会标一个*
号。
然后,我们就可以在dev
分支上正常提交,比如对readme.txt做个修改,加上一行:
1
|
Creating a new branch is quick. |
然后提交:
1
2
3
4
|
$ git add readme.txt $ git commit -m "branch test" [dev fec145a] branch test 1 file changed, 1 insertion(+) |
现在,dev
分支的工作完成,我们就可以切换回master
分支:
1
2
|
$ git checkout master Switched to branch 'master' |
切换回master
分支后,再查看一个readme.txt文件,刚才添加的内容不见了!因为那个提交是在dev
分支上,而master
分支此刻的提交点并没有变:
现在,我们把dev
分支的工作成果合并到master
分支上:
1
2
3
4
5
|
$ git merge dev Updating d17efd8..fec145a Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+) |
git merge
命令用于合并指定分支到当前分支。合并后,再查看readme.txt的内容,就可以看到,和dev
分支的最新提交是完全一样的。
注意到上面的Fast-forward
信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master
指向dev
的当前提交,所以合并速度非常快。
当然,也不是每次合并都能Fast-forward
,我们后面会讲其他方式的合并。
合并完成后,就可以放心地删除dev
分支了:
1
2
|
$ git branch -d dev Deleted branch dev (was fec145a). |
删除后,查看branch
,就只剩下master
分支了:
1
2
|
$ git branch * master |
因为创建、合并和删除分支非常快,所以Git鼓励你使用分支完成某个任务,合并后再删掉分支,这和直接在master
分支上工作效果是一样的,但过程更安全。
解决冲突
人生不如意之事十之八九,合并分支往往也不是一帆风顺的。
准备新的feature1
分支,继续我们的新分支开发:
1
2
|
$ git checkout -b feature1 Switched to a new branch 'feature1' |
修改readme.txt最后一行,改为:
1
|
added this line from branch feature 1 |
在feature1
分支上提交:
$ git add readme.txt
$ git commit -m "add feature"
[feature1 75a857c] AND simple
1 file changed, 1 insertion(+), 1 deletion(-)
切换到master
分支:
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
Git还会自动提示我们当前master
分支比远程的master
分支要超前1个提交。
在master
分支上把readme.txt文件的最后一行改为:
1
|
added this line from master |
提交:
$ git add readme.txt
$ git commit -m "master update"
[master 400b400] & simple
1 file changed, 1 insertion(+), 1 deletion(-)
现在,master
分支和feature1
分支各自都分别有新的提交,变成了这样:
这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突,我们试试看:
1
2
3
4
|
$ git merge feature1 Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result. |
果然冲突了!Git告诉我们,readme.txt文件存在冲突,必须手动解决冲突后再提交。git status
也可以告诉我们冲突的文件:
1
2
3
4
5
6
7
8
9
10
|
$ git status # On branch master # Your branch is ahead of 'origin/master' by 2 commits. # # Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: readme.txt # no changes added to commit (use "git add" and /or "git commit -a" ) |
我们可以直接查看readme.txt的内容:
1
2
3
4
5
6
7
|
#git study repo Creating a new branch is quick. <<<<<<< HEAD added this line from master ======= added this line from branch feature 1 >>>>>>> feature1 |
Git用<<<<<<<
,=======
,>>>>>>>
标记出不同分支的内容,我们修改如下后保存:
1
2
3
4
|
#git study repo Creating a new branch is quick. added this line from master added this line from branch feature 1 |
再提交
1
2
3
|
$ git add readme.txt $ git commit -m "conflict fixed" [master 59bc1cb] conflict fixed |
现在,master
分支和feature1
分支变成了下图所示:
用带参数的git log
也可以看到分支的合并情况:
1
2
3
4
5
6
7
8
|
$ git log --graph --pretty=oneline * feedd786cad3e18323a41846fcc1b0d52fc0c98e fix conflict |\ | * 01f8f8d168e113fac9fbe24c4cfa6d4c351a9821 update from branch * | 743ccee30f3d74f1993f17e7312032b7399b1306 from master |/ * edfbc29982927236596539e0f1971b0575f803c0 branch test * 8675486bfeeb340914369e80d2cfcf3e854e88a3 add home page |
2.1、分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本;
你和你的小伙伴们每个人都在dev
分支上干活,每个人都有自己的分支,时不时地往dev
分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
2.2、bug分支
软件开发中,bug就像家常便饭一样。有了bug就需要修复,在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。
当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支issue-101
来修复它,但是,等等,当前正在dev
上进行的工作还没有提交:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
$ git status # On branch dev # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: hello.py # # 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 # |
并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复该bug,怎么办?
幸好,Git还提供了一个stash
功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
1
2
3
|
$ git stash Saved working directory and index state WIP on dev: 6224937 add merge HEAD is now at 6224937 add merge |
现在,用git status
查看工作区,就是干净的(除非有没有被Git管理的文件),因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug,假定需要在master
分支上修复,就从master
创建临时分支:
1
2
3
4
5
|
$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. $ git checkout -b issue-101 Switched to a new branch 'issue-101' |
现在修复bug,需要把“Git is free software ...”改为“Git is a free software ...”,然后提交:
1
2
3
4
|
$ git add readme.txt $ git commit -m "fix bug 101" [issue-101 cc17032] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-) |
修复完成后,切换到master
分支,并完成合并,最后删除issue-101
分支:
1
2
3
4
5
6
7
8
9
|
$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 2 commits. $ git merge --no-ff -m "merged bug fix 101" issue-101 Merge made by the 'recursive' strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git branch -d issue-101 Deleted branch issue-101 (was cc17032). |
太棒了,原计划两个小时的bug修复只花了5分钟!现在,是时候接着回到dev
分支干活了!
1
2
3
4
5
|
$ git checkout dev Switched to branch 'dev' $ git status # On branch dev nothing to commit (working directory clean) |
工作区是干净的,刚才的工作现场存到哪去了?用git stash list
命令看看:
1
2
|
$ git stash list stash@{0}: WIP on dev: 6224937 add merge |
工作现场还在,Git把stash内容存在某个地方了,但是需要恢复一下,有两个办法:
一是用git stash apply
恢复,但是恢复后,stash内容并不删除,你需要用git stash drop
来删除;
另一种方式是用git stash pop
,恢复的同时把stash内容也删了:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
$ git stash pop # On branch dev # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: hello.py # # 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 # Dropped refs /stash @{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40) |
再用git stash list
查看,就看不到任何stash内容了:
1
|
$ git stash list |
你可以多次stash,恢复的时候,先用git stash list
查看,然后恢复指定的stash,用命令:
1
|
$ git stash apply stash@{0} |
2.3、分支策略
多人协作
当你从远程仓库克隆时,实际上Git自动把本地的master
分支和远程的master
分支对应起来了,并且,远程仓库的默认名称是origin
。
要查看远程库的信息,用git remote
:
1
2
|
$ git remote origin |
或者,用git remote -v
显示更详细的信息:
1
2
3
|
$ git remote - v origin git@github.com:triaquae /gitskills .git (fetch) origin git@github.com:triaquae /gitskills .git (push) |
上面显示了可以抓取和推送的origin
的地址。如果没有推送权限,就看不到push的地址。
2.4、 推送分支
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上:
1
|
$ git push origin master |
如果要推送其他分支,比如dev
,就改成:
1
|
$ git push origin dev |
但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?
-
master
分支是主分支,因此要时刻与远程同步; -
dev
分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步; -
bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
-
feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
总之,就是在Git中,分支完全可以在本地自己藏着玩,是否推送,视你的心情而定!
2.5、抓取分支
多人协作时,大家都会往master
和dev
分支上推送各自的修改。
现在,模拟一个你的小伙伴,可以在另一台电脑(注意要把SSH Key添加到GitHub)或者同一台电脑的另一个目录下克隆:
1
2
3
4
5
6
7
|
$ git clone git@github.com:triaquae /gitskills .git Cloning into 'gitskills' ... remote: Counting objects: 16, done . remote: Compressing objects: 100% (7 /7 ), done . remote: Total 16 (delta 0), reused 10 (delta 0), pack-reused 0 Receiving objects: 100% (16 /16 ), done . Checking connectivity... done . |
当你的小伙伴从远程库clone时,默认情况下,你的小伙伴只能看到本地的master
分支。不信可以用git branch
命令看看:
1
2
|
$ git branch * master |
现在,你的小伙伴要在dev
分支上开发,就必须创建远程origin
的dev
分支到本地,于是他用这个命令创建本地dev
分支:
1
|
$ git checkout -b dev origin /dev |
现在,他就可以在dev
上继续修改,然后,时不时地把dev
分支push
到远程:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
$ git add . $ git commit -m "small updates" [dev f1b762e] small updates 2 files changed, 5 insertions(+), 1 deletion(-) Alexs-MacBook-Pro:gitskills alex$ git push origin dev Counting objects: 4, done . Delta compression using up to 8 threads. Compressing objects: 100% (3 /3 ), done . Writing objects: 100% (4 /4 ), 438 bytes | 0 bytes /s , done . Total 4 (delta 0), reused 0 (delta 0) To git@github.com:triaquae /gitskills .git 33ec6b4..f1b762e dev -> dev |
你的小伙伴已经向origin/dev分支推送了他的提交,而碰巧你也对同样的文件作了修改,并试图推送:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
$ git add . $ git commit -m "add Dog class" [dev 7e7b1bf] add Dog class 2 files changed, 7 insertions(+) $ git push origin dev To git@github.com:triaquae /gitskills .git ! [rejected] dev -> dev (fetch first) error: failed to push some refs to 'git@github.com:triaquae/gitskills.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...' ) before pushing again. #提示你了,先把远程最新的拉下来再提交你的 hint: See the 'Note about fast-forwards' in 'git push --help' for details. |
推送失败,因为你的小伙伴的最新提交和你试图推送的提交有冲突,解决办法也很简单,Git已经提示我们,先用git pull
把最新的提交从origin/dev
抓下来,然后,在本地合并,解决冲突,再推
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
$ git pull remote: Counting objects: 4, done . remote: Compressing objects: 100% (3 /3 ), done . remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0 Unpacking objects: 100% (4 /4 ), done . From github.com:triaquae /gitskills 33ec6b4..f1b762e dev -> origin /dev There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull <remote> <branch> If you wish to set tracking information for this branch you can do so with: git branch -- set -upstream-to=origin/<branch> dev |
git pull
也失败了,原因是没有指定本地dev
分支与远程origin/dev
分支的链接,根据提示,设置dev
和origin/dev
的链接:
1
2
|
$ git branch -- set -upstream-to=origin /dev dev Branch dev set up to track remote branch dev from origin. |
再pull:
1
2
3
4
5
6
|
$ git pull Auto-merging hello.py CONFLICT (content): Merge conflict in hello.py Auto-merging branch_test.md CONFLICT (content): Merge conflict in branch_test.md Automatic merge failed; fix conflicts and then commit the result. |
这回git pull
成功,但是合并有冲突,需要手动解决,解决的方法和分支管理中的解决冲突完全一样。解决后,提交,再push:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
$ git add . $ git commit -m "merge & fix hello.py" [dev 93e28e3] merge & fix hello.py $ git push origin dev Counting objects: 8, done . Delta compression using up to 8 threads. Compressing objects: 100% (7 /7 ), done . Writing objects: 100% (8 /8 ), 819 bytes | 0 bytes /s , done . Total 8 (delta 1), reused 0 (delta 0) remote: Resolving deltas: 100% (1 /1 ), done . To git@github.com:triaquae /gitskills .git f1b762e..93e28e3 dev -> dev |
因此,多人协作的工作模式通常是这样:
-
首先,可以试图用
git push origin branch-name
推送自己的修改; -
如果推送失败,则因为远程分支比你的本地更新,需要先用
git pull
试图合并; -
如果合并有冲突,则解决冲突,并在本地提交;
-
没有冲突或者解决掉冲突后,再用
git push origin branch-name
推送就能成功!
如果git pull
提示“no tracking information”,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream branch-name origin/branch-name
。
这就是多人协作的工作模式,一旦熟悉了,就非常简单。
2.6、 github使用
我们一直用GitHub作为免费的远程仓库,如果是个人的开源项目,放到GitHub上是完全没有问题的。其实GitHub还是一个开源协作社区,通过GitHub,既可以让别人参与你的开源项目,也可以参与别人的开源项目。
在GitHub出现以前,开源项目开源容易,但让广大人民群众参与进来比较困难,因为要参与,就要提交代码,而给每个想提交代码的群众都开一个账号那是不现实的,因此,群众也仅限于报个bug,即使能改掉bug,也只能把diff文件用邮件发过去,很不方便。
但是在GitHub上,利用Git极其强大的克隆和分支功能,广大人民群众真正可以第一次自由参与各种开源项目了。
如何参与一个开源项目呢?比如人气极高的bootstrap项目,这是一个非常强大的CSS框架,你可以访问它的项目主页https://github.com/twbs/bootstrap,点“Fork”就在自己的账号下克隆了一个bootstrap仓库,然后,从自己的账号下clone:
1
|
git clone git@github.com:michaelliao /bootstrap .git |
一定要从自己的账号下clone仓库,这样你才能推送修改。如果从bootstrap的作者的仓库地址git@github.com:twbs/bootstrap.git
克隆,因为没有权限,你将不能推送修改。
Bootstrap的官方仓库twbs/bootstrap
、你在GitHub上克隆的仓库my/bootstrap
,以及你自己克隆到本地电脑的仓库,他们的关系就像下图显示的那样:
如果你想修复bootstrap的一个bug,或者新增一个功能,立刻就可以开始干活,干完后,往自己的仓库推送。
如果你希望bootstrap的官方库能接受你的修改,你就可以在GitHub上发起一个pull request。当然,对方是否接受你的pull request就不一定了。
如果你没能力修改bootstrap,但又想要试一把pull request,那就Fork一下我的仓库:https://github.com/triaquae/gitskills ,创建一个your-github-id.txt
的文本文件,写点自己学习Git的心得,然后推送一个pull request给我,我会视心情而定是否接受。
小结
-
在GitHub上,可以任意Fork开源仓库;
-
自己拥有Fork后的仓库的读写权限;
-
可以推送pull request给官方仓库来贡献代码。
2.7、 忽略特殊文件.gitignore
有些时候,你必须把某些文件放到Git工作目录中,但又不能提交它们,比如保存了数据库密码的配置文件啦,等等,每次git status
都会显示Untracked files ...
,有强迫症的童鞋心里肯定不爽。
好在Git考虑到了大家的感受,这个问题解决起来也很简单,在Git工作区的根目录下创建一个特殊的.gitignore
文件,然后把要忽略的文件名填进去,Git就会自动忽略这些文件。
不需要从头写.gitignore
文件,GitHub已经为我们准备了各种配置文件,只需要组合一下就可以使用了。所有配置文件可以直接在线浏览:https://github.com/github/gitignore
忽略文件的原则是:
- 忽略操作系统自动生成的文件,比如缩略图等;
- 忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的
.class
文件; - 忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件。
举个例子:
假设你在Windows下进行Python开发,Windows会自动在有图片的目录下生成隐藏的缩略图文件,如果有自定义目录,目录下就会有Desktop.ini
文件,因此你需要忽略Windows自动生成的垃圾文件:
1
2
3
4
|
# Windows: Thumbs.db ehthumbs.db Desktop.ini |
然后,继续忽略Python编译产生的.pyc
、.pyo
、dist
等文件或目录:
1
2
3
4
5
6
7
|
# Python: *.py[cod] *.so *.egg *.egg-info dist build |
加上你自己定义的文件,最终得到一个完整的.gitignore
文件,内容如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
# Windows: Thumbs.db ehthumbs.db Desktop.ini # Python: *.py[cod] *.so *.egg *.egg-info dist build # My configurations: db.ini deploy_key_rsa |
最后一步就是把.gitignore
也提交到Git,就完成了!当然检验.gitignore
的标准是git status
命令是不是说working directory clean
。
使用Windows的童鞋注意了,如果你在资源管理器里新建一个.gitignore
文件,它会非常弱智地提示你必须输入文件名,但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore
了。
有些时候,你想添加一个文件到Git,但发现添加不了,原因是这个文件被.gitignore
忽略了:
1
2
3
4
|
$ git add App.class The following paths are ignored by one of your .gitignore files: App.class Use -f if you really want to add them. |
如果你确实想添加该文件,可以用-f
强制添加到Git:
1
|
$ git add -f App.class |
或者你发现,可能是.gitignore
写得有问题,需要找出来到底哪个规则写错了,可以用git check-ignore
命令检查:
1
2
|
$ git check-ignore - v App.class .gitignore:3:*.class App.class |
Git会告诉我们,.gitignore
的第3行规则忽略了该文件,于是我们就可以知道应该修订哪个规则。
小结
-
忽略某些文件时,需要编写
.gitignore
; -
.gitignore
文件本身要放到版本库里,并且可以对.gitignore
做版本管理!
2.8、基本操作小结
相信大家对Git的基本操作有一定的了解,下面进行一下简单的梳理总结:
命令 git config --global user.name "name" #配置git使用用户
# git config --global user.email "mail" #配置git使用邮箱
# git config --global color.ui true #配置颜色
# git config --list #查看当前配置
# git init #初始为git工作目录
# git status #查看git状态
# git reflog #查看未来历史更新点
# git reset --hard 4bf5b29 #找到历史还原点的SHA-1值,就可以还原(值不写全,系统会自动匹配)
# git checkout -- file #恢复暂存区至上一版本
# git add [file1] [file2] ... #添加指定文件至暂存区
# git add [dir] #添加指定目录至暂存区,包括子目录(递归添加)
# git add . #添加当前目录所有文件至暂存区
# git rm [file1] [file2] ... #删除工作区文件,并将这次删除放入暂存区
# git rm –cached [file] #停止追踪指定文件,但该文件会保留在工作区
# git mv [file-old] [file-new] #重命名文件,修改后放入暂存区