Git
Git是什么?
Git是目前世界上最先进的分布式版本控制系统(没有之一)
CVS及SVN都是集中式的版本控制系统,而Git是分布式版本控制系统
集中式版本控制系统,版本库是集中存放在中央服务器的,而干活的时候,用的都是自己的电脑,所以要先从中央服务器取得最新的版本,然后开始干活,干完活了,再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆,你要改一本书,必须先从图书馆借出来,然后回到家自己改,改完了,再放回图书馆。
集中式版本控制系统最大的毛病就是必须联网才能工作,如果在局域网内还好,带宽够大,速度够快,
分布式版本控制系统与集中式版本控制系统有何不同呢?
分布式版本控制系统根本没有“中央服务器”,每个人的电脑上都是一个完整的版本库,这样,你工作的时候,就不需要联网了,因为版本库就在你自己的电脑上
和集中式版本控制系统相比,分布式版本控制系统的安全性要高很多,因为每个人电脑里都有完整的版本库,某一个人的电脑坏掉了不要紧,随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题,所有人都没法干活了
分布式版本控制系统除了Git以及促使Git诞生的BitKeeper外,还有类似Git的Mercurial和Bazaar等。这些分布式版本控制系统各有特点,但最快、最简单也最流行的依然是Git!
创建版本库
什么是版本库?
版本库又名仓库,英文名repository,你可以简单理解成一个目录,这个目录里面的所有文件都可以被Git管理起来,每个文件的修改、删除,Git都能跟踪,以便任何时刻都可以追踪历史,或者在将来某个时刻可以“还原”
第一步: 创建一个版本库非常简单,首先,选择一个合适的地方,创建一个空目录 :
pwd
命令用于显示当前目录
第二步,通过git init
命令把这个目录变成Git可以管理的仓库
把一个文件放到Git仓库只需要两步
第一步,用命令git add
告诉Git,把文件添加到仓库:
$ git add readme.txt
执行上面的命令,没有任何显示,这就对了,Unix的哲学是“没有消息就是好消息”,说明添加成功。
第二步,用命令git commit
告诉Git,把文件提交到仓库:
$ git commit -m "wrote a readme file"
[master (root-commit) eaadf4e] wrote a readme file
1 file changed, 2 insertions(+)
create mode 100644 readme.txt
简单解释一下git commit
命令,-m
后面输入的是本次提交的说明,可以输入任意内容,当然最好是有意义的,这样就能从历史记录里方便地找到改动记录。
commit
可以一次提交很多文件,所以你可以多次add
不同的文件 比如:
$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."
疑难解答
Q:输入git add readme.txt
,得到错误:fatal: not a git repository (or any of the parent directories)
。
A:Git命令必须在Git仓库目录内执行(git init
除外),在仓库目录外执行是没有意义的。
Q:输入git add readme.txt
,得到错误fatal: pathspec 'readme.txt' did not match any files
。
A:添加某个文件时,该文件必须在当前目录下存在,用ls
或者dir
命令查看当前目录的文件,看看文件是否存在,或者是否写错了文件名。
小结
初始化一个Git仓库,使用git init
命令。
添加文件到Git仓库,分两步:
- 使用命令
git add
,注意,可反复多次使用,添加多个文件; - 使用命令
git commit -m
,完成。
时光机穿梭
git status
命令看看结果 ,
git status
命令可以让我们时刻掌握仓库当前的状态,
git diff
这个命令 查看difference,显示的格式正是Unix通用的diff格式
提交修改和提交新文件的步骤
第一步是git add
:
$ git add <file>.txt
同样没有任何输出。在执行第二步git commit
之前,我们再运行git status
看看当前仓库的状态:
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: <fli.txt
git status
告诉我们,将要被提交的修改包括file.txt`,下一步,就可以放心地提交了:
$ git commit -m "add distributed"
[master e475afc] add distributed
1 file changed, 1 insertion(+), 1 deletion(-)
提交后,我们再用git status
命令看看仓库的当前状态:
$ git status
On branch master
nothing to commit, working tree clean
Git告诉我们当前没有需要提交的修改,而且,工作目录是干净(working tree clean)的
小结
- 要随时掌握工作区的状态,使用
git status
命令。 - 如果
git status
告诉你有文件被修改过,用git diff
可以查看修改内容
版本回退
用git log
命令查看历史记录
git log
命令显示从最近到最远的提交日志
如果嫌输出信息太多,看得眼花缭乱的,可以试试加上--pretty=oneline
参数 , 看到的一大串类似1094adb...
的是commit id
(版本号)
每提交一个新版本,实际上Git就会把它们自动串成一条时间线。如果使用可视化工具查看Git历史,就可以更清楚地看到提交历史的时间线
使用git reset
命令
$ git reset --hard HEAD^ , 在Git中,用HEAD
表示当前版本 , 上一个版本就是HEAD^
, 上上一个版本就是HEAD^^
$ git reset --hard +版本号(版本号没必要写全,前几位就可以了,Git会自动去找),回到指定的某个版本
cat file.txt//查看文件内容
--hard
参数有啥意义?
Git的版本回退速度非常快,因为Git在内部有个指向当前版本的HEAD
指针,当你回退版本的时候,Git仅仅是把HEAD从指向回退的版本 , 然后顺便把工作区的文件更新了 。
Git提供了一个命令git reflog
用来记录你的每一次命令
小结
HEAD
指向的版本就是当前版本,因此,Git允许我们在版本的历史之间穿梭,使用命令git reset --hard commit_id
。- 穿梭前,用
git log
可以查看提交历史,以便确定要回退到哪个版本。 - 要重返未来,用
git reflog
查看命令历史,以便确定要回到未来的哪个版本
工作区和暂存区
Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念
git add
命令实际上就是把要提交的所有修改放到暂存区(Stage),然后,执行git commit
就可以一次性把暂存区的所有修改提交到分支。
一旦提交后,如果你又没有对工作区做任何修改,那么工作区就是“干净”的:
管理和修改
什么是修改?
新增了一行,这就是一个修改,删除了一行,也是一个修改,更改了某些字符,也是一个修改,删了一些又加了一些,也是一个修改,甚至创建一个新文件,也算一个修改。
第一次修改 -> git add
-> 第二次修改 -> git commit
Git管理的是修改,当你用git add
命令后,在工作区的第一次修改被放入暂存区,准备提交,但是,在工作区的第二次修改并没有放入暂存区,所以,git commit
只负责把暂存区的修改提交了,也就是第一次的修改被提交了,第二次的修改不会被提交。
提交第二次修改: 可以继续git add
再git commit
,也可以别着急提交第一次修改,先git add
第二次修改,再git commit
,就相当于把两次修改合并后一块提交了 比如: 第一次修改 -> git add
-> 第二次修改 -> git add
-> git commit
用git diff HEAD -- readme.txt
命令可以查看工作区和版本库里面最新版本的区别
小结
每次修改,如果不用git add
到暂存区,那就不会加入到commit
中。
撤销修改
git checkout -- file
可以丢弃工作区的修改
意思就是,把file.txt文件在工作区的修改全部撤销,这里有两种情况:
一种是file.txt自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
一种是file.txt已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
总之,就是让这个文件回到最近一次git commit
或git add
时的状态。
git checkout -- file
命令中的--
很重要,没有--
,就变成了“切换到另一个分支”的命令 。
用命令git reset HEAD
可以把暂存区的修改撤销掉(unstage),重新放回工作区 。
git reset
命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD
时,表示最新的版本。
小结
场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout -- file
。
场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD
,就回到了场景1,第二步按场景1操作。
场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考版本回退一节,不过前提是没有推送到远程库。
删除文件
在Git中,删除也是一个修改操作 , 一般情况下,你通常直接在文件管理器中把没用的文件删了,或者用rm
命令删了 ,但是 这个时候,Git知道你删除了文件,因此,工作区和版本库就不一致了,git status
命令会立刻告诉你哪些文件被删除了 , 现在你有两个选择,一是确实要从版本库中删除该文件,那就用命令git rm
删掉,并且git commit
, 现在,文件就从版本库中被删除了。
git checkout
其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。
注意:从来没有被添加到版本库就被删除的文件,是无法恢复的 !!
小结
命令git rm
用于删除一个文件。如果一个文件已经被提交到版本库,那么你永远不用担心误删,但是要小心,你只能恢复文件到最新版本,你会丢失最近一次提交后你修改的内容。
远程仓库
自行注册GitHub账号。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的,所以,需要一点设置:
第1步:创建SSH Key。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsa
和id_rsa.pub
这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key: ssh-keygen -t rsa -C “youremail@example.com”
如果一切顺利的话,可以在用户主目录里找到.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,然后,在右上角找到“Create a new repo”按钮,创建一个新的仓库:
在Repository name填入learngit
,其他保持默认设置,点击“Create repository”按钮,就成功地创建了一个新的Git仓库
目前,在GitHub上的这个learngit
仓库还是空的,GitHub告诉我们,可以从这个仓库克隆出新的仓库,也可以把一个已有的本地仓库与之关联,然后,把本地仓库的内容推送到GitHub仓库。
本地关联远程库 :
git remote add origin git@github.com:*******/learngit.git
origin是远程库默认的名字 , 也可以改成别的 。
用 git push -u origin master命令本地库的所有内容推送到远程库上 。
由于远程库是空的,我们第一次推送master
分支时,加上了-u
参数,Git不但会把本地的master
分支内容推送的远程新的master
分支,还会把本地的master
分支和远程的master
分支关联起来,在以后的推送或者拉取时就可以简化命 。
推送成功后,可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样
只要本地作了提交,就可以通过命令:
$ git push origin master
把本地master
分支的最新修改推送至GitHub,现在,你就拥有了真正的分布式版本库!
删除远程库
可以用git remote rm
命令。使用前,建议先用git remote -v
查看远程库信息:
此处的“删除”其实是解除了本地和远程的绑定关系,并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库,需要登录到GitHub,在后台页面找到删除按钮再删除。
小结
要关联一个远程库,使用命令git remote add origin git@server-name:path/repo-name.git
;
关联一个远程库时必须给远程库指定一个名字,origin
是默认习惯命名;
关联后,使用命令git push -u origin master
第一次推送master分支的所有内容;
此后,每次本地提交后,只要有必要,就可以使用命令git push origin master
推送最新修改;
分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在,也就是有没有联网都可以正常工作,而SVN在没有联网的时候是拒绝干活的!当有网络的时候,再把本地提交推送一下就完成了同步。
从远程库克隆
首先,登陆GitHub,创建一个新的仓库,名字叫gitskills
我们勾选Initialize this repository with a README
,这样GitHub会自动为我们创建一个README.md
文件。创建完毕后,可以看到README.md
文件
下一步是用命令git clone
克隆一个本地库
命令:git clone git@github.com:*******/gitskills.git
然后进入gitskills
目录看看,已经有README.md
文件了
cd gitskills
$ ls
README.md
小结
要克隆一个仓库,首先必须知道仓库的地址,然后使用git clone
命令克隆。
Git支持多种协议,包括https
,但ssh
协议速度最快。
分支管理
创建与合并分支
每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master
分支。HEAD
严格来说不是指向提交,而是指向master
,master
才是指向提交的,所以,HEAD
指向的就是当前分支。
一开始的时候,master
分支是一条线,Git用master
指向最新的提交,再用HEAD
指向master
,就能确定当前分支,以及当前分支的提交点:
每次提交,master
分支都会向前移动一步,这样,随着你不断提交,master
分支的线也越来越长。
当我们创建新的分支,例如dev
时,Git新建了一个指针叫dev
,指向master
相同的提交,再把HEAD
指向dev
,就表示当前分支在dev
上:
从现在开始,对工作区的修改和提交就是针对dev
分支了,比如新提交一次后,dev
指针往前移动一步,而master
指针不变:
假如我们在dev
上的工作完成了,就可以把dev
合并到master
上。Git怎么合并呢?最简单的方法,就是直接把master
指向dev
的当前提交,就完成了合并 。
合并完分支后,甚至可以删除dev
分支。删除dev
分支就是把dev
指针给删掉,删掉后,我们就剩下了一条master
分支 。
解决冲突
当Git无法自动合并分支时,就必须首先解决冲突。解决冲突后,再提交,合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容,再提交。
用git log --graph
命令可以看到分支合并图
分支管理策略
合并分支时,可能Git会用Fast forward
模式,但这种模式下,删除分支后,会丢掉分支信息。
如果要强制禁用Fast forward
模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
分支策略
在实际开发中应该按照几个基本原则进行分支管理:
首先,master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;干活都在dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本。
每个人都在dev
分支上干活,每个人都有自己的分支,时不时地往dev
分支上合并就可以了。
小结
Git分支十分强大,在团队开发中应该充分应用。
合并分支时,加上--no-ff
参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward
合并就看不出来曾经做过合并。
Bug分支
软件开发中,bug就像家常便饭一样。有了bug就需要修复,在Git中,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。
Git提供了一个stash
功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
用git status
查看工作区,就是干净的(除非有没有被Git管理的文件),因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug,假定需要在master
分支上修复,就从master
创建临时分支, 修复完成后,切换到master
分支,并完成合并,最后删除issue-101
分支
用git stash list
命令看看刚才的工作现场存到哪去了
Git把stash内容存在某个地方了,但是需要恢复一下,有两个办法:
一是用git stash apply
恢复,但是恢复后,stash内容并不删除,你需要用git stash drop
来删除;
另一种方式是用git stash pop
,恢复的同时把stash内容也删了。
在master分支上修复了bug后,我们要想一想,dev分支是早期从master分支分出来的,所以,这个bug其实在当前dev分支上也存在
小结
修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除;
当手头工作没有完成时,先把工作现场git stash
一下,然后去修复bug,修复后,再git stash pop
,回到工作现场;
在master分支上修复的bug,想要合并到当前dev分支,可以用git cherry-pick
命令,把bug提交的修改“复制”到当前分支,避免重复劳动。
Feature分支
每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支
如果要丢弃一个没有被合并过的分支,可以通过git branch -D
强行删除。
多人协作
当你从远程仓库克隆时,实际上Git自动把本地的master
分支和远程的master
分支对应起来了,并且,远程仓库的默认名称是origin
用git remote
命令要查看远程库的信息,
或者,用git remote -v
显示更详细的信息
推送分支
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上:
$ git push origin 分支名
并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?
master
分支是主分支,因此要时刻与远程同步;dev
分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;- bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
- feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
抓取分支
多人协作时,大家都会往master
和dev
分支上推送各自的修改。
当从远程库clone时,默认情况下,只能看到本地的master
分支。可以用git branch
命令看看:
要在dev
分支上开发,就必须创建远程origin
的dev
分支到本地,用 git checkout -b dev origin/dev命令创建分支:
碰巧你也对同样的文件作了修改,并试图推送 , 如果推送失败,是因为你的clone的最新提交和你试图推送的提交有冲突,解决办法也很简单,先用git pull
把最新的提交从origin/dev
抓下来,然后,在本地合并,解决冲突,再推送 ,如果 git pull
也失败了,原因是没有指定本地dev
分支与远程origin/dev
分支的链接,用git branch --set-upstream-to=origin/dev dev命令设置dev
和origin/dev
的链接,再次pull
这回git pull
成功,但是合并有冲突,需要手动解决,解决的方法和分支管理中的解决冲突完全一样。解决后,提交,再push
多人协作的工作模式:
- 首先,可以试图用
git push origin
推送自己的修改; - 如果推送失败,则因为远程分支比你的本地更新,需要先用
git pull
试图合并; - 如果合并有冲突,则解决冲突,并在本地提交;
- 没有冲突或者解决掉冲突后,再用
git push origin
推送就能成功!
如果git pull
提示no tracking information
,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream-to origin/
小结
- 查看远程库信息,使用
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
,如果有冲突,要先处理冲突
ush origin 推送自己的修改; 2. 如果推送失败,则因为远程分支比你的本地更新,需要先用
git pull试图合并; 3. 如果合并有冲突,则解决冲突,并在本地提交; 4. 没有冲突或者解决掉冲突后,再用
git push origin `推送就能成功!
如果git pull
提示no tracking information
,则说明本地分支和远程分支的链接关系没有创建,用命令git branch --set-upstream-to origin/
小结
- 查看远程库信息,使用
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 常用命令
mkdir 文件名 //新建目录
pwd //显示当前目录
1 file changed //一个文件被改动
2 insertions //插入两行内容
git diff 文件名 //查看修改内容 difference(差异;区别)
git log //最近到最远的提交日志
git log --pretty=oneline //与git log类似,输出的内容会变少
git rest --hard HEAD^ //回退到上一个版本,git rest 命令,HEAD表示指向当前版本的指针
cat 文件名 //查看回退后的版本内容
找不到最新版本怎么办?git reflog //记录你的每一次命令
版本之间的切换 git reset --hard commit_id(版本id)
git checkout – 文件名 //撤销内容
git reset HEAD 文件名 //重置到新版本
rm 文件名 //删除一个文件
git rm 文件名 //同上
git remote add to origin 远程仓库地址
git push -u origin master
//第一次推送master分支,加上-u参数,还会把本地分支和远程分支关联
git remote -v //查看远程信息
git remote rm origin //删除名字为origin的仓库(只是解除本地和远程的绑定关系)
git remote add origin 远程仓库地址 //本地关联远程仓库
git checkout -b dev //-b表示创建并切换,相当于两条命令
git branch //所有的分支,当前分支前有(*)标注
git branch 分支名 //创建分支
git merge 分支名 //合并指定分支到当前分支
git switch -c 分支名 //创建+切换分支
git switch 分支名 //切换分支
git branch -d 分支名 //删除分支
git branch 查看本地所有分支
git status 查看当前状态
git commit 提交
git branch -a 查看所有的分支
git branch -r 查看远程所有分支
git commit -am “init” 提交并且加注释
git remote add origin git@192.168.1.119:ndshow
git push origin master 将文件给推到服务器上
git remote show origin 显示远程库origin里的资源
git push origin master:develop
git push origin master:hb-dev 将本地库与服务器上的库进行关联
git checkout --track origin/dev 切换到远程dev分支
git branch -D master develop 删除本地库develop
git checkout -b dev 建立一个新的本地分支dev
git merge origin/dev 将分支dev与当前分支进行合并
git checkout dev 切换到本地dev分支
git remote show 查看远程库
git add .
git rm 文件名(包括路径) 从git中删除指定文件
git clone git://github.com/schacon/grit.git 从服务器上将代码给拉下来
git config --list 看所有用户
git ls-files 看已经被提交的
git rm [file name] 删除一个文件
git commit -a 提交当前repos的所有的改变
git add [file name] 添加一个文件到git index
git commit -v 当你用-v参数的时候可以看commit的差异
git commit -m “This is the message describing the commit” 添加commit信息
git commit -a -a是代表add,把所有的change加到git index里然后再commit
git commit -a -v 一般提交命令
git log 看你commit的日志
git diff 查看尚未暂存的更新
git rm a.a 移除文件(从暂存区和工作区中删除)
git rm --cached a.a 移除文件(只从暂存区中删除)
git rm -f a.a 强行移除修改后文件(从暂存区和工作区中删除)
git diff --cached 或 $ git diff --staged 查看尚未提交的更新
git stash push 将文件给push到一个临时空间中
git stash pop 将文件从临时空间pop下来