Git 时间，版本控制工具的高级用法

        现在的你对于 Git 应该完全不会感到陌生了吧，通过了之前两节内容的学习，你已经掌握了 Git 中很多的常用命令，像提交代码这种简单的操作相信肯定是难不倒你的。

        那么打开 Git Bash，并进入到 BaiduMapTest 这个项目的根目录，然后执行提交操作：

git init
git add .
git commit -m "First Commit."

        这样就将准备工作完成了，下面就让我们开始学习关于 Git 的高级用法。

1.  分支的用法

        分支是版本控制工具中比较高级且比较重要的一个概念，它主要的作用就是在现有代码的基础上开辟一个分叉口，使得代码可以在主干线和分支线上同时进行开发，且相互之间不会影响。分支的工作原理示意图如图 11.16 所示。

图 11.16

        你也许会有疑惑，为什么需要建立分支呢，只有在主干线上进行开发不是挺好的吗？没错，通常情况下，只在主干线上进行开发是完全没有问题的，不过一旦涉及到出版本的情况，如果不建立分支的话，你就会非常地头疼。举个简单的例子吧，比如说你们公司研发了一款不错的软件，最近刚刚完成，并推出了 1.0 版本。但是领导是不会让你们闲着的，马上提出了新的需求，让你们投入到了 1.1 版本的开发工作当中。过了几个星期，1.1 版本的功能已完成了一半，但是这个时候又用户反馈，之前上线的 1.0 版本发现了几个重大的 bug，严重影响软件的正常使用。领导也相当重视这个问题，要求你们立刻修复这些 bug。因为现在 1.1 版本已开发一半了，如果在现有代码的基础上修复这些 bug，那么更新的 1.0 版本将会带有一半 1.1 版本的功能！

        进退两难了是不是？但是如果你使用了分支的话，就完全不会存在这个让人头疼的问题。你只需要在发布 1.0 版本的时候建立一个分支，然后在主干线上继续开发 1.1 版本的功能。当 1.0 版本上发现任何 bug 的时候，就在分支上进行修改，然后发布新的 1.0 版本，并记得将修改后的代码合并到主干线上。这样的话，不仅可以轻松解决掉 1.0 版本存在的 bug，而且保证了主干线上的代码也已经修复了这些 bug，当 1.1 版本发布时就不会有同样的 bug 存在了。

        说了这么多，相信你也已经意识到分支的重要性了，那么我们马上来学习一下如何在 Git 中操作分支吧。

        分支的英文名是 branch，如果想要查看当前的版本库当中有哪些分支，可以使用 git branch -a 这个命令，结果如图 11.17 所示。

图 11.17

        由于目前 BaiduMapTest 项目中还没有创建过任何分支，因此只有一个 master 分支存在，这也就是前面所说的主干线。接下来我们尝试去创建一个分支，命令如下：

git branch version1.0

        这样就创建了一个名为 version1.0 的分支，我们再次输入 git branch -a 这个命令来检查一下，结果如图 11.18 所示。

图 11.18

        可以看到，果然有一个叫作 version1.0 的分支出现了。你会发现，master 分支的前面有一个 * 号，说明目前我们的代码还是在 master 分支上的，那么怎样才能切换到 version1.0 这个分支上呢？其实也很简单，只需要使用 checkout 命令即可，如下所示：

git checkout version1.0

        再次输入 git branch -a 来进行检查，结果如图 11.19 所示。

图 11.19

        可以看到，我们已经把代码成功切换到 version1.0 这个分支上了。

        需要注意的是，在 version1.0 分支上修改并提交的代码将不会影响到 master 分支。同样的道理，在 master 分支上修改并提交的代码也不会影响到 version1.0 分支。因此，如果我们在 version1.0 分支上修复了一个 bug，在 master 分支上这个 bug 仍然是存在的。这时将修改的代码一行行复制到 master 分支上显然不是一种聪明的做法，最好的办法就是使用 merge 命令来完成合并操作，如下所示：

git checkout master
git merge version1.0

        仅仅这样简单的两行命令，就可以把在 version1.0 分支上修改并提交的内容合并到 master 分支上了。当然，在合并分支的时候还有可能出现代码冲突的情况，这个时候你就需要静下心来慢慢地找出并解决这些冲突，Git 在这里就无法帮助你了。

        最后，当我们不再需要 version1.0 这个分支的时候，可以使用如下命令将这个分支删除掉：

git branch -D version1.0

2.  与远程版本库协作

        可以这样说，如果你是一个人在开发，那么使用版本控制工具就远远无法发挥出它真正强大的功能。没错，所有的版本控制工具最重要的一个特定就是可以使用它来进行团队合作开发。每个人的电脑上都会有一份代码，当团队的某个成员在自己的电脑上编写完成某个功能后，就将代码提交到服务器，其他的成员只需要将服务器上的代码同步到本地，就能保证整个团队所有人的代码都是相同的。这样的话，每个团队成员就可以各司其职，大家共同来完成一个较为庞大的项目。

        那么如何使用 Git 来进行团队合作开发呢？这就需要有一个远程的版本库，团队的每个成员都从这个版本库中获取到最原始的代码，然后各自进行开发，并且以后每次提交的代码都同步到远程版本库上就可以了。另外，团队中的每个成员最好都要养成经常从版本库中获取最新代码的习惯，不然的话，大家的代码就很有可能经常出现冲突。

        比如说现在有一个远程版本库的 Git 地址是 https://github.com/example/test.git，就可以使用如下的命令将代码下载到本地：

git clone https://github.com/example/test.git

        之后你在这份代码的基础上进行了一些修改和提交，那么怎样才能把本地修改的内容同步到远程版本库上呢？这就需要借助 push 命令来完成了，用法如下所示：

git push origin master

        其中 origin 部分指定的是远程版本库的 Git 地址，master 部分指定的是同步到哪一个分支上，上述命令就完成了将本地代码同步到 https://github.com/example/test.git 这个版本库的 master 分支上的功能。

        知道了将本地的修改同步到远程版本库上的方法，接下来我们看一下如何将远程版本库上的修改同步到本地。Git 提供了两种两门来完成此功能，分别是 fetch 和 pull，fetch 的语法规则和 push 是差不多的，如下所示：

git fetch origin master

        执行这个命令后，就会将远程版本库上的代码同步到本地，不过同步下来的代码并不会合并到任何分支上去，而是会存放到一个 origin/master 分支上，这时我们可以通过 diff 命令来查看远程版本库上到底修改了哪些东西：

git diff origin/master

        之后再调用 merge 命令将 origin/master 分支上的修改合并到主分支上即可，如下所示：

git merge origin/master

        而 pull 命令则是相当于将 fetch 和 merge 这两个命令放在一起执行了，它可以从远程版本库上获取最新的代码并且合并到本地，用法如下所示：

git pull origin master

        也许你现在对远程版本库的使用还会感觉比较抽象，没关系，因为暂时我们只是了解了一下命令的用法，还没进行实践，后面你将会对远程版本库的用法有更深一层的认识。

摘自《第一行代码》