常用的svn和git命令

2018-07-20    来源:编程学习网

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

版本管理基本上是多人协作开发中必不可少的工具,常用的版本管理工具有:svn和git。虽然都有可视化的工具帮助我们使用这些工具,然而当你用上命令行之后,我想你会选择抛弃这些可视化工具。下面是我整理的一些常用的svn和git命令。

git&svn

Svn篇

首先你可以通过svn help/h来查看帮助信息。

开始工作

检出(checkout)服务器数据到本地

你刚入职一家公司,或新加入某个团队,立马参与到一个项目中,那么就得获取项目代码,开始你的项目生涯。这个时候一般你需要检出项目代码:

svn checkout/co [directory] project(本地目录名,可选) // 检出版本3 svn checkout/co –revision/r 3 [directory] project(本地目录名,可选) 

接着你就可以通过svn info来查看版本信息了。

导入(import)项目

有时候项目尚未创建,你需要将本地的目录放到SVN版本仓库中:

svn import project(本地目录名) [directory] 

然后可以通过svn list/ls确认已经在版本仓库中了。

更新

每次你开始编码前,你都最好先更新下本地的工作目录:

cd project svn update/up // 更新到版本3 svn update/up –revision/r 3 

这样你就可以在新的项目代码基础上工作了。

修改

可能你写了一个新的模块,增加了一些新的文件,需要纳入项目的版本控制:

svn add index.html list.html ... 

可能你发现某个模块已经陈旧了,不再使用了:

svn delete/del/remove/rm hello.html 

可能你发现一个模块的命名不太合理,需要改名:

svn move/mv main.css common.css 

可能你要创建一个新的较大的模块,需要新增目录:

svn mkdir list 

可能你发现要写的模块代码似于旧的模块,直接复制整个代码:

svn copy/cp users/list.js list/list.js 

检查

忙碌的一天过去了,或者一个任务完成了,这个时候一般会将你的工作成果,也就是代码更新到版本仓库。

习惯上会先检查下修改状态:

svn status/stat/st 

看到一些SVN状态位信息,确认是修改了哪些文件,之后一般会自己code review一下代码的改动,可能有的人会习惯直接用SVN方式来查看:

svn diff/di folder(本地目录名,可选,默认当前目录) // 查看index.html当前版本和版本3的差别 svn diff/di –revision/r 3 index.html // 查看index.html版本3和版本4的差别 svn diff/di –revision/r 3:4 index.html 

一般来说这个时候,没有什么特殊情况,就直接进入“提交”阶段了,然后结束一个工作日或工作周期,但难免会有些特殊情况出现。

取消修改

当你code review完后,发现有些改动不满意,你可能又会取消这些修改:

svn revert index.html // 回滚整个目录 svn revert . -R/--recursive 

分支操作

创建分支

创建一个分支

svn copy/cp svn://xxx.com/repo/trunk svn://xxx.com/repo/branches/test -m 'make branch test' 

把工作目录转到分支

svn switch/sw svn://xxx.com/repo/branches/test 

当然,也可以再转到主干svn switch/sw svn://xxx.com/repo/trunk。

给分支打标签

复制最新的发布分支为标签:

svn copy/cp svn://xxx.com/repo/branches/test svn://xxx.com/repo/tags/test_tag 

合并一个分支到主干

查找到分支版本

cd branches/test(分支目录) svn log –stop-on-copy 

最后一个r11340就是创建分支时的reversion,也可:

cd trunk(主干目录) svn -q –stop-on-copy svn://xxx.com/repo/branches/test(分支url) 

这条命令会查询出自创建分支以后分支上的所有修改,最下面的那个版本号就是我们要找的版本号。

合并到主干

cd trunk(主干目录) svn merge -r 11340(分支版本):HEAD svn://xxx.com/repo/branches/test(分支url) 

两个分支合并

假设99是从旧主干引出,100打完tag,表示是新主干。

合并最新代码的意思是:将新主干与旧主干比对,并添加到99中。这样99既有自己的新增的代码,也同时有最新线上的代码。

cd 99_Branch svn merge svn://xxx.com/repo/tags/project_Old_BL svn://xxx.com/repo/tags/project_New_BL svn ci -m 'merge 100 trunk' 

但是后来,其他人又向100提了代码,所以还需要将100分支(即打了tag后的100,打了tag前的100已是主干)合并至99中。

合并办法:找出100分支,比对与新主干之间的差别,并添加到99中。这样99就有最新的全部代码了。

cd 99_Branch svn merge svn://xxx.com/repo/tags/project_New_BL svn:/xxx.com/repo/branches/100_Branch svn ci -m 'merge 100 branch' 

发布

给当前主干打个标签,并且这个标签不再改动了,但是实际上标签和分支是一个意思,你可以在标签上继续做改动,但这不推荐。

svn copy/cp svn://xxx.com/repo/trunk svn://xxx.com/repo/tags/RB-1.0 

合并主干到分支

svn merge -r LastRevisionMergedFromTrunkToBranch:HEAD svn:/xxx.com/repo/branches/99_Branch 

解决冲突

当发生冲突的时候,会提示如下信息:

Conflict discovered in ‘index.html’.

Select: (p) postpone, (df) diff-full, (e) edit,

(mc) mine-conflict, (tc) theirs-conflict,

(s) show all options:

svn detects that theres a conflict here and require you to take some kind of action.

如果你输入s选项,则会列出所有svn解决冲突的选项,如下所示:

(e) edit - change merged file in an editor #直接进入编辑

(df) diff-full -show all changes made to merged file #显示更改至目标文件的所有变化

(r) resolved -accept merged version of file

(dc) display-conflict -show all conflicts(ignoring merged version) #显示所有冲突

(mc) mine-conflict -accept my version for all conflicts (same) #冲突以本地为准

(tc) theirs-conflict -accept their version for all conflicts (same) #冲突以服务器为准

(mf) mine-full -accept my version of entire file (even non-conflicts) #完全以本地为准

(tf) theirs-full -accept their version of entire file (same) #完全以服务器为准

(p) postpone -mark the conflict to be resolved later #标记冲突,稍后解决

(l) launch -launch external tool to resolve conflict

(s) show all -show this list

一般我们会选择p稍后解决冲突,这样会生成三个文件:.mine, .rOLDREV, .rNEWREV。比如:

index.html index.html.mine index.html.r1 index.html.r2 

解决冲突方法大致有一下几种:

手工修改index.html文件,然后将当前index.html作为最后提交的版本

svn resolve index.html –-accept working 

选择base版本,即index.html.rOLDREV作为最后提交的版本

svn resolve index.html –-accept base 

使用index.html.rNEWREV作为最后提交的版本

svn resolve index.html –-accept theirs-full 

使用index.html.mine作为最后提交的版本

svn resolve index.html –-accept mine-full // 或者用下面这条命令也可以 // svn resolve index.html –-accept theirs-conflict 

提交代码

最后,一切确认没问题了:code review完毕,自己觉得代码满意了;然后也合并完别人的修改并且没有冲突了。那么就提交代码吧:

svn commit/ci -m 'message' 

导出代码

你想把你的代码导出,不包含svn版本信息,那么你可以:

svn export svn://xxx.com/repo/branches/test folder(本地目录) 

Git篇

安装之后第一步

安装 Git 之后,你要做的第一件事情就是去配置你的名字和邮箱,因为每一次提交都需要这些信息:

git config --global user.name "bukas" git config --global user.email "[email protected]" 

获取Git配置信息,执行以下命令:

git config --list 

创建版本库

什么是版本库呢?版本库又名仓库,英文名repository,你可以简单理解成一个目录,这个目录里面的所有文件都可以被Git管理起来,每个文件的修改、删除,Git都能跟踪,以便任何时刻都可以追踪历史,或者在将来某个时刻可以“还原”。

mkdir testgit && cd testgit git init 

瞬间Git就把仓库建好了,细心的读者可以发现当前目录下多了一个.git的目录,默认是隐藏的,用ls -ah命令就可以看见。

git-init

把文件添加到版本库

touch readme.md git add readme.md 

然后用命令git commit告诉Git把文件提交到仓库:

git commit -m "wrote a readme file" 

简单解释一下git commit命令,-m后面输入的是本次提交的说明,可以输入任意内容,当然最好是有意义的,这样你就能从历史记录里方便地找到改动记录。

一次可以add多个不同的文件,以空格分隔:

git add a.txt b.txt c.txt 

仓库状态

git status 

git status命令可以让我们时刻掌握仓库当前的状态。

但如果能看看具体修改了什么内容就更好了:

git diff readme.md 

版本回退

在实际工作中,我们脑子里怎么可能记得一个几千行的文件每次都改了什么内容,不然要版本控制系统干什么。版本控制系统肯定有某个命令可以告诉我们历史记录,在Git中,我们用git log命令查看:

git log 

git-log

git log命令显示从最近到最远的提交日志。如果嫌输出信息太多,看得眼花缭乱的,可以试试加上--pretty=oneline参数:

git log --pretty=oneline 

git-log-pretty

需要友情提示的是,你看到的一大串类似2e70fd...376315的是commit id(版本号)

在 Git中,用HEAD表示当前版本,也就是最新的提交commit id,上一个版本就是HEAD^,上上一个版本就是HEAD^^,当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100。

现在我们要把当前版本回退到上一个版本,就可以使用git reset命令:

git reset --hard HEAD^ 

然我们用git log再看看现在版本库的状态,最新的那个版本已经看不到了!好比你从21世纪坐时光穿梭机来到了19世纪,想再回去已经回不去了,肿么办?

git-reset

办法其实还是有的,只要上面的命令行窗口还没有被关掉,你就可以顺着往上找啊找啊,假设找到那个commit id是2e70fdf...,于是就可以指定回到未来的某个版本:

git reset --hard 2e70fdf 

版本号没必要写全,前几位就可以了,Git会自动去找。当然也不能只写前一两位,因为Git可能会找到多个版本号,就无法确定是哪一个了。

现在,你回退到了某个版本,关掉了电脑,第二天早上就后悔了,想恢复到新版本怎么办?找不到新版本的commit id怎么办?

Git提供了一个命令git reflog用来记录你的每一次命令:

git reflog 

git-reflog

终于舒了口气,于是你看到的commit id是2e70fdf,现在,你又可以乘坐时光机回到未来了。

工作区和暂存区

Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。

工作区就是你在电脑里能看到的目录,比如我的testgit文件夹就是一个工作区。

工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。

Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD。

前面讲了我们把文件往 Git 版本库里添加的时候,是分两步执行的:

第一步是用git add把文件添加进去,实际上就是把文件修改添加到暂存区;

第二步是用git commit提交更改,实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时,Git自动为我们创建了唯一一个master分支,所以现在git commit就是往master分支上提交更改。

你可以简单理解为,git add命令实际上就是把要提交的所有修改放到暂存区(Stage),然后执行git commit就可以一次性把暂存区的所有修改提交到分支。

一旦提交后,如果你又没有对工作区做任何修改,那么工作区就是“干净”的。

修改与撤销

用git diff HEAD -- readme.md命令可以查看工作区和版本库里面最新版本的区别。

git checkout -- file可以丢弃工作区的修改:

git checkout -- readme.md 

命令git checkout -- readme.md意思就是,把readme.md文件在工作区的修改全部撤销,即让这个文件回到最近一次git commit或git add时的状态。

当然也可以用git reset命令。

删除文件

一般情况下,你通常直接在文件管理器中把没用的文件删了,或者用rm命令删了:

rm readme.md 

这个时候,Git 知道你删除了文件,因此,工作区和版本库就不一致了,git status命令会立刻告诉你哪些文件被删除了。

现在你有两个选择,一是确实要从版本库中删除该文件,那就用命令git rm删掉,并且git commit:

git rm readme.md git commit -m "remove readme.md" 

现在,文件就从版本库中被删除了。

另一种情况是删错了,因为版本库里还有呢,所以可以很轻松地把误删的文件恢复到最新版本:

git checkout -- readme.md 

生成SSH key

创建 SSH Key。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开 Shell(Windows下打开Git Bash),创建SSH Key:

ssh-keygen -t rsa -C "[email protected]" 

你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可。

如果一切顺利的话,可以在用户主目录里找到.ssh目录,里面有id_rsa和id_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。

然后登录GitHub(或者其它Git代码托管平台),打开Account settings,SSH Keys页面,点Add SSH Key,填上任意Title,在Key文本框里粘贴id_rsa.pub文件的内容。

为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。

当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。

远程服务器

Git 最强大的功能之一是可以有一个以上的远程服务器(另一个事实,你总是可以运行一个本地仓库)。你不一定总是需要写访问权限,你可以从多个服务器中读取(用于合并),然后写到另一个服务器中。添加一个远程服务器很简单:

git remote add origin(别名,根据爱好命名) [email protected]:bukas/bukas.git 

如果你想查看远程服务器的相关信息,你可以这样做:

# shows URLs of each remote server git remote -v   # gives more details about origin git remote show origin(别名) 

下一步,就可以把本地库的所有内容推送到远程库上:

git push -u origin master 

把本地库的内容推送到远程,用git push命令,实际上是把当前分支master推送到远程。

由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。

从现在起,只要本地作了提交,就可以通过命令把本地master分支的最新修改推送至GitHub:

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 clone克隆一个本地库:

git clone [email protected]:test/testgit.git 

你也许还注意到,GitHub给出的地址不止一个,还可以用https://github.com/test/testgit.git这样的地址。实际上Git支持多种协议,默认的git://使用ssh,但也可以使用https等其他协议。使用https除了速度慢以外,还有个最大的麻烦是每次推送都必须输入口令,但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

创建与合并分支

首先我们创建dev分支,然后切换到dev分支:

git checkout -b dev 

git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:

git branch dev git checkout dev 

然后用git branch命令查看当前分支:

git branch 

我们在dev分支上进行添加修改操作,然后我们把dev分支的工作成果合并到master分支上:

git checkout master git merge dev 

git merge命令用于合并指定分支到当前分支。

注意到git merge的信息里面可能有Fast-forward字样,Git告诉我们,这次合并是“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。

当然也不是每次合并都能Fast-forward。

合并完成后,就可以放心地删除dev分支了:

git branch -d dev 

如果要丢弃一个没有被合并过的分支,可以通过git branch -D <branch>强行删除。

在本地创建和远程分支对应的分支,使用git checkout -b branch-name origin/branch-name,本地和远程分支的名称最好一致;

建立本地分支和远程分支的关联,使用git branch --set-upstream branch-name origin/branch-name;

从远程抓取分支,使用git pull,如果有冲突,要先处理冲突。

解决冲突

人生不如意之事十之八九,合并分支往往也不是一帆风顺的。

有时候我们进行合并的时候,会提示有冲突出现CONFLICT (content),必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件。

打开冲突文件我们会看到Git用<<<<<<<,=======,>>>>>>>标记出不同分支的内容,我们修改后提交:

git add readme.md git commit -m "conflict fixed" 

用带参数的git log也可以看到分支的合并情况:

git log --graph --pretty=oneline --abbrev-commit 

分支管理策略

通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。

如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。

下面我们实战一下--no-ff方式的git merge:

首先,仍然创建并切换dev分支:

git checkout -b dev 

修改readme.md文件,并提交一个新的commit:

git add readme.md git commit -m "add merge" 

现在,我们切换回master:

git checkout master 

准备合并dev分支,请注意--no-ff参数,表示禁用Fast forward:

git merge --no-ff -m "merge with no-ff" dev 

Bug分支

软件开发中,bug就像家常便饭一样。有了bug就需要修复,在Git中,由于分支是如此的强大,所以,每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。

当你接到一个修复一个代号101的bug的任务时,很自然地,你想创建一个分支issue-101来修复它,但是,等等,当前正在dev上进行的工作还没有提交。

并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复该bug,怎么办?

幸好,Git还提供了一个stash功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:

git stash 

现在,用git status查看工作区,就是干净的(除非有没有被 Git 管理的文件),因此可以放心地创建分支来修复bug。

首先确定要在哪个分支上修复bug,假定需要在master分支上修复,就从master创建临时分支:

git checkout master git checkout -b issue-101 

现在修复bug,然后提交:

git add readme.md git commit -m "fix bug 101" 

修复完成后,切换到master分支,并完成合并,最后删除issue-101分支:

git checkout master git merge --no-ff -m "merged bug fix 101" issue-101 

太棒了,原计划两个小时的bug修复只花了5分钟!现在,是时候接着回到dev分支干活了!

git checkout dev git status 

工作区是干净的,刚才的工作现场存到哪去了?用git stash list命令看看:

git stash list 

工作现场还在,Git把stash内容存在某个地方了,但是需要恢复一下,有两个办法:

一是用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除;

另一种方式是用git stash pop,恢复的同时把stash内容也删了:

git stash pop 

再用git stash list查看,就看不到任何stash内容了。

你可以多次stash,恢复的时候,先用git stash list查看,然后恢复指定的stash,用命令

git stash apply [email protected]{0} 

标签管理

发布一个版本时,我们通常先在版本库中打一个标签,这样,就唯一确定了打标签时刻的版本。将来无论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来。所以,标签也是版本库的一个快照。

命令git tag <tagname>用于新建一个标签,默认为HEAD,也可以指定一个commit id。

git tag -a <tagname> -m "blablabla..."可以指定标签信息。

还可以通过-s用私钥签名一个标签:

git tag -s v0.5 -m "signed version 0.2 released" fec145a 

git tag可以查看所有标签。

用命令git show <tagname>可以查看某个标签的详细信息。

如果标签打错了,也可以删除:

git tag -d v0.1 

因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地安全删除。

如果要推送某个标签到远程,使用命令git push origin <tagname>:

git push origin v1.0 

或者,一次性推送全部尚未推送到远程的本地标签:

git push origin --tags 

如果标签已经推送到远程,要删除远程标签就麻烦一点,先从本地删除:

git tag -d v0.9 

然后,从远程删除。删除命令也是push,但是格式如下:

git push origin :refs/tags/v0.9 

忽略特殊文件

在安装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了:

git config --global core.excludesfile '~/.gitignore' 

配置别名

有没有经常敲错命令?比如git status?status这个单词真心不好记。

如果敲git st就表示git status那就简单多了,当然这种偷懒的办法我们是极力赞成的。

我们只需要敲一行命令,告诉Git,以后st就表示status:

git config --global alias.st status 

当然还有别的命令可以简写:

git config --global alias.co checkout git config --global alias.ci commit git config --global alias.br branch 

--global参数是全局参数,也就是这些命令在这台电脑的所有Git仓库下都有用。

在撤销修改一节中,我们知道,命令git reset HEAD file可以把暂存区的修改撤销掉(unstage),重新放回工作区。既然是一个unstage操作,就可以配置一个unstage别名:

git config --global alias.unstage 'reset HEAD' 

配置一个git last,让其显示最后一次提交信息:

git config --global alias.last 'log -1' 

甚至还有人把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的时候,加上–global是针对当前用户起作用的,如果不加,那只针对当前的仓库起作用。

配置文件放哪了?每个仓库的Git配置文件都放在.git/config文件中。

而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中。

原文:http://w3cboy.com/post/2015/09/those-common-svn-and-git-commands/

标签: isp 安全 代码 服务器 权限 数据库

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:如何做好架构之识别问题

下一篇:认识概念是理解架构的基础