学习廖雪峰老师的git教程,本人比较懒,大部分是盗图,笔记比较乱,都是一些常用的命令。
Git的所有工作都是现在本地缓存的,只有执行git commit -m "简短说明" 后才会向服务器提交。
安装Git
Debian/Ubuntu
apt-get install git
Centos/RedHat
yum install git
Windows
Mac
git --version
查看版本
#################################################################################
Git配置
ls -a
或
ls -ah 方便查看隐藏文件
执行git config命令就是调用此文件
/etc/gitconfig 全部用户生效
--system调用的文件
~/.gitcinfig
当前用户有效
--global调用的文件
.git/config 当前项目的配置文件
.git/config的配置会覆盖
/etc/gitconfig 中的同名变量。
win中配置文件一般在主目录下的对应用户文件夹擦
C:\Documents and Settings\$USER
win中
/etc/gitconfig是在安装目录中。
#################################################################################
用户信息配置
git config --global user.name "leolan"
git config --global user.email
842632422@qq.com
用了global选项后当前用户的所有项目默认使用此用户信息,某一项目若食用其它的用户信息。把--global去掉重新配置,会在该项目.git/config中重新生成配置就行了。
git config --global core.editor emace 指定emace为默认编辑器,不指定默认为vim
#################################################################################
差异化分析工具(冲突合并)
git config --global merge.tool vimdiff
git可以理解kdiff3 ,tkdiff,meld,xxdiff,emerge,vimdiff,gvimdiff,ecmerge,opendiff等工具的输出信息。
git config --list 查看已配置的用户信息
git config user.name 查看配置的用户名,改为user.email则为邮箱,改为对应的就行。
#################################################################################
使用方法
一般进入某项目的目录后再执行以下命令。
git init 设置当前目录为Git仓库
git init 目录名 指定目录为Git仓库
git clone [源]
从源拷贝项目到本地的当前目录
git clone [源][目录] 指定源下载到某个目录
例:git clone git://github.com/schacon/grit.git mygrit
git status
查看当前目录文件的状态,加
-s 显示简短信息。
A是已添加到缓存、
M为文件有改动、
空格为未缓存的文件,组合显示如:
AM代表已缓存的文件有改动,
空格M代表未缓存的文件有改动。
git add 文件名 添加文件到项目缓存中,没有添加的文件不属于项目文件,也不会痛不到服务器。
git add . 添加当前目录到项目缓存中,如果添加多个文件,此命令更方便。
git commit -m "项目的版本或简短说明"
可以指定版本号及简单说明改动了哪些内容,同时会把所有改动同步到服务器上。
git commit -am "项目的版本或简短说明"
改动了多个文件又不想一个个添加,此命令自动添加所有改动的文件并同步到服务器。
git diff 未缓存的改动
git diff --cached 已缓存的改动
git diff HEAD
已缓存和未缓存的所有改动
git diff --stat
显示摘要而非整个diff
git reset -- HEAD 文件 取消文件已缓存的内容,
--很重要,没有加
--表示切换到另一个分支。
git rm 文件
从项目中及本地删除文件
git mv 文件
从项目中及本地重命名文件
#################################################################################
版本回退
日常使用
git status
查看当前状态
git diff
查看做了哪些修改
git add file
添加到缓存
git commit -m "xxx"
提交
git log
进入项目目录执行,可以看到所有的历史版本,信息太多加
--pretty=oneline参数简化。
首先,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
看看readme.txt的内容是不是版本
add distributed
:
$ cat readme.txtGit is a distributed version control system.Git is free software.
果然。
还可以继续回退到上一个版本
wrote a readme file
,不过且慢,然我们用
git log
再看看现在版本库的状态:
$
git log
commit ea34578d5496d7dd233c827ed32a8cd576c5ee85Author: Michael Liao <askxuefeng@gmail.com>Date: Tue Aug 20 14:53:12 2013 +0800 add distributedcommit cb926e7ea50ad11b8f9e909c05226233bf755030Author: 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可能会找到多个版本号,就无法确定是哪一个了。
Git的版本回退速度非常快,因为Git在内部有个指向当前版本的
HEAD
指针,当你回退版本的时候,Git仅仅是把HEAD从指向
append GPL
:
改为指向
add distributed
:
然后顺便把工作区的文件更新了。所以你让
HEAD
指向哪个版本号,你就把当前版本定位在哪。
你回退到了某个版本,关掉了电脑,第二天早上就后悔了,想恢复到新版本怎么办?找不到新版本的
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 GPLea34578 HEAD@{2}: commit: add distributedcb926e7 HEAD@{3}: commit (initial): wrote a readme file
终于舒了口气,第二行显示
append GPL
的
commit id
是
3628164
,现在,你又可以乘坐时光机回到未来了。
#################################################################################
管理修改
第一次修改 ->
git add
-> 第二次修改 ->
git commit
你看,我们前面讲了,Git管理的是修改,当你用
git add
命令后,在工作区的第一次修改被放入暂存区,准备提交,但是,在工作区的第二次修改并没有放入暂存区,所以,
git commit
只负责把暂存区的修改提交了,也就是第一次的修改被提交了,第二次的修改不会被提交。
提交后,用
git diff HEAD -- readme.txt
命令可以查看
工作区
和
版本库
里面最新版本的区别:
怎么提交第二次修改呢?你可以继续
git add
再
git commit
,也可以别着急提交第一次修改,先
git add
第二次修改,再
git commit
,就相当于把两次修改合并后一块提交了:
第一次修改 ->
git add
-> 第二次修改 ->
git add
->
git commit
好,现在,把第二次修改提交了。
#################################################################################
撤销修改
当发现某部分代码需要撤销时
git checkout -- file
可以丢弃工作区的修改:
$
git checkout -- readme.txt
命令
git checkout -- readme.txt
意思就是,把
readme.txt
文件在工作区的修改全部撤销,这里有两种情况:
一种是
readme.txt
自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
一种是
readme.txt
已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
总之,就是让这个文件回到最近一次
git commit
或
git add
时的状态。
第一种:
git checkout -- file(文件名)
命令中的
--
很重要,没有
--
,就变成了“切换到另一个分支”的命令,我们在后面的分支管理中会再次遇到
git
checkout
命令。
第二种:
现在假定是凌晨3点,你不但写了一些胡话,还
git add
到暂存区了:
庆幸的是,在
commit
之前,你发现了这个问题。用
git status
查看一下,修改只是添加到了暂存区,还没有提交:
Git同样告诉我们,用命令
git reset HEAD file
可以把暂存区的修改撤销掉(
unstage
),重新放回工作区:
git reset
命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用
HEAD
时,表示最新的版本。
再用
git status
查看一下,现在暂存区是干净的,工作区有修改
丢弃工作区的修改:
$
git checkout -- readme.txt
直接恢复文件并恢复版本库的内容
$
git status
# On branch master
nothing to commit (working directory clean)
git reset --hard HEAD
恢复到当前版本(git rm 后没有commit的那个版本,如果进行了commit,此次commit就是一个新版本,只能通过
git reset --hard HEAD^
回到上一个commit)
现在,假设你不但改错了东西,还从暂存区提交到了版本库,怎么办呢?还可以版本回退到上一个版本。不过,这是有条件的,就是你还没有把自己的本地版本库推送到远程,递交到远程后就没有办法咯。
注意:要完全撤回修改的代码,要git reset HEAD file 后执行git checkout -- file 才会完全包括工作区的内容也删除。
#################################################################################
删除文件
一般情况下,你通常直接在文件管理器中把没用的文件删了,或者用
rm
命令删了:
$
rm test.txt
此时文件删除了但版本库里还有记录,文件可能恢复不了。
这个时候,Git知道你删除了文件,因此,工作区和版本库就不一致了,
git status
命令会提示你哪些文件被删除了
要从版本库中删除该文件,那就用命令
git rm
删掉,并且
git commit
[git rm会同时删除版本库及文件]
另一种情况是删错了,因为版本库里还有呢,所以可以很轻松地把误删的文件恢复到最新版本:
$
git checkout -- test.txt
git checkout
其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。
提交代码的更改一共分2个阶段。
1).从工作目录,提交到
stage
。2).从
stage
提交到
master
。
从工作目录提交到
stage
,需要用
add
或者
rm
命令,只提交到
stage
,而没有提交到
master
,是不会自动同步到
master
的。
从
stage
提交到
master
用
commit
命令。
退回也是要分两步,一个是从
master
退回到
stage
,然后再从
stage
退回到工作目录。
对于还没有提交到
stage
的,可以从
stage
用
checkout
命令退回,这一步会取
stage
中的文件状态,覆盖掉工作目录中文件的状态,跟
master
完全没关系。
对于已经到达
stage
的,想把
state
中的文件状态用
master
中的覆盖掉,就用
reset
命令,这样就把
stage
中修改用
master
的状态覆盖掉了,完全跟工作目录没关系
#################################################################################
远程仓库
在继续阅读后续内容前,请自行注册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"
你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可,由于这个Key也不是用于军事目的,所以也无需设置密码。
如果一切顺利的话,可以在用户主目录里找到
.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仓库,任何人都可以看到喔(但只有你自己才能改)。所以,不要把敏感信息放进去。
ssh -T git@github.com
提示:Hi MyLeoLan! You've successfully authenticated, but GitHub does not provide shell access.
则成功添加sshkey
#################################################################################
添加远程库
首先,登陆GitHub,然后,在右上角找到“
Create a new repo
”按钮,创建一个新的仓库:
在Repository name填入
learngit
,其他保持默认设置,点击“
Create repository
”按钮,就成功地创建了一个新的Git仓库:
目前,在GitHub上的这个
learngit
仓库还是空的,GitHub告诉我们,可以从这个仓库克隆出新的仓库,也可以把一个已有的本地仓库与之关联,然后,把本地仓库的内容推送到GitHub仓库。
现在,我们根据GitHub的提示,在本地的
learngit
仓库下运行命令:
$
git remote add origin git@github.com:myleolan/learngit.git
请千万注意,把上面的
myleolan
替换成你自己的GitHub账户名,否则,你在本地关联的就是我的远程库,关联没有问题,但是你以后推送是推不上去的,因为你的SSH Key公钥不在我的账户列表中。
添加后,远程库的名字就是
origin
,这是Git默认的叫法,也可以改成别的,但是
origin
这个名字一看就知道是远程库。
错误解决:
error: src refspec master does not match any.
引起该错误的原因是,目录中没有文件,空目录是不能提交上去的 执行
git commit -m “xxx”
error: insufficient permission for adding an object to repository database ./objects
服务端没有可写目录的权限[可能不是你的库,或
sshkey不对
]
error:fatal: remote origin already exists.
解决办法:
$
git remote rm origin
error: failed to push som refs to ........
解决办法:
$
git pull origin master
//先pull 下来 再push 上去
error: failed to push some refs to 'git@github.com:myleolan/learnpython.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'Note about
fast-forwards' section of 'git push --help' for details.
解决办法:是因为远程用web创建的的库和本地不一样。
$
git pull origin master
//先pull 下来 再push 上去
解决github push错误The requested URL returned error: 403 Forbidden while accessing
# 将
[remote "origin"]
url = https://github.com/iopqrst/learn20140823.git
修改为:
[remote "origin"]
就是加上
用户名@
之后再次执行
git push
输入密码即可。
要关联(
添加
)一个远程库,使用命令
git remote add origin git@github.com:MyLeoLan/testgit.git
关联后,使用命令
git push -u origin master
第一次推送
master分支
的所有内容;
【由于远程库是空的,我们第一次推送
master分支
时,加上了
-u
参数,Git不但会把本地的
master
分支内容推送的远程新的
master
分支,还会把本地的
master
分支和远程的
master
分支关联起来,在以后的推送或者拉取时就可以简化命令。】
此后,每次本地提交后,只要有必要,就可以使用命令
git push origin master
推送最新修改;
分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在,也就是有没有联网都可以正常工作,而SVN在没有联网的时候是拒绝干活的!当有网络的时候,再把本地提交推送一下就完成了同步,真是太方便了!
当前的远程库
git remote
或
git remote -v
从远程库下载新分支和数据
git fetch origin
从远程仓库提取数据并尝试合并到当前分支
git pull origin
删除远程仓库
git remote rm [别名,仓库名]
#################################################################################
从远程库克隆
现在,假设我们从零开发,那么最好的方式是先创建远程库,然后,从远程库克隆。
首先,登陆GitHub,创建一个新的仓库,名字叫
gitskills
:
我们勾选
Initialize this repository with a README
,这样GitHub会自动为我们创建一个
README.md
文件。创建完毕后,可以看到
README.md
文件
现在,远程库已经准备好了,下一步是用命令
git clone
克隆一个本地库:
$
git clone git@github.com:michaelliao/gitskills.git
实际上,Git支持多种协议,默认的
git://
使用
ssh
,但也可以使用
https
等其他协议。
使用
https
除了速度慢以外,还有个最大的麻烦是每次推送都必须输入口令,但是在某些只开放
http
端口的公司内部就无法使用
ssh
协议而只能用
https
。
pull:本地 <-- 远程push:本地 --> 远程
本质上都是同步
commi
t
如果你本地落后远程,必然要
pull
如果你本地超前远程,必然要
push
#################################################################################
分支
创建分支可以在分支上工作而不影响
master
分支,党分支工作完成时再合并到
master
分支上。
一般流程:
先查看分支:
git branch
创建+切换分支:
git checkout -b <分支name>
等价于:
创建分支:
git branch <分支name>
+
切换分支:
git checkout <分支name>
查看当前分支:
git branch
在新建分支上进行工作,工作完成时。
切换回主分支:
git checkout master
合并某分支到当前分支(当前已切换回
master
分支了):
git merge <分支name>
删除分支:
git branch -d <分支name>
查看当前分支:
git branch
只剩
master分支
啦。
#################################################################################
解决冲突
当合并出现冲突时,一般要手动解决。
直接查看master分支的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.
<<<<<<<
HEAD
Creating
a
new
branch
is
quick
&
simple.
=
======
Creating
a
new
branch
is
quick
AND
simple.
>
>>>>>> feature1
Git用
<<<<<<<
,
=======
,
>>>>>>>
标记出不同分支的内容,
我们修改如下后保存:
Creating a
new
branch is quick
and
simple.
再提交:
$
git add readme.txt
$
git commit -m "conflict fixed"
[master
59
bc1cb] conflict fixed
用带参数的
git log
也可以看到分支的合并情况:
$
git log --graph --pretty=oneline --abbrev-commit
用
git log --graph
命令可以看到分支合并图。
#################################################################################
分支管理策略
合并分支时,如果可能,Git会用
Fast forward
模式,但这种模式下,删除分支后,会丢掉分支信息。
如果要强制禁用
Fast forward
模式,Git就会在
merge
时生成一个
新的commit
,这样,从分支历史上就可以看出分支信息。
下面我们实战一下
--no-ff
方式的
git merge
:
创建分支、修改文件,提交缓存,切换回
master分支
准备合并
dev
分支,请注意
--no-ff
参数,表示禁用
Fast forward
,因为本次合并要创建一个新的commit,所以加上
-m
参数,把commit描述写进去。
$
git merge --no-ff -m "merge with no-ff" dev
Merge made by the
'recursive'
strategy. readme.txt | 1 +
1
file changed, 1 insertion(+)
用
git log
看看分支历史:
$
git log --graph --pretty=oneline --abbrev-commit
* 7825a50 merge with no-ff|\| * 6224937 add merge|/* 59bc1cb conflict fixed...
分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,
master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在
dev
分支上,也就是说,
dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把
dev
分支合并到
master
上,在
master
分支发布1.0版本;
你和你的小伙伴们每个人都在
dev
分支上干活,每个人都有自己的分支,时不时地往
dev
分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
Git分支十分强大,在团队开发中应该充分应用。
合并分支时,加上
--no-ff
参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而
fast forward
合并就看不出来曾经做过合并。
#################################################################################
Bug分支
当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支
issue-101
来修复它,但是,等等,当前正在
dev
上进行的工作还没有提交:
$
git status
# On branch dev
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: hello.py
#
。。。。。。。。
# modified: readme.txt
#
并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复该bug,怎么办?
幸好,Git还提供了一个
stash
功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
$
git stash
Saved working directory and index state WIP on dev: 6224937 add mergeHEAD is now at 6224937 add merge
现在,用
git status
查看工作区,就是干净的(除非有没有被Git管理的文件),因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug,假定需要在
master
分支上修复,就从
master
创建临时分支:
$
git checkout master
$
git checkout -b issue-101
Switched to a new branch 'issue-101'
现在修复bug,需要把“Git is free software ...”改为“Git is a free software ...”,然后提交:
$
git add readme.txt
$
git commit -m "fix bug 101"
修复完成后,切换到
master
分支,并完成合并,最后删除
issue-101
分支:
$
git checkout master
$
git merge --no-ff -m "merged bug fix 101" issue-101
$
git branch -d issue-101
Deleted branch issue-101 (was cc17032).
太棒了,原计划两个小时的bug修复只花了5分钟!现在,是时候接着回到
dev
分支干活了!
[root@VM_163_167_centos testgit]#
git push origin master
To git@github.com:MyLeoLan/testgit.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:MyLeoLan/testgit.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'Note about
fast-forwards' section of 'git push --help' for details.
push被拒绝,此时排除了没有commit的问题之后
先
git pull --rebase origin master
再
git pull origin master
即可解决。
git pull -f origin master
强制覆盖也行,但很危险。
$
git checkout dev
Switched to branch 'dev'
$
git status
# On branch dev
nothing to commit (working directory clean)
工作区是干净的,刚才的工作现场存到哪去了?用
git stash list
命令看看:
$
git stash list
stash@{0}: WIP on dev: 6224937 add merge
工作现场还在,Git把stash内容存在某个地方了,但是需要恢复一下,有两个办法:
一是用
git stash apply
恢复,但是恢复后,
stash
内容并不删除,你需要用
git stash drop
来删除;(stash只是临时封存区,建议删除)
另一种方式是用
git stash pop
,恢复的同时把stash内容也删了
$
git stash pop
# On branch dev
。。。。。。。。
# modified: readme.txt
#
Dropped refs/stash@{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd4
0
)
再用
git stash list
查看,就看不到任何stash内容了
可以多次
stash
,恢复的时候,先用
git stash list
查看,然后恢复指定的
stash
,用命令:
$
git stash apply stash@{0}
【stash@{0}是封存的标识】
#################################################################################
Feature分支
软件开发中,总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该
feature分支
。
$
git checkout -b feature-vulcan
Switched to a new branch 'feature-vulcan'
修改代码完成之后
$
git add vulcan.py
$
git status
$
git commit -m "add feature vulcan"
切回
dev
,准备合并:
$
git checkout dev
一切顺利的话,
feature分支
和
bug分支
是类似的,合并,然后删除。
但是,
就在此时,接到上级命令,因经费不足,新功能必须取消!
虽然白干了,但是这个分支还是必须就地销毁:
$
git branch -d feature-vulcan
error: The branch 'feature-vulcan' is not fully merged.If you are sure you want to delete it, run 'git branch -D feature-vulcan'.
销毁失败。Git友情提醒,
feature-vulcan
分支还没有被合并,如果删除,将丢失掉修改,如果要强行删除,需要使用命令
git branch -D feature-vulcan
。
现在我们强行删除:
$
git branch -D feature-vulcan
Deleted branch feature-vulcan (was 756d4af).
#################################################################################
多人协作
当你从远程仓库克隆时,实际上Git自动把本地的
master
分支和远程的
master
分支对应起来了,并且,远程仓库的默认名称是
origin
。
要查看远程库的信息,用
git remote
:
$
git remote
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的地址。
抓取分支
多人协作时,大家都会往
master
和
dev
分支上推送各自的修改。
现在,模拟一个你的小伙伴,可以在另一台电脑(注意要把SSH Key添加到GitHub)或者同一台电脑的另一个目录下克隆:
$
git clone git@github.com:michaelliao/learngit.git
当你的小伙伴从远程库clone时,默认情况下,你的小伙伴只能看到本地的
master
分支。不信可以用
git branch
命令看看:
$
git branch
* master
现在,你的小伙伴要在
dev
分支上开发,
就必须创建远程
origin
的
dev
分支
到本地,于是他用这个命令创建本地
dev
分支:
$
git checkout -b dev origin/dev
【在
origin
上创建
Dev
,
-b
切换到
Dev
分支】
现在,他就可以在
dev
上继续修改,然后,时不时地把
dev
分支
push
到远程:
$
git commit -m "add /usr/bin/env"
本地已经有
dev
分支了就不用创建了,直接执行下面的命令会自动在远程服务器新建
dev
分支。
$
git push origin dev
【把本地
dev
推到远程
origin
上,会自动寻找
origin
的
Dev
分支】
多人协作时,大家都会往
master
和
dev
分支上推送各自的修改。
现在,模拟一个你的小伙伴,可以在另一台电脑(注意要把SSH Key添加到GitHub)或者同一台电脑的另一个目录下克隆:
$
git clone git@github.com:michaelliao/learngit.git
Cloning into 'learngit'...remote: Counting objects: 46, done.remote: Compressing objects: 100% (26/26), done.remote: Total 46 (delta 16), reused 45 (delta 15)Receiving objects: 100% (46/46), 15.69 KiB | 6 KiB/s, done.Resolving deltas: 100% (16/16), done.
当你的小伙伴从远程库clone时,默认情况下,你的小伙伴只能看到本地的
master
分支。不信可以用
git branch
命令看看:
$
git branch
* master
现在,你的小伙伴要在
dev
分支上开发,就必须创建远程
origin
的
dev
分支到本地,于是他用这个命令创建本地
dev
分支:
$
git checkout -b dev origin/dev
[如果本地已经有dev分支了,则pull就行]
现在,他就可以在
dev
上继续修改,然后,时不时地把
dev
分支
push
到远程:
$
git commit -m "add /usr/bin/env"
[dev 291bea8] add /usr/bin/env 1 file changed, 1 insertion(+)$
git push origin dev
你的小伙伴已经向
origin/dev
分支推送了他的提交,而碰巧你也对同样的文件作了修改,并试图推送:
$
git add hello.py
$
git commit -m "add coding: utf-8"
$
git push origin dev
To
git@github.com:michaelliao/learngit.git ! [rejected] dev -> dev (non-fast-forward)error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'hint: Updates were rejected because the tip of your current branch is behindhint: its remote counterpart. Merge the remote changes (e.g. 'git pull')hint: before pushing again.hint: See the 'Note about fast-forwards' in 'git push --help' for details.
推送失败,因为你的小伙伴的最新提交和你试图推送的提交有冲突,解决办法也很简单,Git已经提示我们,先用
git pull
把最新的提交从
origin/dev
抓下来,然后,在本地合并,解决冲突,再推送:
$
git pull
remote: Counting objects: 5, done.remote: Compressing objects: 100% (2/2), done.remote: Total 3 (delta 0), reused 3 (delta 0)Unpacking objects: 100% (3/3), done.From github.com:michaelliao/learngit fc38031..291bea8 dev -> origin/devThere 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 dev origin/<branch>
git pull
也失败了,原因是没有指定本地
dev
分支与远程
origin/dev
分支的链接,根据提示,设置
dev
和
origin/dev
的链接:
$
git branch --set-upstream dev origin/dev
【官方更改了命令
git branch --set-upstream-to=origin/dev dev
】
Branch dev
set
up
to
track remote branch dev
from
origin.
$
git commit -m "merge & fix hello.py"
$
git push origin 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
。
这就是多人协作的工作模式,一旦熟悉了,就非常简单。
F&Q
签出远程分支,出现以下错误:
fatal: Cannot update paths and switch to branch 'develop' at the same time.
解决方案
先
git fetch
再
git checkout -b develop origin/develop
因为本地还没有'develop'分支信息,需要先
fetch
或者
pull
假设有人往服务器上推送了一个新的分支,但是我不知道分支的名称是什么,我如何能获取到服务器上的分支列表呢?
- 你直接去问他
- 如果用GitHub,直接去网站看
- git ls-remote --heads origin
推送分支
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上:
$
git push origin master
如果要推送其他分支,比如
dev
,就改成:
$
git push origin dev
但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?
- master分支是主分支,因此要时刻与远程同步;
- dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;
- bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;
- feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。
总之,就是在Git中,分支完全可以在本地自己藏着玩,是否推送,视你的心情而定!
#################################################################################
标签管理
发布一个版本时,我们通常先在版本库中打一个标签(
tag
),这样,就唯一确定了打标签时刻的版本。将来无论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来。所以,标签也是版本库的一个快照。
Git的标签虽然是版本库的快照,但其实它就是指向某个
commit
的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。
Git有commit,为什么还要引入tag?
“请把上周一的那个版本打包发布,commit号是6a5819e...”
“一串乱七八糟的数字不好找!”
如果换一个办法:
“请把上周一的那个版本打包发布,版本号是v1.2”
“好的,按照tag v1.2查找commit就行!”
所以,
tag
就是一个让人容易记住的有意义的名字,它跟某个commit绑在一起。
创建标签
在Git中打标签非常简单,首先,切换到需要打标签的分支上:
$
git branch
* dev master
$
git checkout master
Switched to branch 'master'
然后,敲命令
git tag <name>
就可以打一个新标签:
$
git tag v1.0
可以用命令
git tag
查看所有标签:
$
git tag
v1.0
默认标签是打在最新提交的commit上的。有时候,如果忘了打标签,比如,现在已经是周五了,但应该在周一打的标签没有打,怎么办?
方法是找到历史提交的
commit id
,然后打上就可以了:
$
git log --pretty=oneline --abbrev-commit
6a5819e merged bug fix 101cc17032 fix bug 1017825a50 merge with no-ff6224937 add merge59bc1cb conflict fixed400b400 & simple75a857c AND simplefec145a branch testd17efd8 remove test.txt...
比方说要对
add merge
这次提交打标签,它对应的
commit id
是
6224937
,敲入命令:
$
git tag v0.9 6224937
再用命令
git tag
查看标签:
$
git tag
v0.9v1.0
注意,标签不是按时间顺序列出,而是按字母排序的。可以用
git show <tagname>
查看标签信息:
$
git show v0.9
commit 622493706ab447b6bb37e4e2a2f276a20fed2ab4Author: Michael Liao <askxuefeng@gmail.com>Date: Thu Aug 22 11:22:08 2013 +0800 add merge...
可以看到,
v0.9
确实打在
add merge
这次提交上。
还可以创建带有说明的标签,用
-a
指定标签名,
-m
指定说明文字:
$
git tag -a v0.1 -m "version 0.1 released" 3628164
用命令
git show <tagname>
可以看到说明文字:
$
git show v0.1
tag v0.1Tagger: Michael Liao <askxuefeng@gmail.com>Date: Mon Aug 26 07:28:11 2013 +0800version 0.1 releasedcommit 3628164fb26d48395383f8f31179f24e0882e1e0Author: Michael Liao <askxuefeng@gmail.com>Date: Tue Aug 20 15:11:49 2013 +0800 append GPL
还可以通过
-s
用私钥签名一个标签:
$
git tag -s v0.2 -m "signed version 0.2 released" fec145a
签名采用PGP签名,因此,必须首先安装
gpg(GnuPG)
,如果没有找到gpg,或者没有gpg密钥对,就会报错:
gpg: signing failed: secret key not availableerror: gpg failed to sign the dataerror: unable to sign the tag
如果报错,请参考GnuPG帮助文档配置Key。
如果签名不成功可以加-u 参数,详见:
http://airk000.github.io/git/2013/09/30/git-tag-with-gpg-key
用命令
git show <tagname>
可以看到PGP签名信息:
$
git show v0.2
tag v0.2Tagger: Michael Liao <askxuefeng@gmail.com>Date: Mon Aug 26 07:28:33 2013 +0800signed version 0.2 released-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.4.12 (Darwin)iQEcBAABAgAGBQJSGpMhAAoJEPUxHyDAhBpT4QQIAKeHfR3bo...-----END PGP SIGNATURE-----commit fec145accd63cdc9ed95a2f557ea0658a2a6537fAuthor: Michael Liao <askxuefeng@gmail.com>Date: Thu Aug 22 10:37:30 2013 +0800 branch test
用PGP签名的标签是不可伪造的,因为可以验证
PGP
签名。验证签名的方法比较复杂,这里就不介绍了。
- 命令git tag <name>用于新建一个标签,默认为HEAD,也可以指定一个commit id;
- git tag -a <tagname> -m "blablabla..."可以指定标签信息;
- git tag -s <tagname> -m "blablabla..."可以用PGP签名标签;
- 命令git tag可以查看所有标签。
操作标签
- 命令git tag -d <tagname>可以删除一个本地标签;
- 命令git push origin <tagname>可以推送一个本地标签;
- 命令git push origin --tags可以推送全部未推送过的本地标签;
- 先删除本地对应的标签,再运行命令git push origin :refs/tags/<tagname>删除一个远程标签。
#################################################################################
使用GitHub
如何参与一个开源项目呢?比如人气极高的bootstrap项目,这是一个非常强大的CSS框架,你可以访问它的项目主页
https://github.com/twbs/bootstrap
,
点“
Fork
”就在自己的账号下克隆了一个bootstrap仓库
,然后,从自己的账号下clone:
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/michaelliao/learngit
,创建一个
your-github-id.txt
的文本文件,写点自己学习Git的心得,然后推送一个pull request给我,我会视心情而定是否接受。
#################################################################################
自定义Git
我们已经配置了
user.name
和
user.email
,实际上,Git还有很多可配置项。
比如,让Git显示颜色,会让命令输出看起来更醒目:
$
git config --global color.ui true
忽略特殊文件
有些时候,你必须把某些文件放到Git工作目录中,但又不能提交它们,比如保存了数据库密码的配置文件啦,等等,每次
git status
都会显示
Untracked files ...
,有强迫症的童鞋心里肯定不爽。
好在Git考虑到了大家的感受,这个问题解决起来也很简单,在Git工作区的根目录下创建一个特殊的
.gitignore
文件,然后把要忽略的文件名填进去,Git就会自动忽略这些文件。
不需要从头写
.gitignore
文件,GitHub已经为我们准备了各种配置文件,只需要组合一下就可以使用了。所有配置文件可以直接在线浏览:
https://github.com/github/gitignore
已经配置好了要忽略的文件,下载回来要文件名要改为
.gitignore
忽略文件的原则是:
- 忽略操作系统自动生成的文件,比如缩略图等;
- 忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的.class文件;
- 忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件。
举个例子:
假设你在Windows下进行Python开发,Windows会自动在有图片的目录下生成隐藏的缩略图文件,如果有自定义目录,目录下就会有
Desktop.ini
文件,因此你需要忽略Windows自动生成的垃圾文件:
然后,继续忽略Python编译产生的
.pyc、.pyo、dist
等文件或目录:
加上你自己定义的文件,最终得到一个完整的
.gitignore
文件,内容如下:
# Windows:
Thumbs.dbehthumbs.dbDesktop.ini
# Python:
*.py[cod]*.so*.egg*.egg-infodistbuild
# My configurations:
db.inideploy_key_rsa
最后一步就是把
.gitignore
也提交到Git,就完成了!当然检验
.gitignore
的标准是
git status
命令是不是说
working directory clean
。
使用Windows的童鞋注意了,如果你在资源管理器里新建一个
.gitignore
文件,它会非常弱智地提示你必须输入文件名,但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为
.gitignore
了。
有些时候,你想添加一个文件到Git,但发现添加不了,原因是这个文件被
.gitignore
忽略了:
$
git add App.class
The following paths are ignored by one of your .gitignore files:App.classUse -f if you really want to add them.
如果你确实想添加该文件,可以用
-f
强制添加到Git:
$
git add -f App.class
或者你发现,可能是
.gitignore
写得有问题,需要找出来到底哪个规则写错了,可以用
git check-ignore
命令检查:
$
git check-ignore -v App.class
.gitignore:3:*.class App.class
Git会告诉我们,
.gitignore
的第3行规则忽略了该文件,于是我们就可以知道应该修订哪个规则。
小结
- 忽略某些文件时,需要编写.gitignore;
- .gitignore文件本身要放到版本库里,并且可以对.gitignore做版本管理!
配置别名
有没有经常敲错命令?比如
git status
?
status
这个单词真心不好记。
如果敲
git st
就表示
git status
那就简单多了,当然这种偷懒的办法我们是极力赞成的。
我们只需要敲一行命令,告诉Git,以后
st
就表示
status
:
$
git config --global alias.st status
好了,现在敲
git st
看看效果。
当然还有别的命令可以简写,很多人都用
co
表示
checkout
,
ci
表示
commit
,
br
表示
branch
:
$
git config --global alias.co checkout
$
git config --global alias.ci commit
$
git config --global alias.br branch
以后提交就可以简写成:
$
git ci -m "bala bala bala..."
--global
参数是全局参数,也就是这些命令在这台电脑的所有Git仓库下都有用。
在
撤销修改
一节中,我们知道,命令
git reset HEAD file
可以把暂存区的修改撤销掉(
unstage
),重新放回工作区。既然是一个unstage操作,就可以配置一个
unstage
别名:
$
git config --global alias.unstage 'reset HEAD'
当你敲入命令:
$
git unstage test.py
实际上Git执行的是:
$
git reset HEAD test.py
配置一个
git last
,让其显示最后一次提交信息:
$
git config --global alias.last 'log -1'
数字代表最近的几次提交
这样,用
git last
就能显示最近一次的提交:
$
git last
commit adca45d317e6d8a4b23f9811c3d7b7f0f180bfe2Merge: bd6ae48 291bea8Author: Michael Liao <askxuefeng@gmail.com>Date: Thu Aug 22 22:49:22 2013 +0800 merge & fix hello.py
甚至还有人丧心病狂地把
lg
配置成了:
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
来看看
git lg
的效果:
为什么不早点告诉我?别激动,咱不是为了多记几个英文单词嘛!
配置文件
配置Git的时候,加上
--global
是针对当前用户起作用的,如果不加,那只针对当前的仓库起作用。
配置文件放哪了?每个仓库的Git配置文件都放在
.git/config
文件中:
$
cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true precomposeunicode = true[remote "origin"] url = git@github.com:michaelliao/learngit.git fetch = +refs/heads/*:refs/remotes/origin/*[branch "master"] remote = origin merge = refs/heads/master
[
alias
] last = log -1
别名就在
[alias]
后面,要删除别名,直接把对应的行删掉即可。
而当前用户的Git配置文件放在用户主目录下的一个隐藏文件
.gitconfig
中:
$
cat .gitconfig
[
alias
] co = checkout ci = commit br = branch st = status[user] name = Your Name email = your@email.com
配置别名也可以直接修改这个文件,如果改错了,可以删掉文件重新通过命令配置。
#################################################################################
搭建Git服务器
GitHub就是一个免费托管开源代码的远程仓库。但是对于某些视源代码如生命的商业公司来说,既不想公开源代码,又舍不得给GitHub交保护费,那就只能自己搭建一台Git服务器作为私有仓库使用。
搭建Git服务器需要准备一台运行Linux的机器,强烈推荐用Ubuntu或Debian,这样,通过几条简单的
apt
命令就可以完成安装。
假设你已经有
sudo
权限的用户账号,下面,正式开始安装。
第一步,安装
git
:
$
sudo apt-get install git
或
yum install git
第二步,创建一个
git
用户,用来运行
git
服务:
$
sudo adduser git
第三步,初始化Git仓库:
先选定一个目录作为Git仓库,假定是
/data/git/learngit.git
,在
/data/git/
目录下输入命令:
$
sudo git init --bare learngit.git
Git就会创建一个裸仓库,裸仓库没有工作区,因为服务器上的Git仓库纯粹是为了共享,所以不让用户直接登录到服务器上去改工作区,并且服务器上的Git仓库通常都以
.git
结尾。
$
sudo chown -R git:git learngit.git
Git服务器就已经搭得差不多了。下面我们在客户端clone一下远程仓库$
git clone git@192.168.199.206:/data/git/learngit.git
Cloning into 'learngit'...The authenticity of host '192.168.8.34 (192.168.8.34)' can't be established.RSA key fingerprint is 2b:55:45:e7:4c:29:cc:05:33:78:03:bd:a8:cd:08:9d.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added '192.168.8.34' (RSA) to the list of known hosts.git@192.168.8.34's password:
能连接但要密码,接着下一步。
第四步,创建证书登录(Git服务器打开RSA认证):
然后就可以去Git服务器上添加你的公钥用来验证你的信息了。
vim /etc/ssh/sshd_config
中将RSA认证打开,即:
RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys
这里我们可以看到公钥存放在
.ssh/authorized_keys
文件中。所以我们在
/home/git
下创建
.ssh
目录,然后创建
authorized_keys
文件,收集所有需要登录的用户的公钥,就是他们自己的
id_rsa.pub
文件,把所有公钥导入到
/home/git/.ssh/authorized_keys
文件里,一行一个。
此时$
git clone git@192.168.199.206:/data/git/learngit.git
已经可以免密钥登录啦。
第五步,禁用shell登录:
出于安全考虑,第二步创建的git用户不允许登录shell,这可以通过编辑
/etc/passwd
文件完成。找到类似下面的一行:
git:x:
1001
:
1001
:
,,,
:/home/git:
/bin/bash
改为:
git:x:
1001
:
1001
:
,,,
:/home/git:
/usr/bin/git-shell
这样,
git
用户可以正常通过ssh使用git,但无法登录shell,因为我们为
git
用户指定的
git-shell
每次一登录就自动退出。
第六步,克隆远程仓库:
现在,可以通过
git clone
命令克隆远程仓库了,在各自的电脑上运行:
$
git clone git@192.168.199.206:/data/git/learngit.git
Cloning into 'sample'...warning: You appear to have cloned an empty repository.
剩下的推送就简单了。
管理公钥
如果团队很小,把每个人的公钥收集起来放到服务器的
/home/git/.ssh/authorized_keys
文件里就是可行的。如果团队有几百号人,就没法这么玩了,这时,可以用
Gitosis
来管理公钥。
管理权限
有很多不但视源代码如生命,而且视员工为窃贼的公司,会在版本控制系统里设置一套完善的权限控制,每个人是否有读写权限会精确到每个分支甚至每个目录下。因为Git是为Linux源代码托管而开发的,所以Git也继承了开源社区的精神,不支持权限控制。不过,因为Git支持钩子(hook),所以,可以在服务器端编写一系列脚本来控制提交等操作,达到权限控制的目的。
Gitolite
就是这个工具。
搭建服务器的同时采用Gitolite来管理权限,参考:
https://my.oschina.net/u/2351685/blog/509322
Gitolite的使用,参考:
http://www.uml.org.cn/pzgl/201404092.asp
#################################################################################
完结!
外国友人git手册
10 个迅速提升你 Git 水平的提示
个人学习笔记,不当之处还请指正。
----------不定期更新------------
----------不定期更新------------