版本控制系统GIT文档

版本控制系统GIT文档

李达 20180629

引用博客教程+实践总结

目录
1.     版本控制系统... 2
1.1.      简介... 2
1.2.      常见的版本控制器... 3
1.3.      版本控制分类... 4
1.3.1.       本地版本控制... 4
1.3.2.       集中版本控制（SVN）... 4
1.3.3.       分布式版本控制(GIT) 5
1.3.4.       集中式和分布式的比较... 6
1.4.      Git与github. 7
2.     Git系统... 7
2.1.      工作区域... 7
2.2.      文件的流转控制... 8
2.3.      版本分支管理... 9
2.3.1.       分支策略... 11
2.4.      多人协作... 11
2.5.      标签管理... 12
3.     Git实践... 12
3.1.      工作模式设计... 12
3.2.      实践项目git环境搭建... 13
3.2.1.       安装git 13
3.2.2.       创建远程仓库... 13
3.2.3.       项目git初始化... 13
3.2.4.       项目忽略文件... 17
3.2.5.       开发人员初始化项目环境... 18
3.2.6.       IDE的git插件... 18
3.3.      实践：项目git流程... 20
命令LIST：... 21
Refer：... 31

 

1.版本控制系统

1.1 简介

    什么是版本控制系统？

    如果你用Microsoft Word写过长篇大论，那你一定有这样的经历：

    想删除一个段落，又怕将来想恢复找不回来怎么办？有办法，先把当前文件“另存为……”一个新的Word文件，再接着改，改到一定程度，再“另存为……”一个新文件，这样一直改下去，最后你的Word文档变成了这样：

    过了一周，你想找回被删除的文字，但是已经记不清删除前保存在哪个文件里了，只好一个一个文件去找，真麻烦。

    看着一堆乱七八糟的文件，想保留最新的一个，然后把其他的删掉，又怕哪天会用上，还不敢删，真郁闷。

更要命的是，有些部分需要你的财务同事帮助填写，于是你把文件Copy到U盘里给她（也可能通过Email发送一份给她），然后，你继续修改Word文件。一天后，同事再把Word文件传给你，此时，你必须想想，发给她之后到你收到她的文件期间，你作了哪些改动，得把你的改动和她的部分合并，真困难。

    于是你想，如果有一个软件，不但能自动帮我记录每次文件的改动，还可以让同事协作编辑，这样就不用自己管理一堆类似的文件了，也不需要把文件传来传去。如果想查看某次改动，只需要在软件里瞄一眼就可以，岂不是很方便？

这个软件用起来就应该像这个样子，能记录每次文件的改动：

版本	文件名	用户	说明	日期
1	service.doc	张三	删除了软件服务条款5	7/12 10:38
2	service.doc	张三	增加了License人数限制	7/12 18:09
3	service.doc	李四	财务部门调整了合同金额	7/13 9:51
4	service.doc	张三	延长了免费升级周期	7/14 15:17

    这样，你就结束了手动管理多个“版本”的史前时代，进入到版本控制的20世纪。

    版本控制（Revision control）是一种在开发的过程中用于管理我们对文件、目录或工程等内容的修改历史，方便查看更改历史记录，备份以便恢复以前的版本的软件工程技术。

• 实现跨区域多人协同开发
• 追踪和记载一个或者多个文件的历史记录
• 组织和保护你的源代码和文档
• 统计工作量
• 并行开发、提高开发效率
• 跟踪记录整个软件的开发过程
• 减轻开发人员的负担，节省时间，同时降低人为错误

    简单说就是用于管理多人协同开发项目的技术。

    没有进行版本控制或者版本控制本身缺乏正确的流程管理，在软件开发过程中将会引入很多问题，如软件代码的一致性、软件内容的冗余、软件过程的事物性、软件开发过程中的并发性、软件源代码的安全性，以及软件的整合等问题。

1.2 常见的版本控制器

主流的版本控制器有如下这些：

1. Git
2. SVN（Subversion）
3. CVS（Concurrent Versions System）
4. VSS（Micorosoft Visual SourceSafe）
5. TFS（Team Foundation Server）
6. Visual Studio Online

    版本控制产品非常的多（Perforce、Rational ClearCase、RCS（GNU Revision Control System）、Serena Dimention、SVK、BitKeeper、Monotone、Bazaar、Mercurial、SourceGear Vault），现在影响力最大且使用最广泛的是Git与SVN

1.3 版本控制分类

 

1.3.1 本地版本控制

    记录文件每次的更新，可以对每个版本做一个快照，或是记录补丁文件，适合个人用，如RCS。

1.3.2 集中版本控制（SVN）

 所有的版本数据都保存在服务器上，协同开发者从服务器上同步更新或上传自己的修改

    所有的版本数据都存在服务器上，用户的本地只有自己以前所同步的版本，如果不连网的话，用户就看不到历史版本，也无法切换版本验证问题，或在不同分支工作。而且，所有数据都保存在单一的服务器上，有很大的风险这个服务器会损坏，这样就会丢失所有的数据，当然可以定期备份。代表产品：SVN、CVS、VSS

1.3.3 分布式版本控制(GIT)

    所有版本信息仓库全部同步到本地的每个用户，这样就可以在本地查看所有版本历史，可以离线在本地提交，只需在连网时push到相应的服务器或其他用户那里。由于每个用户那里保存的都是所有的版本数据，只要有一个用户的设备没有问题就可以恢复所有的数据，但这增加了本地存储空间的占用。

1.3.4 集中式和分布式的比较

    先说集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。

    集中式版本控制系统最大的毛病就是必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟，这还不得把人给憋死啊。

    那分布式版本控制系统与集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

    和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。

    在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。

    当然，Git的优势不单是不必联网这么简单，后面我们还会看到Git极其强大的分支管理，把SVN等远远抛在了后面。

1.4 Git与github

GitHub作为免费的远程仓库，是使用git技术的互联网级别的一个远程的git仓库，是一个git代码托管平台。企业内部完全可以制作自己的git远程仓库，已保证数据安全性问题。

 

2. Git系统

Git是目前世界上最先进的分布式版本控制系统（没有之一）。

2.1 工作区域

    Git本地有四个工作区域：工作目录（Working Directory）、暂存区(Stage/Index)、资源库(Repository或Git Directory)、远程的git仓库(Remote Directory)。

1. workspace 即工作区，逻辑上是本地计算机，还没添加到repository的状态；
2. staging 即版本库中的stage，是暂存区。修改已经添加进repository，但还没有作为commit提交，类似于缓存；
3. Local repository 即版本库中master那个地方。到这一步才算是成功生成一个新版本；
4. Remote repository 则是远程仓库。用来将本地仓库上传到网络，可以用于备份、共享、合作。

2.2 文件的流转控制

    文件在这四个区域之间的转换关系如下：

 

2.3 版本分支管理

    分支就是科幻电影里面的平行宇宙，当你正在电脑前努力学习Git的时候，另一个你正在另一个平行宇宙里努力学习SVN。

    如果两个平行宇宙互不干扰，那对现在的你也没啥影响。不过，在某个时间点，两个平行宇宙合并了，结果，你既学会了Git又学会了SVN！

    分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

    现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

    其他版本控制系统如SVN等都有分支管理，但是用过之后你会发现，这些版本控制系统创建和切换分支比蜗牛还慢，简直让人无法忍受，结果分支功能成了摆设，大家都不去用。

    但Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

 

2.3.1 分支策略

    在实际开发中，我们应该按照几个基本原则进行分支管理：

    首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

    那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

    你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

2.4 多人协作

多人协作的工作模式通常是这样：

1. 首先，可以试图用git push origin <branch-name>推送自己的修改；
2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
3. 如果合并有冲突，则解决冲突，并在本地提交；
4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

    如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

    这就是多人协作的工作模式，一旦熟悉了，就非常简单。

2.5 标签管理

    发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

    Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

 Git有commit，为什么还要引入tag？

“请把上周一的那个版本打包发布，commit号是6a5819e...”

“一串乱七八糟的数字不好找！”

如果换一个办法：

“请把上周一的那个版本打包发布，版本号是v1.2”

“好的，按照tag v1.2查找commit就行！”

所以，tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。

3. Git实践

3.1 工作模式设计

==》 项目开发

==》 多人协作

==》 统一内部git远程库（无需高可用，人人都是版本库），在办公网段即可

==》 频繁简捷代码合并，提交历史保留提交人、修改内容，可恢复可撤销

==》 实时快捷冲突处理

==》 阶段里程碑打标签，历史版本控制

==》 新功能、bug处理分支使用，不影响主分支版本

==》 里程碑入svn库，跨网络提交。

3.2 实践项目git环境搭建

3.2.1 安装git

在工作网段的192.168.68.234服务器上安装git系统：

• yum install git

也可以下载git安装包：

• wget https://www.kernel.org/pub/software/scm/git/git-2.7.3.tar.gz

然后进行相应的安装，不过需要先安装依赖包，配置config文件等。

如果是window或其他版本linux系统或os操作系统，安装都是非常简单的，自行发挥即可。在window上还有图形界面进行支持，不错不建议用，因为git对图形界面的支持不够好。

3.2.2 创建远程仓库

创建目录作为远程库仓库的根路径，比如/home/git/lida.git，进入目录内，可创建两种仓库：

创建镜像库：在目录下看不到内容，内容都在版本库里（建议）

• git init –bare

创建普通仓库，和本地的git库形式相同（不建议，因为不应该到远程仓库进行文本操作）

• git init

3.2.3 项目git初始化

本地电脑环境按照git：自行尝试

如果已有项目目录或还没有，都到相应目录下，执行git初始化命令：

• git init

查看当前git版本文件的情况：

• git status

提示有文件未被追踪管理，提示：红色为未被跟踪的文件；

添加到缓冲区

• git add .

提示：git add . 的点 表示所有；绿色表示已经提交到缓冲区；

提交到本地代码仓库

• Git commit –m “项目初始化git库”

缓存中的文件提交到本地仓库中。需要按照提示设置名字和email。

本地git仓库推送到远程git仓库

• git remote add origin root@192.168.68.234:/home/git/lida.git

注意：root为服务器账号，后面需要使用密码认证。Git库目录需要有读写权限；

推送本地git仓库到远程git仓库，完成远程仓库的初始化

• git push –u origin master

自此，远程git仓库已经创建并初始化完成，可以进行多人项目开发和版本控制管理了。

• 本地git log如下：

• 远程git仓库git log如下：

3.2.4 项目忽略文件

有些时候我们不想把某些文件纳入版本控制中，比如数据库文件，临时文件，设计文件等，主要有项目下eclipse环境文件等。

在主目录下建立".gitignore"文件，此文件有如下规则：

1. 忽略文件中的空行或以井号（#）开始的行将会被忽略。
2. 可以使用Linux通配符。例如：星号（*）代表任意多个字符，问号（？）代表一个字符，方括号（[abc]）代表可选字符范围，大括号（{string1,string2,...}）代表可选的字符串等。
3. 如果名称的最前面有一个感叹号（!），表示例外规则，将不被忽略。
4. 如果名称的最前面是一个路径分隔符（/），表示要忽略的文件在此目录下，而子目录中的文件不忽略。
5. 如果名称的最后面是一个路径分隔符（/），表示要忽略的是此目录下该名称的子目录，而非文件（默认文件或目录都忽略）。

#为注释 *.txt #忽略所有 .txt结尾的文件 !lib.txt #但lib.txt除外 /temp #仅忽略项目根目录下的TODO文件,不包括其它目录temp build/ #忽略build/目录下的所有文件 doc/*.txt #会忽略 doc/notes.txt 但不包括 doc/server/arch.txt

然后通过 git add /git commit /git push 推送到git远程仓库即可保证这些文件不会被git进行版本的统一管理。

3.2.5 开发人员初始化项目环境

克隆远程仓库，命令如下：

• git clone root@192.168.68.234:/home/git/lida.git

Git仓库已经同步到本地，可以进行开发处理了。

3.2.6 IDE的git插件

Eclipse和IDEA等ide工具，都支持git插件，提供界面化的git操作，包括添加、提交、删除、与远程库git pull和git push等操作。对使用IDE的项目开发人员来说，非常方便。

 

3.3 实践：项目git流程

多人协作的工作模式通常是这样：

1. 首先，可以试图用git push origin <branch-name>推送自己的修改；
2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
3. 如果合并有冲突，则解决冲突，并在本地提交；
4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

命令LIST：

#查看系统config
git config --system --list
#查看当前用户(global)配置
git config --global  --list
#查看当前仓库配置信息
git config --local  --list
# 在当前目录新建一个Git代码库
$ git init
# 新建一个目录，将其初始化为Git代码库
$ git init [project-name]
# 克隆一个项目和它的整个代码历史(版本信息)
$ git clone [url]
#查看指定文件状态
git status [filename]
#查看所有文件状态
git status
# 添加指定文件到暂存区
$ git add [file1] [file2] ...
# 添加指定目录到暂存区，包括子目录
$ git add [dir]
# 添加当前目录的所有文件到暂存区
$ git add .
#直接从暂存区删除文件，工作区则不做出改变
git rm --cached <file>
#如果已经用add 命令把文件加入stage了，就先需要从stage中撤销
git reset HEAD <file>...
#移除所有未跟踪文件
#一般会加上参数-df，-d表示包含目录，-f表示强制清除。
git clean [options] 
#只从stage中删除，保留物理文件
git rm --cached readme.txt 
#不但从stage中删除，同时删除物理文件
git rm readme.txt 
#把a.txt改名为b.txt
git mv a.txt b.txt 
#查看文件修改后的差异
git diff [files]
#比较暂存区的文件与之前已经提交过的文件
git diff --cached
#比较repo与工作空间中的文件差异
git diff HEAD~n
#用法一
git checkout [-q] [<commit>] [--] <paths>...
#用法二
git checkout [<branch>]
#用法三
git checkout [-m] [[-b]--orphan] <new_branch>] [<start_point>]
$ git checkout branch
#检出branch分支。要完成图中的三个步骤，更新HEAD以指向branch分支，以及用branch  指向的树更新暂存区和工作区。
$ git checkout
#汇总显示工作区、暂存区与HEAD的差异。
$ git checkout HEAD
#同上
$ git checkout -- filename
#用暂存区中filename文件来覆盖工作区中的filename文件。相当于取消自上次执行git add filename以来(如果执行过)的本地修改。
$ git checkout branch -- filename
#维持HEAD的指向不变。用branch所指向的提交中filename替换暂存区和工作区中相   应的文件。注意会将暂存区和工作区中的filename文件直接覆盖。
$ git checkout -- . 或写作 git checkout .
#注意git checkout 命令后的参数为一个点(“.”)。这条命令最危险！会取消所有本地的  #修改(相对于暂存区)。相当于用暂存区的所有文件直接覆盖本地文件，不给用户任何确认的机会！
$ git checkout commit_id -- file_name
#如果不加commit_id，那么git checkout -- file_name 表示恢复文件到本地版本库中最新的状态。
# 提交暂存区到仓库区
$ git commit -m [message]
# 提交暂存区的指定文件到仓库区
$ git commit [file1] [file2] ... -m [message]
# 提交工作区自上次commit之后的变化，直接到仓库区，跳过了add,对新文件无效
$ git commit -a
# 提交时显示所有diff信息
$ git commit -v
# 使用一次新的commit，替代上一次提交
# 如果代码没有任何新变化，则用来改写上一次commit的提交信息
$ git commit --amend -m [message]
# 重做上一次commit，并包括指定文件的新变化
$ git commit --amend [file1] [file2] ...
#修订提交
git commit --amend
#撤销上一次的提交
git reset --hard HEAD~1
#查看提交日志
git log [<options>] [<revision range>] [[\--] <path>…​]
#查看指定状态的文件
git ls-files [-z] [-t] [-v] (--[cached|deleted|others|ignored|stage|unmerged|killed|modified])* (-[c|d|o|i|s|u|k|m])*
在Git中，有一个HEAD指针指向当前分支中最新的提交。当前版本，我们使用"HEAD^"，那么再钱一个版本可以使用"HEAD^^"，如果想回退到更早的提交，可以使用"HEAD~n"。(也就是，HEAD^=HEAD~1，HEAD^^=HEAD~2)
git reset --hard HEAD^
git reset --hard HEAD~1
git reset --59cf9334cf957535cb328f22a1579b84db0911e5
撤销删除：
#to discard changes in working directory
git checkout -- <file>...
# 列出所有本地分支
$ git branch
# 列出所有远程分支
$ git branch -r
# 列出所有本地分支和远程分支
$ git branch -a
# 新建一个分支，但依然停留在当前分支
$ git branch [branch-name]
# 新建一个分支，并切换到该分支
$ git checkout -b [branch]
# 新建一个分支，指向指定commit
$ git branch [branch] [commit]
# 新建一个分支，与指定的远程分支建立追踪关系
$ git branch --track [branch] [remote-branch]
# 切换到指定分支，并更新工作区
$ git checkout [branch-name]
# 切换到上一个分支
$ git checkout -
# 建立追踪关系，在现有分支与指定的远程分支之间
$ git branch --set-upstream [branch] [remote-branch]
# 合并指定分支到当前分支
$ git merge [branch]
# 选择一个commit，合并进当前分支
$ git cherry-pick [commit]
# 删除分支
$ git branch -d [branch-name]
# 删除远程分支
$ git push origin --delete [branch-name]
$ git branch -dr [remote/branch]
#统计某人的代码提交量，包括增加，删除：
git log --author="$(git config --get user.name)" --pretty=tformat: --numstat | gawk '{ add += $1 ; subs += $2 ; loc += $1 - $2 } END { printf 
"added lines: %s removed lines : %s total lines: %s\n",add,subs,loc }' -
#仓库提交者排名前 5(如果看全部，去掉 head 管道即可)：
git log --pretty='%aN' | sort | uniq -c | sort -k1 -n -r | head -n 5
#仓库提交者(邮箱)排名前 5：这个统计可能不会太准，因为很多人有不同的邮箱，但会使用相同的名字
git log --pretty=format:%ae | gawk -- '{ ++c[$0]; } END { for(cc in c) printf "%5d %s\n",c[cc],cc; }' | sort -u -n -r | head -n 5 
#贡献者统计：
git log --pretty='%aN' | sort -u | wc -l
#提交数统计：
git log --oneline | wc -l 
# 显示有变更的文件
$ git status
# 显示当前分支的版本历史
$ git log
# 显示commit历史，以及每次commit发生变更的文件
$ git log --stat
# 搜索提交历史，根据关键词
$ git log -S [keyword]
# 显示某个commit之后的所有变动，每个commit占据一行
$ git log [tag] HEAD --pretty=format:%s
# 显示某个commit之后的所有变动，其"提交说明"必须符合搜索条件
$ git log [tag] HEAD --grep feature
# 显示某个文件的版本历史，包括文件改名
$ git log --follow [file]
$ git whatchanged [file]
# 显示指定文件相关的每一次diff
$ git log -p [file]
# 显示过去5次提交
$ git log -5 --pretty --oneline
# 显示所有提交过的用户，按提交次数排序
$ git shortlog -sn
# 显示指定文件是什么人在什么时间修改过
$ git blame [file]
# 显示暂存区和工作区的差异
$ git diff
# 显示暂存区和上一个commit的差异
$ git diff --cached [file]
# 显示工作区与当前分支最新commit之间的差异
$ git diff HEAD
# 显示两次提交之间的差异
$ git diff [first-branch]...[second-branch]
# 显示今天你写了多少行代码
$ git diff --shortstat "@{0 day ago}"
# 显示某次提交的元数据和内容变化
$ git show [commit]
# 显示某次提交发生变化的文件
$ git show --name-only [commit]
# 显示某次提交时，某个文件的内容
$ git show [commit]:[filename]
# 显示当前分支的最近几次提交
$ git reflog
# 下载远程仓库的所有变动
$ git fetch [remote]
# 显示所有远程仓库
$ git remote -v
# 显示某个远程仓库的信息
$ git remote show [remote]
# 增加一个新的远程仓库，并命名
$ git remote add [shortname] [url]
# 取回远程仓库的变化，并与本地分支合并
$ git pull [remote] [branch]
# 上传本地指定分支到远程仓库
$ git push [remote] [branch]
# 强行推送当前分支到远程仓库，即使有冲突
$ git push [remote] --force
# 推送所有分支到远程仓库
$ git push [remote] --all
#简单查看远程---所有仓库
git remote (只能查看远程仓库的名字)
#查看单个仓库
git  remote show [remote-branch-name]
#新建远程仓库
git remote add [branchname]  [url]
#修改远程仓库
git remote rename [oldname] [newname]
#删除远程仓库
git remote rm [remote-name]
#获取远程仓库数据
git fetch [remote-name] (获取仓库所有更新，但不自动合并当前分支)
git pull (获取仓库所有更新，并自动合并到当前分支)
#上传数据，如git push origin master
git push [remote-name] [branch]
 

Refer：

1.* https://www.cnblogs.com/syp172654682/p/7689328.html

2.https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001373962845513aefd77a99f4145f0a2c7a7ca057e7570000

3. http://www.cnblogs.com/schaepher/p/5561193.html#github

4. https://blog.csdn.net/ljchlx/article/details/21805231 [远端仓库初始化成bare仓库的原因]