一些Git的基本概念和用法（rebase、HEAD、reset、master、remote、pull、push、force等）

由于之前在一个相对封闭且各方面的IT流程都相对完善的公司工作，公司内部总是习惯使用非常成熟的IT工具，不会很快引入外部的新的更高效的生产工具，因此对一些业界已经普及使用的IT工具接触总是会慢很多。除了工作时间，也没有太多机会接触外部的东西，对git的了解比较晚。本人也是从完全不懂Git(只会从github下载master分支的zip包来看源码^_^)，到会用pull、push，再后面也会一些稍微高级一点的用法，如rebase、reset、合并或者修改已有commits等。在这个边学边用的过程中也遇到过一些困惑和曲解，这里系统的整理一下一些常用方法和涉及的概念，希望对新接触这个的Coder能有所帮助。

一、复制或者克隆一个库

一般而言，我们从下载或者复制一个库开始。在github等平台上，使用Fork这个动作复制远端的库到自己名下，复制出来的库跟源库之间有派生关系，可以提交MergeRequest（github上面称为PullRequest，个人觉得这个叫法让人费解，容易产生歧义。）合并代码到源库，MR审核通过后即合入，因此一般正式的版本库中是不能轻易直接push commits的。

要下载远端的代码到本地，则需要在本地git clone远端代码库。git clone可以指定版本下载。clone的过程即在本地建立了一个本地git库。同样本地的这个库与远端的库也是有派生关系，共祖先。Fork和clone后，使得一个本地库可以跟多个远端库有继承关系，因此一个本地库可以配置多个源，这个源也就是remote，每个源有一个容易记的名字，还有其地址。地址又有两种方式，https和ssh，可根据需要选用。

二、提交修改目标库

在本地，先切换到需要修改代码的分支，使用git checkout命令，可以将当前工作的代码切换到指定的分支上面。本地编辑代码后，使用git commit命令生成一条提交记录，该提交记录在本地的分支上面，如果需要同步到远端，那么需要push到远端代码库。到此为止一共提到了3个git库：源库，fork到自己名下的远端库，本地库。任意两个库之间需要增量同步代码都需要MR或者本地库可以push到远端。 通常远端库有多人在合入代码时，如果本地的修改不是基于远端当前最新版本修改的，那么push会报错，提示需要先pull远端的库到本地。此时最常见的是，执行一次pull命令，如果远端的修改与本地的修改不冲突，或者git能自动解决冲突（复杂情况下并不能保证业务逻辑不出问题。），那么此时就顺利将远端比本端多的commits合并到本地了，这个过程其实跟svn等管理工具原理是完全一样的。如果不能自动合并，那么需要手工解决冲突，此时在额外产生的解决conflict的commit中会记录两边的修改。提交后，再push即可。值得注意的是，无论是否有手动解决冲突，都会产生一条merge commit，并且每一次git pull都会产生一条，无论是否有实质性的commit合入。大多数情况下，我们掌握了git checkout、git commit、git pull、git push就够日常开发用了。

三、git rebase的用法

有时候，刚才提到的merge commit并不友好，并且是不需要的，希望代码历史有一个清晰的合入过程，那么git也提供了另一个思路解决问题。即git rebase，rebase的思想，顾名思义，就是将当前分支以目标分支为基，重新组织本地多出来的那些commits，让本地的修改永远保持在整个版本树的最上层，即always commit at the top。git的做法并不是简单的将本地的所有commits合并在一起，而是相当于在目标分支上面一一“重放”每个commit，默认情况下所有commit的时间信息会被重写，但是提交人和提交message等不会重写。rebase带来的一个问题是，可能解决冲突的次数会增多，每一个commit可能都需要解决一次。如果commits过多，那么不适合这种方式，或许直接pull远端是更好的选择，所以本地的commit不要太多，rebase要勤做，在rebase的过程中合并多余的commits。rebase之后，如果原来的本地分支已经push到远端，那么新的本地分支则跟远端的分支不在有完整的继承关系，而是从某个点就分叉了，此时可以选择将新的本地分支push到一个全新的远程分支，基于新的分支来工作。也可以考虑push -force原分支，注意push force等于强制覆盖远端分支，远端分支上面的记录将丢失。如果对rebase过程不是特别了解，或者对解决冲突的过程中的修改不放心，那么建议备份远端分支和rebase之前的本地分支。

四、高级用法，合并commits，修改指定commit

上面介绍了rebase的基本思想和用法，其实基于rebase，还有更多高级用法。比如，修改一个已经提交的commit。rebase的过程中允许交互，在开始rebase之前，git会自动分析出哪些commit是比目标端多的，一一列出，给用户选择每个commit的处理方式，有三种选择：

• 保留 pick p
• 编辑 edit e
• 合并到下一条 squash s

用的最多的是保留和合并，编辑的时候一般很少。还有一种是skip，标准的流程里面并没有此项，在git tortoise界面上提供了此选项，也非常有用。如果选择的是编辑，则在rebase的过程中，当处理到该commit的时候，会给出修改代码的机会。此时需要先将代码重置到父版本，然后将本commit的修改直接置位未提交状态，使用git reset HEAD^即可。其中Head代表当前的最新版本，^代表父版本。^和~的含义可以参考：链接。修改好后，提交commit，此时即可重新生成所有的commit信息，相当于对原commit进行了修改。