git入门手册：git的基本安装，本地库管理，远程上传

前言：

　　　　　git是分布式的版本库控制系统，它能方便你将自己的代码寄存于远程服务器上，从而实现集体合作开发。git有GUI

　　　图形界面，然而使用终端命令仍是主流。以下基于Ubuntu系统操作git（其方式也适用于windows等系统），实现git的基

　　　本安装,关联github账户，本地创建及更改库，分支，连接远程版本库。

　　　　　本文章讲解了一般需要用到的命令，以及更重要的——git管理代码的机制。由于本人知识有限，若有错误，望

　　　指出和谅解。

第一节 git安装：

ubuntu下的安装：

　　　 ubuntu默认没有安装git,alt+ctrl+t打开终端，运行下面命令来安装:　　

　　　　检查是否安装成功：

　　　　未报错就代表成功安装。

第二节 git配置设置：

　　以下设置只要设置一遍，以后不用重新设置

用户名及邮箱：

其他配置：

　　　　启用git输出显示颜色

　　　　设置git编辑器（默认为vim）

第三节关联github账户：

获取ssh密钥：

　　　　之后一路回车即可

　　　　密钥保存在home/.ssh/id_rsa.pub文件里（home目录下.ssh是隐藏的，按快捷键ctrl+h显示）

添加密钥至github：

　　　　复制密钥，打开浏览器登录你的github账户，在setting>SSH and GPG keys 里添加密钥即可。

第四节本地版本库创建：

　　提示：使用git --help或者git 命令 --help获取帮助。

git三大工作区域：

　　　　1.工作目录：即本地目录，是可以看到的，供用户编辑更改代码文档。

　　　　2.暂存区：所在目录为.git/index,所有工作目录中的更改要先提交到暂存区，才能让版本库接受。

　　 3.版本库:所在目录为.git/objects。是所有代码的集中区域，记录用户提交的更改。

创建空的本地版本库：

　　　　 git init 命令：将普通文件夹mypro初始化为空的版本库。

　　　　执行以上命令后会发现mypro文件夹下出现一个隐藏文件夹.git，这就是git仓库储存文件的地方。

　　　　也可以删除库（读者可以不删除它，因为下面还需要一个空仓库）

　　　　实际上就是把mypro文件夹删掉即可

克隆远端版本库：

　　　　这是创建本地版本库的另一种方式，也是最常用的方式，用此方法我们可以克隆他人的版本库进行学习

　　　　和使用，我们这里还是以自己github上的版本库为例。

　　　　git clone +仓库地址就可以克隆了，当然你也可以为克隆的版本库重命名（如果没删除过mypro，可以重

　　　　名为成其他名称）：

第五节更新本地版本库：

创建与更改文件：

　　　在工作目录mypro下新建一个名为hello的文档

　　　　终端下输入git status 查看工作目录的状态：

　　　　发现有红色的hello，说明虽然我们创建了hello文档,但属于未跟踪状态，但版本库并未记录下这次创建.

　　　　下面，我们进行同步（正如前面所说，要将更改提交到库，必须先提交到暂存区）：

　　　　git add +文件名:提交更改到暂存区。

　　　　 git commit -m "更改说明" :将暂存区的所有更改提交到库。

　　　　当提交到暂存区后,出现“新文件：hello”,表示更改已经被跟踪记录，但还未正式提交到库，git status比较的

　　　　永远是版本库与工作目录的不同。

　　　　让我们在正式提交更改后再看一下工作区状态：

　　　　因为此时版本库与工作目录是同步的，所以工作区状态为无。

　　　　接下来，我们来更改hello文件内容，添加"hello!"：

　　　　请读者自行查看工作区状态（在大型开发中这是非常必要的），这次显示的是“更改：hello”,所以可以看出，git

　　　　对于更改是有明确分类的。

　　　　请读者将更改提交到库，注释为“fill the context”。

查看更改提交历史：

　　　　 1.git show 可以查看最近一次更改的具体内容：

　　　　　commit这一行是为更改分配的指针(专业名叫sha-1值，下文都以sha-1值称呼)，它指向这次更改。

　　　　　 “fill the context “是用户添加的更改的说明。

　　　　　 ---a/hello代表更改前的hello被代替了.

　　　　　 +++b/hello代表更改厚的hello，下面两行是更改的内容，第一行可以知道被更改的行数，最后一行表示增加了

　　　　　　"hello!"一行。

　　　 2.git log 可以查看历史记录（输入wq后即可退出查看）：

　　　　　这里显示我们一共更改了两次，commit 后面是指向本次更改的sha-1值。

回退操作：

　　　　有时候，我们想撤销提交，git有强大的回退操作：

　　　　 1.从版本库回退到暂存区（相当于撤销git commit操作）:

　　　　　其中HEAD是一个指针，在我们回退前，它指向最后一次更改的指针（24ffa3c...读者可在上文看到这个指针）,

　　　　　　DAED～1 表示指针回退一个历史点，指向上一次更改的指针（ce169e0...读者可以使用git log查看，可以发现ce169e0...

　　　　　　变成了第一个）（注意：读者的指针同我的是不同的）。

　　　　　　下面请读者输入git commit -m "fill the context"恢复到回退前(此时会分配一个新的指针)，然后在hello文档结尾加一

　　　　　　句“how are you”,最后提交到库，提交说明为“change the context”，之后git log会发现有三次更改。

　　　　　　以上完成后，我们尝试让HEAD回退两个历史点（应该会认为结果同上面的回退是一样的，即hello文档里有“hello!”,hello文

　　　　　　档已提交到暂存区，但未提交到库）。

　　　　可以看到，确实回退到了创建文档之后的第一次更改，但是回退时我们的第二次更改却没有被删除。

　　　　　　git diff --cached +sha-1值：可以对比暂存区的文档与库中某一提交点的该文档之间的区别，这里的sha-1值

　　　　　　指向创建文档的更改，那时hello文档还没有内容。

　　　　　　关于如何回退时删除第二次更改，我将在下面讲到，现在让我们提交更改到库,操作如下：

　　　　2.回退到工作目录：

　　　　成功回退到工作目录，请读者执行git checkout hello命令，放弃更改的提交。

　　　　　 git checkout +文件适用于工作目录下更改（只能是修改不能是创建）过的，未提交到暂存区的文件的回退。

　　　　　　那么提交到暂存区的文件如何回退到工作目录呢？

　　　　　　当然是用git reset --mixed HEAD了（git reset HEAD默认是--mixed）,为什么呢？首先，--mix的作用就是回退到

　　　　　　工作目录，其次HEAD后面没跟参数，表示指向当前的sha-1值（下面实例中为68698...）,下面是一个例子：

　　　　　　回退前：

　　　　　回退后：

　　　　　那么为什么没有git reset --soft HEAD命令呢？因为当从库回退到暂存状态时，对于库来说，放弃了这次更改，HEAD

　　　　　就要指向上一次更改(e59b54...)，所以这里应该指定HEAD~1。

　　 3.回退至上次更改：

　　　　操作前请提交三次hello的更改(请不要嫌麻烦，这至少有利于熟悉git 命令)：

　　　　第一次添加“hello!”,注释为“fill after mixedreset”;

　　　　　第二次添加“how are you? ”，注释为“change1 after mixedreset”;

　　　　第三次添加“i'm fine.”,注释为“change2 after mixedreset”;

　　　　更改结果如下：

　　　　　我们想彻底放弃第三次更改，而这次更改已经提交到库：

　　　　我们看到状态回退到我们第二次提交更改后的时候了。

　　　　 git log --oneline:oneline参数可以简化信息。

　　　　现在可以回答上文提出的多历史点回退问题：

　　　　　请读者输入下图中的代码：

　　　　上面代码中，我们先用hard放弃了第二次的更改，然后再用soft回退，这样去掉了第二次更改，保留了第一次更改。

　　　4.小结：

　　　　至此，回退操作已经讲完了，需要注意的是，soft一般用于回退一个历史点（尽管上文举过回退两个的例子，但很容易发现

　　　　这样的回退是没有意义的），适用于提交到库的更改;--mixed 一般用于不回退历史点或一个历史点，分别适用于提交到库的

　　　　更改和暂存的更改;checkout不回退历史点，适用于未暂存的更改;--hard一般用于回退一个或多个历史点，具有强制性与普适性。

拓展：

　　　1.使用git log -g --oneline（-g参数可以列出所有分配过的sha-1值所对应的更改）：

　　　　　通过上图对比（这些是我们上文操作的所有历史记录，读者可以根据这些记录回忆之前的操作，其中HEAD@{2}和HEAD@{3}是

　　　　　由于本人操作失误撤销回退产生的，下文也会讲如何撤销回退），可以发现，不加g参数当回退的时候就会丢弃一些记录，而加

　　　　　上g参数则会显示所有记录(-g代表全局,在之后的分支管理中是很重要的)。

　　　2.使用sha-1值回退:在回退操作讲解中，我们之前使用的都是HEAD~，但也可以使用sha~1值

　　　　　我们用sha-1值重新实现拓展1中操作,代码输入如下（这里选择了静默执行）：

　　　　结果如下：

第六节分支管理：

　　分支无论在本地库管理，还是大型项目集体开发，都是非常有效的管理方式。

本地创建删除与切换分支：

　　　库在初始化后默认有一个master分支（主分支），事实上我们之前的所有操作都是在master上进行的，那么我们可以在master分支上

　　　　衍生出一个小分支（子支），而对于这个子支来说，master就是它的父支。

　　　　下面我们就来创建两个新的分支：

　　　　git branch 分支名：在当前分之下创建一个子支；

　　　　git checkout 分支名：切换到某分支；

　　　　git branch:查看所有分支；

　　　　上面我们在master下创建了分支dev，dev就是master的一个副本,然后又在dev分支下创建了dev-1分支（*标注标志当前所在分支）；

　　　　请读者在dev分支下提交hello的修改（之前回退到了暂存区），注释为“fill at dev”：

　　　　通过上图可以发现，由于dev是master的一个副本，当在dev下提交修改时，master并不会被影响。

　　　　再比较dev与dev-1:

　　　　这次我们用上文学过的git diff比较，发现dev-1也没有被影响，因此可以知道，分支间在创建后就各自独立。

　　　　我们可以删除不想要的分支，删除前需要切换到另一支分支，否则无法删除（此时我们处于master，要删除Dev-1分支）：

分支合并：

　　　　有分必有合，我们创建分支的目的有三种：

　　　　　　1.利用创建的分支做一些不确定的更改，而不影响到原来的分支。

　　　　　　2.利用某个分支实现某个功能模块，从而利于版本管理。

　　　　　　3.团队合作中，远程库作为根，并从根上为每个人员分配一个分支。

　　　　首先，我们将dev合并到master上（要求当前分支为master，了解两个分支的更改差异）：

　　　　这样就使得master与dev同步了。

　　　　如果要取消合并，可以使用回退操作,如下：

　　　　这里的Orig_head指上一次head所指的位置。

　　　　可以通过下面命令查看未合并的分支（即存在更改差异的）：

第七节远程操作：

　　　　第二节中我们已经关联了github账户，一个github账户能够添加多个ssh秘钥，这样多个人就可以提交到同一个github仓库。

建立连接与推送文件：

　　　　首先，要建立连接，并提交文件到github:

　　　　git remote add origin 仓库地址：加入远程仓库地址（并没有连接，如果地址有错，将不会发现），将远程仓库定义为origin,注意，如果

　　　　执行此命令前已经有过一个origin了，要先执行git remote remove origin删除原来的origin。

　　　　下面就可以推送文件了：

　　　　git push origin master:表示将本地的master同步到远程origin的master主分支上（你可以看图片最后一行）。

拉取文件：

　　　　作为B员工，当有新的项目时，首先要做的是克隆远程库（git clone）,而之后当远程库有新的文件提交后，每个员工在提交自己的代码前都

　　　　应该先拉取远程库的文件，使本地库得到更新，此时不能使用git clone，而是git pull,如图:

　　　　该比命令表示拉取远程库的master分支保存到本地master（由于当前分支为master，所以本地分支省略了），也可以拉取远程库的develop分支并保存到

　　　　本地develop分支：

　　　　但是，这种方法的拉取并不安全，他会直接覆本地同名文件，而并没有征求用户的同意，下面的方式相对是安全的:

　　　　git fetch的格式与pull类似。但是fetch后，你无论是用git status还是git log都看不到拉取的文件，这是因为，fecth建立的是引用，你可以通过

　　　　git log FECTCH_HEAD命令查看远程分支的更改，如果决定接受同步，可以输入git merge origin/master来合并分支。

第八节分支策略与工作流：

　　　　本节我们将简单的模拟一个开发项目，以展现git在团队开发中的强大管理功能，在模拟中，读者应将该模拟想象成一个庞大的开发项目，关注

　　　　分支策略，分工模式等。

　　　　在这之前，我们先来了解最基本的分支策略规定，由于现实开发的需要，每个团队可能采用的分支方式都有差异，但基本上都基于下面的规则：　　

　　　　master:主分支，永远是最稳定的分支，不应该直接在该分支上进行开发，该分支在每一时刻都是作为某个版本的产品供用户使用。

　　　　develop:开发分支，从master中分离出来，用于存放开发者写的、相对稳定的、具有一定功能的代码。当该分支功能集全并测试后，合并到master分支。

　　　　以上两个分支在远程和本地都存在。

　　　　feature:功能分支,开发者的主要阵地，是开发者为开发某个功能模块，而在本地从develop分支分离出的分支，当功能写完后，合并到develop分支，并

　　　　删除feature分支。

　　　　hotfix：修复分支，当已发行的版本存在bug需要修复时，从master分支分离出，完成修复后,合并到master与develop分支，并删除hotfix分支。

　　　　release分支：预发布分支,从develop分离，新版本发布前的调整与测试分支，可以进行细小的bug修复，修复完后,合并到master和develop分支，版本发

　　　　布后，删除改分支。

　　　　现在，让我们通过一个简单的实例了解分支策略与工作流。

　　　　1.boss在github上创建了一个项目仓库，以提交readme.txt初始化仓库,此时已经有master分支了，boss还要给员工们（张三，李四）分配develop分支，这

　　　　　些都可以在github上直接操作。

　　　　2.下面boss,提交了一份已经写好的index.html文件：

　　　　3.员工张三，李四分别克隆仓库（克隆只会克隆master分支），并拉取了develop分支（以张三为例）：

　　　　4.张三，李四分别从本地develop分支上分离出feature分支，并开发自己的功能模块，开发完成后合并到本地和远程的develop分支（以张三为例）：

　　　　远端状态：

　　　　5.假如李四写得较慢，当张三提交develop后，李四需要先将develop再拉取一下，更新自己的develop和feature，才能提交：

　　　　得知远程develop有更新后,先更新后commit:

　　　　远端状态：

　　　　6.此时，版本1的所有功能都开发完毕，boss在本地创建realease分支进行测试，而此时员工又可以进行版本2功能的开发，我们来看一下最终版本1的公布过程：

　　　　打上v1.0的标签，以便之后的跟踪：

　　　　查看远程状态：

　　　　7.然而，正当员工们兴致勃勃地开发下一个版本时，有用户抱怨v1.0的一个bug，而距v2.0成功开发完成还有很长时间。为了尽快解决这个情况，boss决定让张三

　　　　放下功能模块的开发，来解决这个bug：

　　　　　如上图，如果直接先git add再切到其他分支来修复bug,会使得feature3.js也被跟踪,此时明智的方法是使用 git stash:

　　　　然后张三就可以修改bug了，在修改完后,合并master分支，并发布v1.1：

　　　　终于，bug修复完了，张三又可以高高兴兴地去开发他的功能模块了：

后记：

　　　　到此git的学习结束了,但是你只是入门而已，还需要不停地实践与学习去感受git与github的魅力，比如浏览学习github上优秀的开原项目，git高级合并等等。

　　　　下面我列出了一些可以参考学习的网站，希望能进一步帮助你：

　　　最后，感谢读者的阅读，有不当之处，望请包涵！