Git使用总结

详细教程请参考：http://www.yiibai.com/git/git_push.html

本文是本人依据项目中使用的常用命令结合互联网的学习总结。

Git与SVN的不同

SVN（Subversion）是当前使用最多的版本控制工具。与它相比较，Git 最大的优势在于两点：易于本地增加分支和分布式的特性。

下面两幅图可以形象的展示Git与SVN的不同之处

 

图中Git本地和服务器端结构都很灵活，所有版本都存储在一个目录中，你只需要进行分支的切换即可达到在某个分支工作的效果。而 SVN则完全不同，如果你需要在本地试验

一些自己的代码，只能本地维护多个不同的拷贝，每个拷贝对应一个SVN服务器地址。举一个实际的例子，以前我所在 的小组使用SVN作为版本控制工具，当我正在试图增强一

个模块，工作做到一半，由于会改变原模块的行为导致代码服务器上许多测试的失败，所以并没有提交代 码。这时候上级对我说，现在有一个很紧急的Bug需要处理， 必须在

两个小时内完成。我只好将本地的所有修改diff，并输出成为一个patch文 件，然后回滚有关当前任务的所有代码，再开始修改Bug的任务，等到修改好后，在将patch应用回

来。前前后后要完成多个繁琐的步骤，这还不计中间代码 发生冲突所要进行的工作量。可是如果使用Git， 我们只需要开一个分支或者转回到主分支上，就可以随时开始Bug修

改的任务，完成之后，只要切换到原来的分支就可以优雅的继续以前的任务。只要你愿意，每 一个新的任务都可以开一个分支，完成后，再将它合并到主分支上，轻松而优雅。

分布式对于Git而言，你可以本地提交代码，所以在上面的图 中，Git有利于将一个大任务分解，进行本地的多次提交，而SVN只能在本地进行大量的一次性更改(因为要保证提交

的代码可以正常运行)，导致将来合并到主干上造成巨大的风险。Git的代码日 志是在本地的，可以随时查看。SVN的日志在服务器上的，每次查看日志需要先从服务器上下载下

来。我工作的小组，代码服务器在美国，每次查看小组几年前所 做的工作时，日志下载就需要十分钟，这不能不说是一个痛苦。后来我们迁移到Git上，利用Git日志在本地的特

性，我用Ruby编写了一个Rake脚本， 可以查看某个具体任务的所有代码历史，每次只需要几秒钟，大大方便我的工作。当然分布式并不是说用了Git就不需要一个代码中心服务

器，如果你工作在一个 团队里，还是需要一个服务器来保存所有的代码的。

Git 通常有两种方式来进行初始化:

git clone: 这是较为简单的一种初始化方式，当你已经有一个远程的Git版本库，只需要在本地克隆一份

例如：git clone git://github.com/someone/some_project.git  some_project

上面的命令就是将'git://lu.github.com/some_project.git'这个URL地址的远程版本库完全克隆到本地some_project目录下面

git init和git remote：这种方式稍微复杂一些，在此不仅行介绍。

1、pull代码时用 git pull --rebase

当本地commit一个提交和远端服务器中的代码有冲突(别人也改了相同的文件)时可以在pull 中加 –rebase。加上 rebase 的意思是：git pull --rebase合并远端的代码到本地，如遇到冲突的地方需要手动解决（--rebase），相当于SVN上的update合并前：      D---E master     /A---B---C---F origin/master使用 merge 合并后：      D--------E       /          \A---B---C---F----G   master, origin/master如果是 rebase 的方式，就不會有 G 合并点：A---B---C---F---D'---E'   master, origin/master注意到，其中 D’, E’ 的 commit SHA 序号跟本來 D, E 是不同的，应为算是砍掉重新 commit 了。

<h2 class="sectionedit2" id="rebase_vs_merge"><span style="font-size:18px;">rebase VS merge</span></h2><div class="level2"><p>rebase 跟 merge 类似，出现 conflict 会暂停 rebase 动作，需要你手动修复后，然后才可以继续动作。这也是 rebase 比 merge 复杂一点的地方：merge 如果发生 conflict，你只需要解决冲突一次，然后commit 出去就完成了。而 rebase 的 conflict 可能会发生在上述步骤 4 的每一次重新套用上，所以可能需要解决冲突好几次 (rebase 时所谓的解决冲突，其实是直接修改你之前的变更內容，所以上图中变成 D’ 跟 E’ )。</p></div>

2、新建分支（branch）
        git checkout <master/父分支名>
        git pull --rebase
        git branch <dev_新分支名>
        git push -u origin <dev_新分支名>
        git checkout <dev_新分支名>

$ git push <远程主机名> <本地分支名>:<远程分支名>