转：http://www.codelast.com/?p=5719
转载请注明出处：http://www.codelast.com/
以下都是比较基础的操作，高手们请绕道，不必浪费时间来看了。
（A）SVN
（1）查看日志
提交的时候一般会写上注释，如果要查看提交日志，用以下命令：
|
1 |
|
其中，-l 4表示只查看最近4条日志（也可以没有这样的参数，就表示查看所有日志）。但是你通常会很抓狂地发现，最近的几条日志中，竟然没有你才刚刚提交的那一次的日志！这是怎么回事？日志丢了吗？
其实，是因为你要很用以下命令，更新本地的版本库，才能看到最近提交的日志：
|
1 |
|
这事如果你没注意到，那么可能会浪费你很多时间。问Google也不好找答案，因为这个问题不太好描述，所以不好搜索答案。
（2）查看指定的版本修改了哪些文件
|
1 |
|
其中，566是你指定的版本。
（3）查看某个文件在指定的版本修改了什么内容
|
1 |
|
其中，Test.java是你要检查的文件，566是你指定的版本，最后diff被输出到了codelast.diff文件中。
（4）提交
|
1 |
|
其中，Your comment 就是你填写的注释，如果你想换行写，也是可以的，只要你不写后面的那个引号，你可以写一行就回车一次，最后写完了，再加上后面的引号，然后再回车，就执行提交动作了。
（5）检出指定版本的版本库
|
1 |
|
其中，https://xxx 是你的版本库地址，566是你要检出的版本号。版本库将被检出到当前路径下。
文章来源：http://www.codelast.com/
（6）将指定version的trunk上的代码拷贝到tags的指定目录下
|
1 |
|
如上命令将trunk下的 my-project 项目的 1333 版本拷贝到了tags下的 my-project-r1333 中。
（7）将branches上的指定版本合并（merge）到trunk上
有时候我们会在一个分支（branches）上开发，等开发完成的时候，需要把我们已经提交到branches上的代码合并到trunk上，假设你本地的工作目录是在branches上（刚开发完branches上的一个版本，提交了代码），那么可以像下面这样做：
|
1 2 |
|
其中，第一条命令是将本地工作目录切换到trunk上。执行完这条命令后，你本地的工作目录里的文件就会变成与trunk里的文件一致。
第二条命令是将branches上的文件合并到本地。执行完这条命令行，你本地的工作目录里的文件就会变成与branches合并的结果。但是请注意，由于本地的工作目录已经是trunk了（用svn info可查看），所以这一更新，就导致本地有若干文件变成“已修改，但未提交”的状态。因此，你需要把本地因merge被修改过的文件提交一次，就可以使得trunk上的文件变成与branches合并后的版本：
|
1 |
|
文章来源：http://www.codelast.com/
关于svn merge的更详细说明，可参考此文档。
（8）为文件添加上可执行权限
假设你有一个脚本文件checkin到代码库中了，但是你在commit之前，却忘了给它添加可执行权限，那么，当checkout出来这份代码时，就会得到一个没有x权限的脚本，还需要手工再为它添加上x权限，非常麻烦。所以，要为该文件添加上x权限：
|
1 |
|
然后再 svn ci 提交修改即可（尽管你没有修改文件内容，只是修改了文件的权限，也是会被标记为已修改的，需要将此修改提交到代码库中）。
（9）checkout单个文件到本地
如果用 svn checkout 单个文件的URL 来检出一个文件到本地的话，会得到如下的错误提示：
svn: E200007: URL ‘https://xxx‘ refers to a file, not a directory
那么，如何checkout单个文件呢？答案是用svn export命令即可。
（10）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 之后进行了如下操作：
|
1 |
|
然后再生成项目的diff文件，再提交到Review Board上，问题搞定！
（B）Git
（1）提交修改到远程的git repository的基本流程（前提是你当前目录已经处于git版本控制之下）
添加当前目录下所有文件到“即将提交的列表”（当然也可以指定某些指定的文件，将 . 换成指定的文件即可）：
|
1 |
|
将修改提交到本地：
|
1 |
|
提交到远程的git repository：
|
1 |
|
（2）删除远程git repository中的文件
假设要删除当前目录下的abc.txt文件（指远程git repository中的），则：
|
1 |
|
然后提交到本地：
|
1 |
|
然后提交到远程的repository：
|
1 |
|
文章来源：http://www.codelast.com/
（3）TortoiseGit提交代码前弹出错误提示“username and email must be set...”的解决办法
Git Commit（提交）的时候，如果Tortoise弹出一个错误对话框，提示你必须先设置用户名和Email，那么你理所当然地按它的指引点击“Yes”去设置，奇葩的是，在我的Win7上，TortoiseGit settings→Git页面中的“Name”和“Email”竟然无法输入文字（仿佛输入框是只读的一样）！就算我找到了这篇教程，也无济于事。
后来我又找到了这篇教程，尝试用命令行去设置，果然OK了：
|
1 2 |
|
执行这两条命令之后，再回到TortoiseGit的settings→Git页面，就看到Name和Email已经设置好了。
（4）解决每次 git pull 的时候都提示输入密码的烦人问题
执行以下命令：
|
1 |
|
其中，timeout值表示缓存密码多少时间（单位是毫秒还是秒，我不记得了），把它设置为一个非常大的值即可，然后你再git pull的时候，按提示输入密码之后，下一次就不会再提示输入密码了（在timeout时间之内）。
文章来源：http://www.codelast.com/
（5）Windows下的TortoiseGit每次push的时候都提示要输入密码的问题
可以通过修改TortoiseGit的配置来解决：
在设置界面中，“Git”设置子项中，点击“编辑本地.git/config”，会打开一个文本文件，在最后加上如下内容并保存：
|
1 2 |
|
然后再push一次并输入密码，TortoiseGit就可以记住你的密码啦。
（6）提交代码到远程的branch
|
1 |
|
会把本地的 local_branch_name 这个分支提交到远程的 remote_branch_name 这个分支上，如果远程没有这个分支，就会被创建。
（7）删除远程的branch
前面用 git push 命令把本地的分支推送到远程的分支上，命令是很形象的，但是让人非常费解的就是，要删除远程的branch，同样可以用这个push命令：
|
1 |
|
表示删除远程的 remote_branch_name 这个分支。这个让人费解的命令，可以参考Git手册中的说明来理解。
（8）修改已提交的信息
修改最近一次提交的信息很简单：
|
1 |
|
在弹出的编辑界面中修改并保存，再用 git log 看一下，提交的信息是不是已经变了？
但如果要编辑的信息，不是最近一次提交呢？这就需要用到 git rebase 命令了。步骤如下：
用 git log 命令查看到你要修改的那一次提交的版本，然后找到比它更旧的再前一个版本的版本号，例如 f0d1fad，然后：
|
1 |
|
在弹出的编辑界面中，会看到类似于下面的信息：
|
1 2 |
|
假设我们要修改的提交信息，是第二行那一次提交，则把它前面的“pick”改为“edit”或“e”（就是edit的缩写），然后保存。
此时，再用 git log 查看一下，最近的一次提交竟然变成了你刚修改的那次提交？没错，然后我们就可以像前面的方法一样，用 git commit --amend 来修改最近一次的提交信息了。
修改完信息之后，还要把 git log 的信息顺序改回来，通过如下命令完成最后一个操作：
|
1 |
|
文章来源：http://www.codelast.com/
（9）配置命令别名
例如，git status这个超级常用的命令实在太长了，git st 就很好，可以像下面这样配置，使得执行 git st 的时候，等同于 git status：
|
1 |
|
（10）查看文件差异
修改了一个文件（该文件已经加入版本控制中了），还没有把它 git add 到暂存区，则用以下命令就可以看到修改了什么：
|
1 |
|
如果已经把该文件 git add 到了暂存区，再使用 git diff 命令，将没有任何输出。此时，应使用以下两个命令中的任何一个，可以查看到修改的内容（其实显示的就是暂存区里和上一次提前之间的差异）：
|
1 2 |
|
（11）将一个文件移除出版本控制，但是并不将它从本地磁盘上删除
git rm your_file 会将文件 your_file 从本地以及版本控制系统中都删除掉，但是如果我只想把此文件移除出版本控制系统，但并不想把它从本地磁盘上删除，则可以这样做：
|
1 |
|
（12）用meld及git-diffall来比较两个版本之间的文件差异
Meld是一款超级强大的图形化diff比较工具，比你用diff命令查看两个文件的差异要直观得多，那么，如何让git与Meld整合到一起呢？需要用到一个叫git-diffall的第三方脚本，下面会说到。
安装meld：
|
1 |
|
下载git-diffall：https://github.com/thenigan/git-diffall
解压，把其中的脚本拷贝到 /usr/bin 目录下：
|
1 |
|
然后配置git的difftool：
|
1 2 |
|
现在回到一个项目的目录下，比较一个文件的当前工作版本与master中的版本的差异：
|
1 |
|
最后一个参数也可以是一个目录，这样就会比较一个目录的差异（太赏心悦目了）。
每次执行此命令的时候，都会让用户确认是否加载meld，直接回车即可。
然后，在弹出的Meld界面中，尽情体验强大的Meld带给我们的美妙感觉吧！
文章来源：http://www.codelast.com/
（13）撤消修改的几种情况
在SVN中，修改了一个文件之后，还没有提交的话，我们可以用 svn revert your_file 命令，来撤消我们对文件 your_file 所做的修改，使之恢复到没修改之前的状态。但是在Git中，等价的命令是什么呢？在很少使用git之前，我也有这个问题，于是我到Google上一搜“svn revert git”，搜出来很多人都在问这个问题，其实要理解好这个问题，需要先理解好git有工作区、暂存区（stage）的概念，而SVN没有暂存区的概念，所以，当你刚从SVN转到Git时，会很困惑为什么Git撤消修改那么麻烦。其实这才是Git强大之处啊。
①修改了一个文件，还没有将它添加到暂存区，此时，要撤消所做的修改：
|
1 |
|
②修改了一个文件，并且已经通过 git add your_file 把它添加到了暂存区，则想把这个文件复原，先要把它从暂存区“弄出来”：
|
1 |
|
现在，你再用 git status 命令查看的话，会发现它已经被从暂存区“拿出来”了，变成了没有 git add 的状态，但是，它仍然是我们修改过内容的，要继续撤消我们修改的内容的话，继续像上面一样，用 git checkout -- your_file 命令，即可将你所做的修改完全复原了。
（14）查看每个版本修改的文件
git log 可以查看提交日志，再加一个参数就可以看到每个版本修改的文件都有哪些了：
|
1 |
|
文章来源：http://www.codelast.com/
（15）一次git add所有modified的文件到暂存区
如果你修改了100个文件，那么一个个地 git add 它们到暂存区无异于自虐，此时你需要的是批量add：
|
1 |
|
然后就进入了交互式界面：
|
1 2 |
|
选择2，回车，会列出所有将要被 add 的文件，输入星号（*）并回车（表示选择所有文件），然后又会回到上面的菜单界面，选择7回车退出，这时再用 git status 看一下，是不是所有修改过的文件都添加到了暂存区里了？
（16）利用Bitbucket在两地同步私有代码
与Github不同，Bitbucket可以创建private的代码仓库，这对个人而言非常有用。例如，你在台式机A上写的代码，当你出差到其他城市后，还想在你带的笔记本（记为B）上继续写，那么这时候怎么办？有一个傻傻的办法就是连上电脑A（如果可以的话），然后把整个项目打一个tar包，传到B上，但如果你的整个项目目录非常大，压缩之后仍有几百M，那么你可能需要耗费大量时间来传输。更为可取的一个办法就是利用类似于Bitbucket这样的服务，来同步代码，使得只需要更新少量数据就OK了。
下面是步骤：
|
1 |
|
在A处，将代码push到Bitbucket上：
|
1 |
|
这表示将my-branch这个branch的代码push到Bitbucket上的同名branch下（如果Bitbucket上没有这个branch，将被创建）。
在B处：
|
1 2 |
|
这会将Bitbucket上的最新修改下载到本地——但是并没有merge到本地的任何一个branch上。
在B处，创建同名的branch并切换过去：
|
1 2 |
|
这会将刚才从远程仓库（origin/my-branch）下载回来的最新的代码，merge到当前的branch上，因此，本地的my-branch仓库马上就会变成最新的代码了。
看到的提示信息形如：
|
1 2 3 4 |
|
至此，B的my-branch这个branch上的代码就与A的代码同步了。
上面从git fetch开始的步骤，也可以换一种方法实现：
|
1 2 |
|
这里的git pull在效果上相当于git fetch ＋ git merge的组合。但是第一次运行这个命令的时候，会看到类似于下面的提示：
|
1 2 3 4 5 6 7 8 9 |
|
这说明本地的branch没有和remote的branch关联上，所以git pull不知道“从哪里pull”。根据最后一次的提示，需要执行以下命令：
|
1 |
|
会得到提示：
|
1 |
|
则现在再执行git pull命令，就可以把remote的branch下载下来并且merge到本地的branch中了。
文章来源：http://www.codelast.com/
（17）查看当前版本比上一个版本修改了什么内容
|
1 |
|
其中，HEAD代表当前版本，后面带一个 ^ 号表示其之前一个版本。
（18）Git子命令的自动完成／自动补全
在Ubuntu下用 apt-get install git 安装好Git后，Git的子命令就已经能自动完成了，例如你输入 git ad，然后按 TAB，会发现它被补全成了 git add，但是在Arch Linux ARM下，这个功能却没有，我们可以参考这个链接中的教程自己做。
基本思想就是获取github上的一个 git-completion.bash 脚本，然后把它添加到开机自动执行的脚本中：
|
1 2 |
|
然后编辑 /etc/profile 文件，在最后添加如下代码：
|
1 2 3 |
|
重启系统，搞定，Git已经可以自动完成子命令了。
（19）检出指定版本的某个文件
|
1 |
|
例如：
|
1 |
|
（20）To be added...
文章来源：http://www.codelast.com/
（C）git-svn
git-svn是Subversion 双向桥接工具，用于：Git作为本地的版本控制工具，SVN作为远程的仓库。
有人可能会有疑问：为什么会出现git-svn这个东西？这是由于Git实在是比SVN要好用太多太多了，所以有时候，尽管我们不得不使用远程的SVN仓库来和大家同步工作（例如，你公司的代码库就是SVN的），但是在本地，我们仍然可以使用Git来做版本控制，这就是git-svn工具的作用。
（1）初始化
用SVN作为版本控制工具时，我们检出一个项目，用的是 svn co http://xxx 这样的方法，但是用git-svn时，我们应该这样做：
|
1 |
|
（2）只查看SVN log
git log 命令会列出你的所有git commit日志，但是如果只想看SVN的commit日志，就需要用：
|
1 |
|
但是这样输出的信息可能太杂乱了，可以用如下命令，让一次提交只显示一行信息：
|
1 |
|
（3）本地已经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：
|
1 |
|
在当前branch基础上，再创建一个新的branch，并切换过去：
|
1 |
|
这时，my-branch-to-commit这个分支上也有版本A、B、C了。假设版本A的commit id为d939ac4，则将此分支的HEAD指向版本A：
|
1 |
|
这时，my-branch-to-commit这个分支上，最新的版本就是版本A了，于是，我们可以把它提交到远端的SVN repo中去了：
|
1 |
|
于是我们完成了“提交版本A到SVN”的任务，但是，我们还要在版本B、版本C的基础上继续开发，所以，下面，我们要把这两个版本“找回来”。
先切换回master分支：
|
1 |
|
更新到最新的SVN版本：
|
1 |
|
这时，master分支上已经是版本A的代码了。
再创建一个新的工作分支my-branch-to-continue：
|
1 |
|
这时，git cherry-pick命令就大显神威了，它可以挑选指定版本的修改，并应用到当前分支上，所以，我们需要做的是，把my-branch这个分支中的版本B、版本C的修改cherry-pick过来，应用到my-branch-to-continue分支上。
假设版本B的commit id为c37d531，版本C的commit id为822dbbd，则：
|
1 2 |
|
这会生成两个新的commit。
现在，在my-branch-to-continue这个分支上，我们的状态就是：版本A已经是提交到了SVN，版本B、版本C已经提交到了本地git repo中。
现在可以把my-branch这个分支删掉了，因为它已经没用了：
|
1 |
|
大功告成。