git [转自廖雪峰]
1.git的诞生
Git是目前世界上最先进的分布式版本控制系统(没有之一)。
很多人都知道,Linus在1991年创建了开源的Linux,从此,Linux系统不断发展,已经成为最大的服务器系统软件了。
Linus虽然创建了Linux,但Linux的壮大是靠全世界热心的志愿者参与的,这么多人在世界各地为Linux编写代码,那Linux的代码是如何管理的呢?
事实是,在2002年以前,世界各地的志愿者把源代码文件通过diff的方式发给Linus,然后由Linus本人通过手工方式合并代码!
你也许会想,为什么Linus不把Linux代码放到版本控制系统里呢?不是有CVS、SVN这些免费的版本控制系统吗?因为Linus坚定地反对CVS和SVN,这些集中式的版本控制系统不但速度慢,而且必须联网才能使用。有一些商用的版本控制系统,虽然比CVS、SVN好用,但那是付费的,和Linux的开源精神不符。
不过,到了2002年,Linux系统已经发展了十年了,代码库之大让Linus很难继续通过手工方式管理了,社区的弟兄们也对这种方式表达了强烈不满,于是Linus选择了一个商业的版本控制系统BitKeeper,BitKeeper的东家BitMover公司出于人道主义精神,授权Linux社区免费使用这个版本控制系统。
安定团结的大好局面在2005年就被打破了,原因是Linux社区牛人聚集,不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议(这么干的其实也不只他一个),被BitMover公司发现了(监控工作做得不错!),于是BitMover公司怒了,要收回Linux社区的免费使用权。
Linus可以向BitMover公司道个歉,保证以后严格管教弟兄们,嗯,这是不可能的。实际情况是这样的:
Linus花了两周时间自己用C写了一个分布式版本控制系统,这就是Git!一个月之内,Linux系统的源码已经由Git管理了!牛是怎么定义的呢?大家可以体会一下。
Git迅速成为最流行的分布式版本控制系统,尤其是2008年,GitHub网站上线了,它为开源项目免费提供Git存储,无数开源项目开始迁移至GitHub,包括jQuery,PHP,Ruby等等。
历史就是这么偶然,如果不是当年BitMover公司威胁Linux社区,可能现在我们就没有免费而超级好用的Git了。
2.git安装
debian或Ubuntu linux
sudo apt-get install git
其他版本linux
可以直接通过源码安装。先从Git官网下载源码,然后解压,依次输入:./config
,make
,sudo make install
这几个命令安装就好了。
mac
-
安装homebrew,然后通过homebrew安装Git,具体方法请参考homebrew的文档:http://brew.sh/。
-
第二种方法更简单,也是推荐的方法,就是直接从AppStore安装Xcode,Xcode集成了Git,不过默认没有安装,你需要运行Xcode,选择菜单“Xcode”->“Preferences”,在弹出窗口中找到“Downloads”,选择“Command Line Tools”,点“Install”就可以完成安装了。
windows
可以从Git官网直接下载安装程序,然后按默认选项安装即可。
安装完成后,在开始菜单里找到“Git”->“Git Bash”,蹦出一个类似命令行窗口的东西,就说明Git安装成功!
3.git设置
设置用户名和邮箱
安装完成后,还需要最后一步设置,在命令行输入:
$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"
因为Git是分布式版本控制系统,所以,每个机器都必须自报家门:你的名字和Email地址。
注意git config
命令的--global
参数,用了这个参数,表示你这台机器上所有的Git仓库都会使用这个配置,当然也可以对某个仓库指定不同的用户名和Email地址。
自定义git
- 让Git显示颜色,会让命令输出看起来更醒目:
$ git config --global color.ui true
忽略特殊文件
不需要从头写.gitignore
文件,GitHub已经为我们准备了各种配置文件,只需要组合一下就可以使用了。所有配置文件可以直接在线浏览:https://github.com/github/gitignore
忽略文件的原则是:
- 忽略操作系统自动生成的文件,比如缩略图等;
- 忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的
.class
文件; - 忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件。
举个例子:
假设你在Windows下进行Python开发,Windows会自动在有图片的目录下生成隐藏的缩略图文件,如果有自定义目录,目录下就会有Desktop.ini
文件,因此你需要忽略Windows自动生成的垃圾文件:
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini
然后,继续忽略Python编译产生的.pyc
、.pyo
、dist
等文件或目录:
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build
加上你自己定义的文件,最终得到一个完整的.gitignore
文件,内容如下:
# 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
忽略了:
$ 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:
$ git add -f App.class
或者你发现,可能是.gitignore
写得有问题,需要找出来到底哪个规则写错了,可以用git check-ignore
命令检查:
$ git check-ignore -v App.class
.gitignore:3:*.class App.class
Git会告诉我们,.gitignore
的第3行规则忽略了该文件,于是我们就可以知道应该修订哪个规则。
还有些时候,当我们编写了规则排除了部分文件时:
# 排除所有.开头的隐藏文件:
.*
# 排除所有.class文件:
*.class
但是我们发现.*
这个规则把.gitignore
也排除了,并且App.class
需要被添加到版本库,但是被*.class
规则排除了。
虽然可以用git add -f
强制添加进去,但有强迫症的童鞋还是希望不要破坏.gitignore
规则,这个时候,可以添加两条例外规则:
# 排除所有.开头的隐藏文件:
.*
# 排除所有.class文件:
*.class
# 不排除.gitignore和App.class:
!.gitignore
!App.class
把指定文件排除在.gitignore
规则外的写法就是!
+文件名,所以,只需把例外文件添加进去即可。
配置别名
git st
表示status
:git config --global alias.st status
当然还有别的命令可以简写,很多人都用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 adca45d317e6d8a4b23f9811c3d7b7f0f180bfe2
Merge: bd6ae48 291bea8
Author: 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服务器
在远程仓库一节中,我们讲了远程仓库实际上和本地仓库没啥不同,纯粹为了7x24小时开机并交换大家的修改。
GitHub就是一个免费托管开源代码的远程仓库。但是对于某些视源代码如生命的商业公司来说,既不想公开源代码,又舍不得给GitHub交保护费,那就只能自己搭建一台Git服务器作为私有仓库使用。
搭建Git服务器需要准备一台运行Linux的机器,强烈推荐用Ubuntu或Debian,这样,通过几条简单的apt
命令就可以完成安装。
假设你已经有sudo
权限的用户账号,下面,正式开始安装。
第一步,安装git
:
$ sudo apt-get install git
第二步,创建一个git
用户,用来运行git
服务:
$ sudo adduser git
第三步,创建证书登录:
收集所有需要登录的用户的公钥,就是他们自己的id_rsa.pub
文件,把所有公钥导入到/home/git/.ssh/authorized_keys
文件里,一行一个。
第四步,初始化Git仓库:
先选定一个目录作为Git仓库,假定是/srv/sample.git
,在/srv
目录下输入命令:
$ sudo git init --bare sample.git
Git就会创建一个裸仓库,裸仓库没有工作区,因为服务器上的Git仓库纯粹是为了共享,所以不让用户直接登录到服务器上去改工作区,并且服务器上的Git仓库通常都以.git
结尾。然后,把owner改为git
:
$ sudo chown -R git:git sample.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@server:/srv/sample.git
Cloning into 'sample'...
warning: You appear to have cloned an empty repository.
剩下的推送就简单了。
管理公钥
如果团队很小,把每个人的公钥收集起来放到服务器的/home/git/.ssh/authorized_keys
文件里就是可行的。如果团队有几百号人,就没法这么玩了,这时,可以用Gitosis来管理公钥。
这里我们不介绍怎么玩Gitosis了,几百号人的团队基本都在500强了,相信找个高水平的Linux管理员问题不大。
管理权限
有很多不但视源代码如生命,而且视员工为窃贼的公司,会在版本控制系统里设置一套完善的权限控制,每个人是否有读写权限会精确到每个分支甚至每个目录下。因为Git是为Linux源代码托管而开发的,所以Git也继承了开源社区的精神,不支持权限控制。不过,因为Git支持钩子(hook),所以,可以在服务器端编写一系列脚本来控制提交等操作,达到权限控制的目的。Gitolite就是这个工具。
这里我们也不介绍Gitolite了,不要把有限的生命浪费到权限斗争中。
小结
4.创建版本库
- 创建一个空目录
- 通过
git init
命令把这个目录变成Git可以管理的仓库:
5.管理版本库文件
添加文件给git管理:
- 第一步,用命令
git add
告诉Git,把文件添加到仓库(暂存区):git add readme.txt
- 第二步,用命令
git commit
告诉Git,把文件提交到仓库(当前分支):git commit -m "提交readme文件"
可以多次add,一次commit:可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。
查看仓库当前状态:
git status
取消暂存(git add后后悔了):
git restore --staged aa.txt
查看修改的内容:
git diff readme.txt
查看工作区和版本库里面最新版本的区别:
git diff HEAD -- readme.txt
查看历史记录:
git log
,
简洁显示: git log --pretty=oneline
显示分支合并情况: git log --graph --pretty=oneline --abbrev-commit
还原到上一版本(git commit后后悔了):
git reset --hard HEAD^
,如果后悔想恢复到最新版本,只要可以找到最新版本的commit id,就可以还原到指定版本:git reset --hard 19092a
(版本号没必要写全,前几位就可以了,Git会自动去找。当然也不能只写前一两位,因为Git可能会找到多个版本号,就无法确定是哪一个了。)
找到指定版本的commit id:
Git提供了一个命令git reflog
用来记录你的每一次命令
丢弃工作区的修改:
git checkout
其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。
git checkout -- readme.txt
.这里有两种情况:
-
一种是
readme.txt
自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态; -
一种是
readme.txt
已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
总之,就是让这个文件回到最近一次git commit
或git add
时的状态。
丢弃暂存区的修改,重新放回工作区:
git reset HEAD readme.txt
删除文件
git rm readme.txt
,然后commit
恢复误删的工作区文件
git checkout
其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。
git checkout -- readme.txt
场景练习
-
场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令
git checkout -- file
。 -
场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令
git reset HEAD <file>
,就回到了场景1,第二步按场景1操作。 -
场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交:
git reset --hard HEAD^
,不过前提是没有推送到远程库。
6.配置Github
第1步:在用户主目录下,创建SSH Key。
$ ssh-keygen -t rsa -C "youremail@example.com"
,一路回车,无需密码.
boguotong@boguotong .ssh % pwd
/Users/boguotong/.ssh
boguotong@boguotong .ssh % ls
config id_rsa id_rsa.pub known_hosts
boguotong@boguotong .ssh %
第2步:登陆GitHub,打开“Account settings”,“SSH Keys”页面:
然后,点“Add SSH Key”,填上任意Title,在Key文本框里粘贴id_rsa.pub
文件的内容:
点“Add Key”,你就应该看到已经添加的Key:
友情提示,在GitHub上免费托管的Git仓库,任何人都可以看到喔(但只有你自己才能改)。所以,不要把敏感信息放进去。
如果你不想让别人看到Git库,有两个办法,一个是交点保护费,让GitHub把公开的仓库变成私有的,这样别人就看不见了(不可读更不可写)。另一个办法是自己动手,搭一个Git服务器,因为是你自己的Git服务器,所以别人也是看不见的。这个方法我们后面会讲到的,相当简单,公司内部开发必备。
7.远程仓库
添加远程仓库
-
在github创建一个仓库,例如名为:learngit
-
在本地learngit仓库下运行命令:
git remote add origin git@github.com:yourgithubaccount/learngit.git
,远程仓库的名字就是origin,是git默认叫法,可改成别的.但是
origin
这个名字一看就知道是远程库。 -
推送本地所有内容到远程库
git push -u origin master
把本地库的内容推送到远程,用
git push
命令,实际上是把当前分支master
推送到远程。由于远程库是空的,我们第一次推送
master
分支时,加上了-u
参数,Git不但会把本地的master
分支内容推送的远程新的master
分支,还会把本地的master
分支和远程的master
分支关联起来,在以后的推送或者拉取时就可以简化命令:git push origin master
。
SSH警告
当你第一次使用Git的clone
或者push
命令连接GitHub时,会得到一个警告:
The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?
这是因为Git使用SSH连接,而SSH连接在第一次验证GitHub服务器的Key时,需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器,输入yes
回车即可。
Git会输出一个警告,告诉你已经把GitHub的Key添加到本机的一个信任列表里了:
Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
这个警告只会出现一次,后面的操作就不会有任何警告了。
如果你实在担心有人冒充GitHub服务器,输入yes
前可以对照GitHub的RSA Key的指纹信息是否与SSH连接给出的一致。
删除远程库
如果添加的时候地址写错了,或者就是想删除远程库,可以用git remote rm <name>
命令。使用前,建议先用git remote -v
查看远程库信息:
$ git remote -v
origin git@github.com:michaelliao/learn-git.git (fetch)
origin git@github.com:michaelliao/learn-git.git (push)
然后,根据名字删除,比如删除origin
:
$ git remote rm origin
此处的“删除”其实是解除了本地和远程的绑定关系,并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库,需要登录到GitHub,在后台页面找到删除按钮再删除。
查看远程库
git remote
显示更详细信息:git remote -v
$ git remote -v
origin git@github.com:michaelliao/learngit.git (fetch)
origin git@github.com:michaelliao/learngit.git (push)
上面显示了可以抓取和推送的origin
的地址。如果没有推送权限,就看不到push的地址。
8.分支管理
创建并切换分支
git checkout -b dev
git checkout
命令加上-b
参数表示创建并切换,相当于以下两条命令:
$ git branch dev
$ git checkout dev
Switched to branch 'dev'
switch
我们注意到切换分支使用git checkout <branch>
,而前面讲过的撤销修改则是git checkout -- <file>
,同一个命令,有两种作用,确实有点令人迷惑。
实际上,切换分支这个动作,用switch
更科学。因此,最新版本的Git提供了新的git switch
命令来切换分支:
创建并切换到新的dev
分支,可以使用:
$ git switch -c dev
直接切换到已有的master
分支,可以使用:
$ git switch master
查看当前分支
git branch
git branch
命令会列出所有分支,当前分支前面会标一个*
号。
合并分支
git merge dev
git merge
命令用于合并指定分支到当前分支
合并操作( merge )只对对当前所在分支产生影响;无论是否存在冲突,合并之后,dev分支都不会发生变化。
分支管理策略
通常,合并分支时,如果可能,Git会用Fast forward
模式,但这种模式下,删除分支后,会丢掉分支信息(合并看不出来曾经做过合并)。
如果要强制禁用Fast forward
模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
git merge --no-ff -m "不使用快速合并模式的合并" dev
因为本次合并要创建一个新的commit,所以加上-m
参数,把commit描述写进去。
合并后,我们用git log --graph --pretty=oneline --abbrev-commit
看看分支历史:可以看到分支合并记录:
$ git log --graph --pretty=oneline --abbrev-commit
* e1e9c68 (HEAD -> master) merge with no-ff
|\
| * f52c633 (dev) add merge
|/
* cf810e4 conflict fixed
...
删除分支
git branch -d dev
如果删除分支时,分支未被合并会提示删除失败,强行删除: git branch -D dev
解决冲突
分支合并时出现冲突,git无法执行"快速合并",需要手动修改冲突后再重新提交(git add,git commit -m 'resolve conflict')
bug分支场景
-
当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支
issue-101
来修复它,但是,等等,当前正在dev
上进行的工作还没有提交: -
把当前工作现场“储藏”起来,等以后恢复现场后继续工作:
git stash
.现在,用git status
查看工作区,就是干净的(除非有没有被Git管理的文件),因此可以放心地创建分支来修复bug。 -
首先确定要在哪个分支上修复bug,假定需要在
master
分支上修复,就从master
创建临时分支:git checkout master
切换到master分支,然后在此基础上创建bug分支:git checkout b issue-101
-
修复完bug,把修改文件add和commit后,切换到master分支
git checkout master
,合并分支git merge --no-ff -m "fix bug" issue-101
-
删除bug分支
git branch -d issue-101
-
切换到dev分支继续干活
git checkout dev
,查看之前暂存记录git stash list
,恢复暂存有2个办法:一是用
git stash apply
恢复,但是恢复后,stash内容并不删除,你需要用git stash drop
来删除;另一种方式是用
git stash pop
,恢复的同时把stash内容也删了:你可以多次stash,恢复的时候,先用
git stash list
查看,然后恢复指定的stash,用命令:$ git stash apply stash@{0}
-
在master分支上修复了bug后,我们要想一想,dev分支是早期从master分支分出来的,所以,这个bug其实在当前dev分支上也存在。
那怎么在dev分支上修复同样的bug?重复操作一次,提交不就行了?
有木有更简单的方法?
有!
同样的bug,要在dev上修复,我们只需要把
4c805e2 fix bug 101
这个提交所做的修改“复制”到dev分支。注意:我们只想复制4c805e2 fix bug 101
这个提交所做的修改,并不是把整个master分支merge过来。为了方便操作,Git专门提供了一个
cherry-pick
命令,让我们能复制一个特定的提交到当前分支:$ git branch * dev master $ git cherry-pick 4c805e2 [master 1d4b803] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)
Git自动给dev分支做了一次提交,注意这次提交的commit是
1d4b803
,它并不同于master的4c805e2
,因为这两个commit只是改动相同,但确实是两个不同的commit。用git cherry-pick
,我们就不需要在dev分支上手动再把修bug的过程重复一遍。有些聪明的童鞋会想了,既然可以在master分支上修复bug后,在dev分支上可以“重放”这个修复过程,那么直接在dev分支上修复bug,然后在master分支上“重放”行不行?当然可以,不过你仍然需要
git stash
命令保存现场,才能从dev分支切换到master分支。
推送分支到远程库
推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上:git push origin master
如果要推送其他分支,比如dev
,就改成: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-to <branch-name> origin/<branch-name>
建立连接后,之后再推送或拉取就可以只写git pull
或git push
而不用指定分支名了.
rebase
变基
9.标签管理
发布一个版本时,我们通常先在版本库中打一个标签(tag),这样,就唯一确定了打标签时刻的版本。将来无论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来。所以,标签也是版本库的一个快照。
Git的标签虽然是版本库的快照,但其实它就是指向某个commit的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。
Git有commit,为什么还要引入tag?tag就是一个让人容易记住的有意义的名字,它跟某个commit绑在一起
创建标签
-
切换到需要打标签的分支上 :
git checkout master
,执行命令:git tag v1.2
-
命令
git tag -a <tagname> -m "blablabla..."
可以指定标签信息; -
默认标签是打在最新提交的commit上的。有时候,如果忘了打标签,比如,现在已经是周五了,但应该在周一打的标签没有打,怎么办?
方法是找到历史提交的commit id:
git log --pretty=oneline --abbrev-commit
,然后打上就可以了:比方说要对add merge
这次提交打标签,它对应的commit id是f52c633
,敲入命令:git tag v0.9 f52c633
查看标签
注意,标签不是按时间顺序列出,而是按字母排序的。
查看全部标签:git tag
查看标签信息(查看标签日期及打在哪个commit上): git show <tagname>
删除标签
因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地安全删除。
git tag -d <tagname>
如果标签已经推送到远程,要删除远程标签就麻烦一点
- 先从本地删除:
git tag -d v1.0
- 然后,从远程删除。删除命令也是push,但是格式如下:`git push origin :refs/tags/v0.9``
推送标签到远程
git push origin <tagname>
或者,一次性推送全部尚未推送到远程的本地标签:git push origin --tags
10.使用Gitee
基本使用
使用Gitee和使用GitHub类似,
注册账号并登录,上传自己的SSH公钥:选择右上角用户头像 -> 菜单“修改资料”,然后选择“SSH公钥”,填写一个便于识别的标题,然后把用户主目录下的.ssh/id_rsa.pub
文件的内容粘贴进去,点击“确定”即可.
如果我们已经有了一个本地的git仓库(例如,一个名为learngit的本地库),如何把它关联到Gitee的远程库上呢?
-
首先,我们在Gitee上创建一个新的项目,选择右上角用户头像 -> 菜单“控制面板”,然后点击“创建项目”:
项目名称最好与本地库保持一致:
-
然后,我们在本地库上使用命令
git remote add
把它和Gitee的远程库关联:
git remote add origin git@gitee.com:liaoxuefeng/learngit.git
- 之后,就可以正常地用
git push
和git pull
推送了!
如果在使用命令git remote add
时报错:
git remote add origin git@gitee.com:liaoxuefeng/learngit.git
fatal: remote origin already exists.
这说明本地库已经关联了一个名叫origin
的远程库,此时,可以先用git remote -v
查看远程库信息:
git remote -v
origin git@github.com:michaelliao/learngit.git (fetch)
origin git@github.com:michaelliao/learngit.git (push)
可以看到,本地库已经关联了origin
的远程库,并且,该远程库指向GitHub。
我们可以删除已有的GitHub远程库:
git remote rm origin
再关联Gitee的远程库(注意路径中需要填写正确的用户名):
git remote add origin git@gitee.com:liaoxuefeng/learngit.git
此时,我们再查看远程库信息:
git remote -v
origin git@gitee.com:liaoxuefeng/learngit.git (fetch)
origin git@gitee.com:liaoxuefeng/learngit.git (push)
现在可以看到,origin已经被关联到Gitee的远程库了。通过git push
命令就可以把本地库推送到Gitee上。
一个本地库能不能既关联GitHub,又关联Gitee呢?
答案是肯定的,因为git本身是分布式版本控制系统,可以同步到另外一个远程库,当然也可以同步到另外两个远程库。
使用多个远程库时,我们要注意,git给远程库起的默认名称是origin
,如果有多个远程库,我们需要用不同的名称来标识不同的远程库。
仍然以learngit
本地库为例,我们先删除已关联的名为origin
的远程库:
git remote rm origin
然后,先关联GitHub的远程库:
git remote add github git@github.com:michaelliao/learngit.git
注意,远程库的名称叫github
,不叫origin
了。
接着,再关联Gitee的远程库:
git remote add gitee git@gitee.com:liaoxuefeng/learngit.git
同样注意,远程库的名称叫gitee
,不叫origin
。
现在,我们用git remote -v
查看远程库信息,可以看到两个远程库:
git remote -v
gitee git@gitee.com:liaoxuefeng/learngit.git (fetch)
gitee git@gitee.com:liaoxuefeng/learngit.git (push)
github git@github.com:michaelliao/learngit.git (fetch)
github git@github.com:michaelliao/learngit.git (push)
如果要推送到GitHub,使用命令:
git push github master
如果要推送到Gitee,使用命令:
git push gitee master
这样一来,我们的本地库就可以同时与多个远程库互相同步:
┌─────────┐ ┌─────────┐
│ GitHub │ │ Gitee │
└─────────┘ └─────────┘
▲ ▲
└─────┬─────┘
│
┌─────────────┐
│ Local Repo │
└─────────────┘
11.使用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
,以及你自己克隆到本地电脑的仓库,他们的关系就像下图显示的那样:
┌─ GitHub ────────────────────────────────────┐
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ twbs/bootstrap │────>│ my/bootstrap │ │
│ └─────────────────┘ └─────────────────┘ │
│ ▲ │
└──────────────────────────────────┼──────────┘
▼
┌─────────────────┐
│ local/bootstrap │
└─────────────────┘
如果你想修复bootstrap的一个bug,或者新增一个功能,立刻就可以开始干活,干完后,往自己的仓库推送。
如果你希望bootstrap的官方库能接受你的修改,你就可以在GitHub上发起一个pull request。
12.使用SourceTree
当我们对Git的提交、分支已经非常熟悉,可以熟练使用命令操作Git后,再使用GUI工具,就可以更高效。
Git有很多图形界面工具,这里我们推荐SourceTree,它是由Atlassian开发的免费Git图形界面工具,可以操作任何Git库。
首先从官网下载SourceTree并安装,然后直接运行SourceTree。
第一次运行SourceTree时,SourceTree并不知道我们的Git库在哪。如果本地已经有了Git库,直接从资源管理器把文件夹拖拽到SourceTree上,就添加了一个本地Git库:
也可以选择“New”-“Clone from URL”直接从远程克隆到本地。
提交
我们双击learngit
这个本地库,SourceTree会打开另一个窗口,展示这个Git库的当前所有分支以及文件状态。选择左侧面板的“WORKSPACE”-“File status”,右侧会列出当前已修改的文件(Unstaged files):
选中某个文件,该文件就自动添加到“Staged files”,实际上是执行了git add README.md
命令:
然后,我们在下方输入Commit描述,点击“Commit”,就完成了一个本地提交:
实际上是执行了git commit -m "update README.md"
命令。
使用SourceTree进行提交就是这么简单,它的优势在于可以可视化地观察文件的修改,并以红色和绿色高亮显示。
分支
在左侧面板的“BRANCHES”下,列出了当前本地库的所有分支。当前分支会加粗并用○标记。要切换分支,我们只需要选择该分支,例如master
,然后点击右键,在弹出菜单中选择“Checkout master”,实际上是执行命令git checkout master
:
要合并分支,同样选择待合并分支,例如dev
,然后点击右键,在弹出菜单中选择“Merge dev into master”,实际上是执行命令git merge dev
:
推送
在SourceTree的工具栏上,分别有Pull
和Push
,分别对应命令git pull
和git push
,只需注意本地和远程分支的名称要对应起来,使用时十分简单。
注意到使用SourceTree时,我们只是省下了敲命令的麻烦,SourceTree本身还是通过Git命令来执行任何操作。如果操作失败,SourceTree会自动显示执行的Git命令以及错误信息,我们可以通过Git返回的错误信息知道出错的原因:
本文来自博客园,作者:bgtong,转载请注明原文链接:https://www.cnblogs.com/bgtong/p/16089603.html
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了