30分钟教你轻松使用Git做代码管理

2017-06-20

Git的起源

(故事性内容，不喜跳过，干货往下看)

git的由来说白了，就是一个天才程序员，因为不喜欢传统的代码版本控制工具（集中式）或者喜欢的工具不开源，就自己花了半个月的时间写了这么一个流行至今的“分布式版本控制系统”。

当年，Linux的发明人Linus Torvalds将Linux的源码放置开源社区后，开始接收来自世界各地的志愿者们贡献的代码，并手工合并。可想而知，随着linux社区日益活跃，Linux的源码也更加庞大，这样的手工合并代码的方式越来越困难，也越来越不像程序员的做事风格。

不是早就存在像SVN和CVS这样的自动化代码版本控制工具吗？然而Linus表示，坚决抵制集中式版本控制器。因为集中式的工具不但速度慢，而且如果中央服务器突然宕机，或者没有网络，团队几乎无法提交工作。那Bitkeeper这样强大的分布式版本控制工具呢？事实上，从2002年开始，linus就开始用Bitkeeper管理代码，自此，Linux的发展步伐加快了一倍。

然而，Bitkeeper是一款商业版软件，虽然为开发开源软件的兄弟们提供使用许可，但是同时也限制开源社区不可以开发具备相同功能的软件。但程序员们哪有几个是安份的？开源社区的兄弟们更是如此。Linux和Bitkeeper交往的大好时光持续到2005年，开发Samba的Andrew试图破解BitKeeper的协议，却被Bitmover公司（Bitkeeper的研发公司）发现了，从此收回了在开源社区使用Bitkeeper的许可。

激动人心的时刻来了，Linus和Bitmover公司的CEO Larry McVoy是好朋友，本来可以为社区的兄弟们低个头，向Bitmover认个错，以前怎么哥俩好，今后继续怎么搞。

但是天才就是天才，Linus随后花了半个月的时间用C写了一个分布式版本控制器，并在一个月内将Linux的代码完全由其托管，这个工具就是Git。当然，开源的。

时至今日，Git已经成为了最为流行的代码管理工具。随着Github网站的上线，更是红得一发不可收拾。

Tips:据说去年，Bitkeeper也开源了。

Git vs SVN

上面说了这么多，无非是想表达的对天才程序员的敬佩之情和对开源精神的推崇，虽然自己还只是一个Coder，但也会努力成为一个厉害的Programmer的。

为什么Linus抵制像SVN这样的集中式版本控制呢？Git是分布式的，和集中式的区别究竟在哪呢？我们接下来就来探讨下。上图

SVN开发流程

可以看出，所有的开发者都是通过连接中央服务器进行代码获取或者代码提交的。开发人员之间，必须通过中央服务器来合作开发。中央服务器中保存着完整的版本库，开发者如果要进行版本控制，需要连接网络。若服务器宕机，或者网络中断，开发工作将无法开展。

git_work_flow

而对于分布式的版本控制器，每个人的电脑上都可以保存一份完整的版本库。从remote pull下来最新的代码，如果网络中断，开发人员完全可以在本地做版本回滚和修改提交，再在联网的时候推送到远程仓库。若两名开发人员合作开发一个功能，可以不经过远端服务器就可以相互之间推送修改，合并冲突后，再由某一人推送代码。大大得提高了开发效率。而且如果服务器坏了，数据丢失，没关系，每个人都有完整的版本库，从其他人那里clone一份就ok了。当然，信息安全的问题也就来了。

当然，对于一个项目的开发，选择集中式或者分布式的版本控制并不是关键问题，我认为提高版本控制的决定因素在于良好的分支管理策略，这里还是比较讲究的。有兴趣的同学可以参考《Git权威指南》。

Git初体验

讲了这么多，我们来实际演练下git的操作吧。由于习惯了命令行操作，虽然公司推荐小乌龟，但我还是很傲娇的用git bash

环境搭建

• window10(win7也ok，64bit或者32bit无关紧要，都有对应的git版本)

• git的win版官网下载地址 下载最新版的可以的。30M+，一会就下好了。

• github远端仓库，登陆官网注册，创建一个就好

安装

看到以下画面前一路next(注意设置安装路径)

git_install1

然后按上图进行单选，接着一路next，安装就好了。在新建一个文件夹，进入，在空白处右击，会发现右键菜单多了两个选项，Git GUI here，Git Bash here。选择第二个。进入如下界面

git_bash_gui

这个就是git的命令行界面了。

我利用git提交代码的流程

git在window的安装需要200M+的空间，而在Linux上安装包却非常小，很有可能是因为windows上启动git，首先会启动一个轻量级Linux系统，然后再在其中启动git，你会发现在git bash界面上，你能够使用很多Linux下的代码，包括vim编辑器，有点小激动。
Tips:C://Users/[你的用户名]/目录下面有一个.bashrc文件，这个文件和Linux的.bashrc一样，在启动时加载，配置bash的环境变量，你可以在这里配置java的环境变量，这样就能在git bash使用java命令了。其他软件也是如此。

假设你刚进公司，公司在github上托管了一个开源项目(我刚刚创建一个空的项目)，你需要在上面开发，你首先需要从github上clone一份完整的最新代码。复制下图链接

git_clone_url

然后在git bash敲入如下命令git clone [刚刚复制的链接]，并进入目录。

git_clone_bash

查看code1.txt的内容

code1_content_pre

你已经或得了完整的代码了，现在你可以尝试进行开发。一般这个时候，我会选择新建一个分支，在那个分支上做开发，完成后切换回主分支，合并新建的分支，再提交代码。那什么是分支呢？参考这里吧！

敲入git checkout -b dev来新建一个名为dev的分支。

git_checkout_-b

git checkout 这个命令是用来切换分支的，如果带上了-b选项，就表示新建一个分支。git branch是查看所有分支，分支名前带分号的表示当前所在分支。-a选项表示罗列所有分支，包括本地和远程追踪分支。

**Tips: **在命令后设置-h可以查看命令帮助，--help可以启动浏览器查看更加详细的帮助文档。

好了，分支也建好了，我们可以尝试开发了，我们做如下操作：

1. 在code1.txt中修改第一行，并增加若干行。
2. 新建一个文件，写入一些内容

code1_content_after1

mycode_create

你在项目中添加了新的文件，并且更改了旧的文件，可以通过git diff命令查看修改

git_diff

你发现，对于code1.txt中原本一行的修改，git简单粗暴的记录为删除后，再添加。对于新增的内容记录为增加。是的，git是以行（hang）为单位记录文件的修改。等等，你发现我们刚刚新建的mycode1.txt文件并没有被显示。使用git status命令查看当前工作空间状态

git_status

mycode1.txt是Untracked files，这个文件未被git追踪，你需要通过git add .将你的所有修改、新增、删除添加进工作区的暂存区stage，什么是git的暂存区呢，参考

敲入git add .

git_add

再用git status可以看到，能够看到所有文件的修改了。mycode.txt为新增文件。

现在你完成了你的工作，准备提交所有的修改，敲入git commit -m "一些信息"

git_commit

将代码的变化提交到本地仓库。现在的分支是dev，我们切换回master

git_checkout_master

可以看出，切换回master分支后，你会发现目录下只有code1.txt文件了，自己新建的文件不复存在。（注意：如果在dev分支上没有commit修改，在master分支上能够看到在dev分支上的修改。）

我们以图来分析

git_branch_manage_pic1

这是最开始的状态，只有一个master分支，HEAD指向当前分支的最新版本。

git_branch_manage_pic2

新建一个分支后，同时也切换到dev分支上，此时HEAD指向dev，master和dev的最新版本是一样的。

git_branch_manage_pic3

现在在dev分支上修改，并提交代码，你会发现，dev开始和master分开了，

git_branch_manage_pic4

多次提交代码后，切换回master，此时master的版本早已落后于dev，通过git merge dev命令将dev分支合并进master分支中，以保证版本一致.

git_branch_manage_pic5

git_merge_dev

现在，你可以在将master分支推送的远端仓库的master分支了。

git_push_origin

**Tips: **截图中的命令很仔细的制定了本地分支和远程分支的名字git push origin [local branch]:[remote branch]，事实上，如果使用了git branch --set-upstream [本地分支] [远程分支]关联本地和远端分支后，可以直接简写git push推送代码。git branch -vv可以查看本地和远端分支的关联。

git branch -D dev删除dev分支

git_branch_-D

这大概是我每天最常的一套提交代码的流程，只要没有人碰我修改了的文件，就不会发生代码冲突，一般能够顺利提交（后面会演示冲突的产生和解决办法）。此外，你不会直接提交修改给远端master分支，一般会设置评审分支，日常的代码先提交到评审分支，再发起合并请求，请相关大佬review代码，再合并进master分支。这个还是比较简单的分支管理策略，对于持续发布的项目，分支管理是更加复杂的。具体可以查阅阮一峰的博客，或者搜索“git flow”,"gitlab flow","github flow"关键字。

代码冲突

在多人协作开发的情况下，代码冲突是常有的事，每次辛辛苦苦地修改完bug，增加feature，满心欢喜的推送代码，等着下班回家陪媳妇，结果看到由于代码冲突而导致merge失败的错误，真的有点想shi.

angry

亲亲抱抱举高高，没什么大不了。下面我就以我的经验，演示下冲突的产生，以及解决办法。

情况1：研发A修改了code1.txt文件并合并到master，此时研发B修改了mycode1.txt文件，想要合并到master（A已经合并）

devA_edit_code1

在code1.txt中增加新内容

git_merge_devA

提交修改，并切换回master分支，merge devA

devB_edit_mycode1

checkout devB分支，修改mycode1.txt内容

git_merge_devB

再提交修改，并切换回master，合并devB

合并成功，这是不会发生冲突的。因此，如果每个人修改的不同的代码文件都，合并是不会发生冲突的。

情况2：研发A和研发B合作开发新功能，A修改了code1.txt文件并合并到master，此时B在他的分支上也修改了code1.txt文件，想要合并到master（A已经合并）

devA_edit_code1_2

修改完code1.txt后，devA提交修改，并切换到master，合并devA

devB_edit_code1

切换到devB，由于没有更新代码，你发现devB分支上的code1.txt文件没有devA之前修改的痕迹，同样的，devA分支上的mycode1.txt也没有devB的修改。修改code1.txt，增加一行内容。

emerge_conflict

切换回master，进行合并发现代码冲突，合并失败。此时右下角显示merging状态。激动人心的时刻到了！

神秘的微笑

conflict_git_status

这个时候使用git status命令可以看到，code1.txt被同时修改了，所以产生冲突。继续使用git diff命令查看code1.txt中的冲突

conflict_git_diff

命令行中看到上面这样的内容，第一反应是崩溃的，本能的就会抵制继续往下看，而开始寻找好用的GUI工具。这就是人们对未知事物的本能反应，抗拒。其实读懂这些符号就没啥了。这些内容是实实在在得写在了文件中的，在实际的工程中，如果有实时编译的IDE，立马就会报错。我们用vim编辑code1.txt，以图解决冲突。

conflict_solve1

第一部分是冲突中HEAD的修改，现在在master分支，自然是指master的修改。第二部分就是devB的修改。

conflict_solve2

简单粗暴的删除git自动添加的符号，完成冲突解决。注意：实际开发中，冲突的解决还是的小心一点，两个人当面核对代码冲突还是很有必要的。如果不能见面沟通，最好是在理解对方的修改后，再解决冲突。否则弄丢了对方辛辛苦苦修改的代码，还是很崩溃的。

conflict_git_merge

之后将修改add进暂存区，然后commit。merge会自动完成。git log可以查看版本历史

一般在工程中，推送代码前，重新从远端仓库pull一份新的代码，和本地分支做合并，在本地解决冲突后，再推送到远程仓库。