[原创] SVN和Git的一些用法总结

以下都是比较基础的操作，高手们请绕道，不必浪费时间来看了。

（A）SVN

➤ 查看日志
提交的时候一般会写上注释，如果要查看提交日志，用以下命令：

svn log -l 4

其中，-l 4表示只查看最近4条日志（也可以没有这样的参数，就表示查看所有日志）。但是你通常会很抓狂地发现，最近的几条日志中，竟然没有你才刚刚提交的那一次的日志！这是怎么回事？日志丢了吗？
其实，是因为你要很用以下命令，更新本地的版本库，才能看到最近提交的日志：

svn up

这事如果你没注意到，那么可能会浪费你很多时间。问Google也不好找答案，因为这个问题不太好描述，所以不好搜索答案。

➤ 查看指定的版本修改了哪些文件

svn diff --summarize -c 566

其中，566是你指定的版本。

➤ 查看某个文件在指定的版本修改了什么内容

svn diff Test.java -c 566 > codelast.diff

其中，Test.java是你要检查的文件，566是你指定的版本，最后diff被输出到了codelast.diff文件中。

➤ 提交

svn ci -m "Your comment"

其中，Your comment 就是你填写的注释，如果你想换行写，也是可以的，只要你不写后面的那个引号，你可以写一行就回车一次，最后写完了，再加上后面的引号，然后再回车，就执行提交动作了。

➤ 检出指定版本的版本库

svn co https://xxx -r 566

其中，https://xxx 是你的版本库地址，566是你要检出的版本号。版本库将被检出到当前路径下。
文章来源：http://www.codelast.com/

➤ 将指定version的trunk上的代码拷贝到tags的指定目录下

svn cp https://svn.codelast.com/trunk/my-project@1333 https://svn.codelast.com/tags/my-project-r1333

如上命令将trunk下的 my-project 项目的 1333 版本拷贝到了tags下的 my-project-r1333 中。

➤ 将branches上的指定版本合并（merge）到trunk上
有时候我们会在一个分支（branches）上开发，等开发完成的时候，需要把我们已经提交到branches上的代码合并到trunk上，假设你本地的工作目录是在branches上（刚开发完branches上的一个版本，提交了代码），那么可以像下面这样做：

svn switch trunk-url-of-your-project
svn merge branch-url-of-your-project

其中，第一条命令是将本地工作目录切换到trunk上。执行完这条命令后，你本地的工作目录里的文件就会变成与trunk里的文件一致。
第二条命令是将branches上的文件合并到本地。执行完这条命令行，你本地的工作目录里的文件就会变成与branches合并的结果。但是请注意，由于本地的工作目录已经是trunk了（用svn info可查看），所以这一更新，就导致本地有若干文件变成“已修改，但未提交”的状态。因此，你需要把本地因merge被修改过的文件提交一次，就可以使得trunk上的文件变成与branches合并后的版本：

svn ci -m "Merge branch to trunk"

文章来源：http://www.codelast.com/
关于svn merge的更详细说明，可参考此文档。

➤ 为文件添加上可执行权限
假设你有一个脚本文件checkin到代码库中了，但是你在commit之前，却忘了给它添加可执行权限，那么，当checkout出来这份代码时，就会得到一个没有x权限的脚本，还需要手工再为它添加上x权限，非常麻烦。所以，要为该文件添加上x权限：

svn propset svn:executable on your-script.sh

然后再 svn ci 提交修改即可（尽管你没有修改文件内容，只是修改了文件的权限，也是会被标记为已修改的，需要将此修改提交到代码库中）。

➤ checkout单个文件到本地
如果用 svn checkout 单个文件的URL 来检出一个文件到本地的话，会得到如下的错误提示：

svn: E200007: URL 'https://xxx' refers to a file, not a directory

那么，如何checkout单个文件呢？答案是用svn export命令即可。

➤ Review Board提交svn的diff文件时，提示“The file 'https://svn.codelast.com/abc.txt' (r1030) could not be found in the repository”错误的解决办法
我遇到的这例错误，是因为我在一个项目中新添加了一个文件abc.txt，于是用 svn add abc.txt 添加它，然后 svn diff > today.diff 生成了项目的diff文件，然后把该diff文件提交到Review Board中，想要生成一个新的review，结果就遇到了上面的错误提示。
这个错误提示乍一看非常搞笑：因为abc.txt是新添加的文件，它当然不会在repository中存在啊！这不是废话么？
同时我注意到，当我执行 svn add abc.txt时，命令行提示：

A  (bin)  abc.txt

虽然abc.txt是一个纯文本文件，但是svn貌似把它认作了一个binary文件，于是我Google到了这个链接，按照里面的说法，我在 svn add abc.txt 之后进行了如下操作：

svn propset svn:mime-type 'text/plain' abc.txt

然后再生成项目的diff文件，再提交到Review Board上，问题搞定！

（B）Git

➤ 提交修改到远程的git repository的基本流程（前提是你当前目录已经处于git版本控制之下）
添加当前目录下所有文件到“即将提交的列表”（当然也可以指定某些指定的文件，将 . 换成指定的文件即可）：

git add .

将修改提交到本地：

git commit -m "对本次修改的注释写在这里"

提交到远程的git repository：

git push

➤ 删除远程git repository中的文件
假设要删除当前目录下的abc.txt文件（指远程git repository中的），则：

git rm abc.txt

然后提交到本地：

git commit -m "delete a file"

然后提交到远程的repository：

git push

文章来源：http://www.codelast.com/
➤ TortoiseGit提交代码前弹出错误提示“username and email must be set...”的解决办法
Git Commit（提交）的时候，如果Tortoise弹出一个错误对话框，提示你必须先设置用户名和Email，那么你理所当然地按它的指引点击“Yes”去设置，奇葩的是，在我的Win7上，TortoiseGit settings→Git页面中的“Name”和“Email”竟然无法输入文字（仿佛输入框是只读的一样）！就算我找到了这篇教程，也无济于事。
后来我又找到了这篇教程，尝试用命令行去设置，果然OK了：

d:\git\bin>git.exe config --global user.name "你的用户名"
d:\git\bin>git.exe config --global user.email "你的Email"

执行这两条命令之后，再回到TortoiseGit的settings→Git页面，就看到Name和Email已经设置好了。

➤ 解决每次 git pull 的时候都提示输入密码的烦人问题
执行以下命令永久保存密码：

git config --global credential.helper store

如果不想永久保存密码，可以在指定的时间内保存密码：

git config --global credential.helper "cache --timeout=360000"

其中，timeout值表示缓存密码多少时间（单位是毫秒还是秒，我不记得了），把它设置为一个非常大的值即可，然后你再git pull的时候，按提示输入密码之后，下一次就不会再提示输入密码了（在timeout时间之内）。
文章来源：http://www.codelast.com/
➤ Windows下的TortoiseGit每次push的时候都提示要输入密码的问题
可以通过修改TortoiseGit的配置来解决：
在设置界面中，“Git”设置子项中，点击“编辑本地.git/config”，会打开一个文本文件，在最后加上如下内容并保存：

[credential]
	helper = store

然后再push一次并输入密码，TortoiseGit就可以记住你的密码啦。

➤ 提交代码到远程的branch

git push -u origin local_branch_name:remove_branch_name

会把本地的 local_branch_name 这个分支提交到远程的 remote_branch_name 这个分支上，如果远程没有这个分支，就会被创建。

➤ 删除远程的branch
前面用 git push 命令把本地的分支推送到远程的分支上，命令是很形象的，但是让人非常费解的就是，要删除远程的branch，同样可以用这个push命令：

git push -u origin :remote_branch_name

表示删除远程的 remote_branch_name 这个分支。这个让人费解的命令，可以参考Git手册中的说明来理解。

➤ 修改已提交的信息
修改最近一次提交的信息很简单：

git commit --amend

在弹出的编辑界面中修改并保存，再用 git log 看一下，提交的信息是不是已经变了？
但如果要编辑的信息，不是最近一次提交呢？这就需要用到 git rebase 命令了。步骤如下：
用 git log 命令查看到你要修改的那一次提交的版本，然后找到比它更旧的再前一个版本的版本号，例如 f0d1fad，然后：

git rebase -i f0d1fad

在弹出的编辑界面中，会看到类似于下面的信息：

pick a3d4def 修改了一处实现
pick d0ea224 添加了配置文件

假设我们要修改的提交信息，是第二行那一次提交，则把它前面的“pick”改为“edit”或“e”（就是edit的缩写），然后保存。
此时，再用 git log 查看一下，最近的一次提交竟然变成了你刚修改的那次提交？没错，然后我们就可以像前面的方法一样，用 git commit --amend 来修改最近一次的提交信息了。
修改完信息之后，还要把 git log 的信息顺序改回来，通过如下命令完成最后一个操作：

git rebase --continue

文章来源：http://www.codelast.com/
➤ 配置命令别名
例如，git status这个超级常用的命令实在太长了，git st 就很好，可以像下面这样配置，使得执行 git st 的时候，等同于 git status：

git config --global alias.st status

➤ 查看文件差异
修改了一个文件（该文件已经加入版本控制中了），还没有把它 git add 到暂存区，则用以下命令就可以看到修改了什么：

git diff

如果已经把该文件 git add 到了暂存区，再使用 git diff 命令，将没有任何输出。此时，应使用以下两个命令中的任何一个，可以查看到修改的内容（其实显示的就是暂存区里和上一次提前之间的差异）：

git diff --cached
git diff --staged

➤ 将一个文件移除出版本控制，但是并不将它从本地磁盘上删除
git rm your_file 会将文件 your_file 从本地以及版本控制系统中都删除掉，但是如果我只想把此文件移除出版本控制系统，但并不想把它从本地磁盘上删除，则可以这样做：

git rm --cached your_file

➤ 用meld及git-diffall来比较两个版本之间的文件差异
Meld是一款超级强大的图形化diff比较工具，比你用diff命令查看两个文件的差异要直观得多，那么，如何让git与Meld整合到一起呢？需要用到一个叫git-diffall的第三方脚本，下面会说到。

sudo apt-get install meld

sudo cp git-diffall /usr/bin

git config --global diff.tool meld
git config --global alias.diffall git-diffall

git difftool ..master src/test/MyClass.java

文章来源：http://www.codelast.com/
➤ 撤消修改的几种情况
在SVN中，修改了一个文件之后，还没有提交的话，我们可以用 svn revert your_file 命令，来撤消我们对文件 your_file 所做的修改，使之恢复到没修改之前的状态。但是在Git中，等价的命令是什么呢？在很少使用git之前，我也有这个问题，于是我到Google上一搜“svn revert git”，搜出来很多人都在问这个问题，其实要理解好这个问题，需要先理解好git有工作区、暂存区（stage）的概念，而SVN没有暂存区的概念，所以，当你刚从SVN转到Git时，会很困惑为什么Git撤消修改那么麻烦。其实这才是Git强大之处啊。
①修改了一个文件，还没有将它添加到暂存区，此时，要撤消所做的修改：

git checkout -- your_file 

②修改了一个文件，并且已经通过 git add your_file 把它添加到了暂存区，则想把这个文件复原，先要把它从暂存区“弄出来”：

git reset HEAD your_file

现在，你再用 git status 命令查看的话，会发现它已经被从暂存区“拿出来”了，变成了没有 git add 的状态，但是，它仍然是我们修改过内容的，要继续撤消我们修改的内容的话，继续像上面一样，用 git checkout -- your_file 命令，即可将你所做的修改完全复原了。

➤ 查看每个版本修改的文件
git log 可以查看提交日志，再加一个参数就可以看到每个版本修改的文件都有哪些了：

git log --name-status

文章来源：http://www.codelast.com/
➤ 一次git add所有modified的文件到暂存区
如果你修改了100个文件，那么一个个地 git add 它们到暂存区无异于自虐，此时你需要的是批量add：

git add -i

然后就进入了交互式界面：

  1: status	  2: update	  3: revert	  4: add untracked
  5: patch	  6: diff	  7: quit	  8: help

选择2，回车，会列出所有将要被 add 的文件，输入星号（*）并回车（表示选择所有文件），然后又会回到上面的菜单界面，选择7回车退出，这时再用 git status 看一下，是不是所有修改过的文件都添加到了暂存区里了？

➤ 利用Bitbucket在两地同步私有代码
(当前，2019.11，GitHub已经可以创建private的repo，写这一条的时候GitHub还不行)
与Github不同，Bitbucket可以创建private的代码仓库，这对个人而言非常有用。例如，你在台式机A上写的代码，当你出差到其他城市后，还想在你带的笔记本（记为B）上继续写，那么这时候怎么办？有一个傻傻的办法就是连上电脑A（如果可以的话），然后把整个项目打一个tar包，传到B上，但如果你的整个项目目录非常大，压缩之后仍有几百M，那么你可能需要耗费大量时间来传输。更为可取的一个办法就是利用类似于Bitbucket这样的服务，来同步代码，使得只需要更新少量数据就OK了。
下面是步骤：

git remote add origin https://codelast@bitbucket.org/codelast/my-repo.git

git push -u origin my-branch:my-branch

git checkout master
git fetch

git checkout -b my-branch
git merge origin/my-branch

Updating e8b4538..6bc7bcd
Fast-forward
 src/java/com/codelast/Demo.java        |  11 +++++++
 ......

git checkout -b my-branch
git pull

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> my-branch

git branch --set-upstream-to=origin/my-branch my-branch

Branch my-branch set up to track remote branch my-branch from origin.

文章来源：http://www.codelast.com/
➤ 查看当前版本比上一个版本修改了什么内容

git diff HEAD^ HEAD

其中，HEAD代表当前版本，后面带一个 ^ 号表示其之前一个版本。

➤ Git子命令的自动完成／自动补全
在Ubuntu下用 apt-get install git 安装好Git后，Git的子命令就已经能自动完成了，例如你输入 git ad，然后按 TAB，会发现它被补全成了 git add，但是在Arch Linux ARM下，这个功能却没有，我们可以参考这个链接中的教程自己做。
基本思想就是获取github上的一个 git-completion.bash 脚本，然后把它添加到开机自动执行的脚本中：

curl https://raw.githubusercontent.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.sh
chmod +x ~/.git-completion.sh

然后编辑 /etc/profile 文件，在最后添加如下代码：

if [ -f ~/.git-completion.sh ]; then
    . ~/.git-completion.sh
fi

重启系统，搞定，Git已经可以自动完成子命令了。

➤ 检出指定版本的某个文件

git checkout <commit_id> <your_file_path>

例如：

git checkout 3493c0ec MyClass.java

那么检出的文件放到哪了呢？当然是放到这个文件原来的路径，也就是覆盖了本地的相同文件。

➤ 删除远程已经不存在、本地还存在的远程（remote branch）分支记录
这是什么意思？拿GitLab来举个例子：

• 我在GitLab上提交了一个Merge Request，并且在提交的时候设置了：如果上游接受这个reqeust，则自动删除对应的远程branch
• 上游接受了这个request，于是我的那个远程branch被GitLab自动删除了
• 我于是删除了本地的对应branch

现在看似和这一次commit相关的清理工作已经做完了，但实际上还没有。用 git branch -a 命令，会看到类似于下面的信息：

* master

  remotes/origin/HEAD -> origin/master

  remotes/origin/gitlab-test

git remote prune origin

会打印出一条信息：

* [pruned] origin/gitlab-test

然后再试试 git branch -a，就会发现那个branch的信息已经删除掉了。

➤ fork出来的项目和主干保持同步
假设你在GitLab上fork了一个项目，那么接下来你fork出来的项目就和原项目（称之为主干）无关了，主干更新了代码，你fork出来的项目并不会自动更新代码。
而我们每次开发一个新功能之前，为了防止大量代码冲突，都应该在最新版的代码基础上来开发，因此，让我们fork出来的代码与主干保持一致是有必要的。方法如下：

• 把主干的远程仓库地址添加到你当前项目中

git remote add upstream git@gitlab.codelast.com:test-repo/test-project.git

• 把主干的最新代码检出到本地

git fetch upstream

• 合并主干的最新代码到本地的master分支上（本地的master分支，其对应的远程分支，就是我们前面fork出来的那个项目的master分支）

git checkout master

git merge upstream/master

• 如果merge的时候有冲突(conflict)，那么你需要解决完所有冲突，然后 git add -u 把解决完冲突的文件添加到待commit的区域，然后 git commit 把修改提交到本地
• 现在，你本地的master分支已经是比主干更新（或者至少和它一样）的代码了，可以推送到远程你fork出来的那个项目了

git push -u origin master

至此，你fork出来的那个项目，其master分支已经和主干完全同步啦。

➤ 生成指定 commit 的 patch

git format-patch -1 {commit-id}

即会在当前目录下生成一个 .patch 文件。

➤ 设置 commit 信息里的 Email

git config user.email abc@gmail.com

此命令不修改已经提交的commit里的Email，仅对未来的commit生效。

➤ 使用 git rebase -i 合并本地的多次commit
当你在一个branch上开发时，在本地可能会多次提交代码，最后才会push到远程代码服务器上。在本地的多次提交，为了让它们看起来“整齐”，通常会把它们合并成一个commit再push到远程。合并的过程可以使用 git rebase -i 命令完成。下面就举例说明。
假设你有如下几个commit，从上到下，依次为 时间最新→时间最旧：

commit ddddd
commit ccccc
commit bbbbb
commit aaaaa (origin/master, origin/HEAD, master)

这里面的 commit id 全部都是虚构的（aaaaa～ddddd），只是为了拿来演示。其中，aaaaa这个commit已经push到远程服务器了，它同时也是这四次commit里面时间最老的那个commit。其他几次commit（bbbbb，ccccc，ddddd）全都是在本地的commit，还没有push到远程服务器。为了把这3个本地的commit合并成一个，我们可以执行：

git rebase -i aaaaa

即：找到所有要合并的commit中，时间最旧的那个commit（即bbbbb）的前一次commit（即aaaaa），再执行 git rebase -i (找到的commit_id) 命令。
之后Git会自动打开你预先配置好的文本编辑器，进入文本编辑界面：

pick ddddd temp

pick ccccc temp

pick bbbbb temp

这里面会列出所有待合并的commit的commit_id以及它们的commit message（在这里全都是"temp"，commit的时候随便填的）。我们需要做的是：把时间最新的那个commit（即ddddd）前面的"pick"保持不变，把其他所有commit（即ccccc、bbbbb）前面的"pick"改为"s"，也就是像下面这样：

pick ddddd temp

s ccccc temp

s bbbbb temp

保存该文件（我配置的Git文本编辑器是VIM，所以在这里用 ESC → :x），马上会进入另一个文本编辑界面：

# This is a combination of 3 commits.

# This is the 1st commit message:

 

temp

 

# This is the commit message #2:

 

temp

 

# This is the commit message #3:

 

temp
（后面内容很长，全都是#号开头的注释，这里省略）

此时，合并完成！之后就可以把合并成的那一个commit push到远程服务器上了。
文章来源：http://www.codelast.com/
➤ git status不显示未追踪的文件（Untracked files）

git status -uno

这里的"-uno"等价于"--untracked-files=no"

➤ To be added...
文章来源：http://www.codelast.com/

（C）git-svn

git-svn是Subversion 双向桥接工具，用于：Git作为本地的版本控制工具，SVN作为远程的仓库。
有人可能会有疑问：为什么会出现git-svn这个东西？这是由于Git实在是比SVN要好用太多太多了，所以有时候，尽管我们不得不使用远程的SVN仓库来和大家同步工作（例如，你公司的代码库就是SVN的），但是在本地，我们仍然可以使用Git来做版本控制，这就是git-svn工具的作用。

➤ 初始化
用SVN作为版本控制工具时，我们检出一个项目，用的是 svn co http://xxx 这样的方法，但是用git-svn时，我们应该这样做：

git svn clone http://xxx

➤ 只查看SVN log
git log 命令会列出你的所有git commit日志，但是如果只想看SVN的commit日志，就需要用：

git svn log

但是这样输出的信息可能太杂乱了，可以用如下命令，让一次提交只显示一行信息：

git svn log --oneline

➤ 本地已经commit了几个版本到git版本库中，但是只想提交一个较旧的版本到远端SVN库中
假设远端repo使用的是SVN，本地使用git-svn来管理，在开发过程中，本地的my-branch中已经提交了A→B→C三个版本，版本A是时间最早的一次提交，版本C是时间最新的一次提交，现在想把版本A上的修改提交到远端SVN repo中，而版本B和版本C暂时不想提交到SVN repo中。但是我们知道，git-svn dcommit命令会将当前版本的修改全部提交到SVN repo中去，因此，不能在当前版本C中进行此操作，一个可用的方法如下：
切换到工作的branch：

git checkout my-branch

在当前branch基础上，再创建一个新的branch，并切换过去：

git checkout -b my-branch-to-commit

这时，my-branch-to-commit这个分支上也有版本A、B、C了。假设版本A的commit id为d939ac4，则将此分支的HEAD指向版本A：

git reset --hard d939ac4

这时，my-branch-to-commit这个分支上，最新的版本就是版本A了，于是，我们可以把它提交到远端的SVN repo中去了：

git svn dcommit

于是我们完成了“提交版本A到SVN”的任务，但是，我们还要在版本B、版本C的基础上继续开发，所以，下面，我们要把这两个版本“找回来”。
先切换回master分支：

git checkout master

更新到最新的SVN版本：

git svn rebase

这时，master分支上已经是版本A的代码了。
再创建一个新的工作分支my-branch-to-continue：

git checkout -b my-branch-to-continue

这时，git cherry-pick命令就大显神威了，它可以挑选指定版本的修改，并应用到当前分支上，所以，我们需要做的是，把my-branch这个分支中的版本B、版本C的修改cherry-pick过来，应用到my-branch-to-continue分支上。
假设版本B的commit id为c37d531，版本C的commit id为822dbbd，则：

git cherry-pick c37d531
git cherry-pick 822dbbd

这会生成两个新的commit。
现在，在my-branch-to-continue这个分支上，我们的状态就是：版本A已经是提交到了SVN，版本B、版本C已经提交到了本地git repo中。
现在可以把my-branch这个分支删掉了，因为它已经没用了：

git branch -D my-branch

大功告成。

文章来源：https://www.codelast.com/
➤➤ 版权声明 ➤➤ 
转载需注明出处：codelast.com 
感谢关注我的微信公众号（微信扫一扫）：