本文共 19849 字，大约阅读时间需要 66 分钟。
一、Git概述
1. Git诞生
很多人都知道，Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。
Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码。
不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是Linus选择了一个商业的版本控制系统BitKeeper（源代码控制管理系统），BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。到了2005年，Linux社区牛人聚集，有一伙人开发Samba的Andrew试图破解BitKeeper的协议，结果被BitMover公司发现了，于是BitMover公司怒了，要收回Linux社区的免费使用权。这个时候，Linus向BitMover公司道个歉，保证以后以后不会在发生这样的事情。之后，Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了。
Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储，无数开源项目开始迁移至GitHub，包括jQuery，PHP，Ruby等等。历史就是这么偶然，如果不是当年BitMover公司威胁Linux社区，可能现在我们就没有免费而超级好用的Git了。到目前为止，Git可以在Linux、Unix、Mac和Windows这几大平台上正常运行了。
2. Git简介
（1）Git是什么？
Git是目前世界上最先进的分布式版本控制系统。Git是一个开源的分布式版本控制软件，可以有效、高速的处理从很小到非常大的项目版本管理。（2）那什么是版本控制系统？
如果你用Microsoft Word写过长篇大论，那你一定有这样的经历：想删除一个段落，又怕将来想恢复找不回来怎么办？有办法，先把当前文件“另存为……”一个新的Word文件，再接着改，改到一定程度，再“另存为……”一个新文件，这样一直改下去，最后你的Word文档变成了这样：
过了一段时间，你想找回被删除的文字，但是已经记不清删除前保存在哪个文件里了，只好一个一个文件去找，就会觉得很麻烦。
看着这样一大堆乱七八糟的文件，想保留最新的一个，然后把其他的删掉，又怕哪天会用上，还不敢删。于是你就会想，如果有一个软件，不但能自动帮我记录每次文件的改动（类似于腾讯的TIM在线文档编辑），这样就不用自己管理一堆类似的文件了。如果想查看某次改动，只需要在软件里瞄一眼就可以，这样是不是很方便？
这样，就结束了手动管理多个“版本”的史前时代，进入到版本控制时代。
二、Git分布式
1. 集中式版本控制系统
集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要看一本书，必须先从图书馆借出来，然后回家自己看，看完了，再放回图书馆。
集中式版本控制系统最大的缺点就是必须联网才能工作，如果在局域网内还好。
2. 分布式版本控制系统
分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。
和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。
3. Git与SVN的主要区别
这两个工具主要的区别在于历史版本维护的位置。
Git本地仓库包含代码库还有历史库，在本地的环境开发就可以记录历史。而SVN的历史库存在于中央仓库，每次对比与提交代码都必须连接到中央仓库才能进行。4. 使用Git的好处在于
自己可以在脱机环境查看开发的版本历史；多人开发时如果充当中央仓库的Git仓库挂了，任何一个开发者都可以随时创建一个新的中央库，然后同步就立刻恢复了中央库。
三、Git原理
Git分布式版本工具的使用流程如下：
工作区（Working Directory）-->版本库（Repository）暂缓区-->仓库1. 工作区（Working Directory）
就是我们在本机里能看到的目录，比如我的gittest文件夹就是一个工作区。
[root@git gittest]# pwd/root/gittest
2. 版本库（Repository）
工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
我们把文件往Git版本库里添加的时候，要执行两步：
第一步：git add 把文件添加进去，实际上就是把文件添加到暂存区；第二步：git commit -m "版本描述信息" 提交到版本库，实际上就是把暂存区的所有内容提交到仓库的当前分支。创建Git版本库时，Git自动为我们创建了一个master分支，所以git commit就是往master分支上提交更改。
你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。当工作区有文件更改，执行git add时，暂缓区就变成如下这样：
git add 命令实际上就是把工作区要提交的内容放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支
一但执行git commit提交后，那么工作区就是“干净”的：现在版本库变成了这样，暂存区就没有任何内容了：
以上就是git分布式版本工具的流程，没看明白的童鞋，可以再多看一次。
四、安装Git
这里我使用Centos 7系统来安装Git。
两种安装方法（选其一就好了）：- 使用yum安装；
- 使用源码包安装。
方法一：
[root@git ~]# yum -y install git-core[root@git ~]# git --version --查看版本号git version 2.16.0
方法二：
1. 获取Git源码包可以去下面的网址去下载Git的源码包：[root@git ~]# wget https://www.kernel.org/pub/software/scm/git/git-2.16.0.tar.gz或[root@git ~]# wget https://github.com/git/git/archive/v2.16.0.tar.gz
我这里下载了2.16.0版本的源码包
git-2.16.0.tar.gz2. 在CentOS 7上安装Git
从Git官网下载源码，然后解压，依次输入：./configure，make，sudo make install这几个命令安装就好了。# tar xvf git-2.16.0.tar.gz -C /usr/src/ --解压# cd /usr/src/git-2.16.0/ --进入解压之后的路径# ./configure --配置# make && make install --编译和安装# git --version --查看版本号git version 2.16.0
五、创建本地工作区
因为Git是分布式版本控制系统，所以，上传版本文件时必须提供：你的名字和Email地址。
[root@git ~]# git config --global user.name "xiaozuoxiansen"[root@git ~]# git config --global user.email "2947853874@qq.com"
版本库又名仓库，英文名repository，可以理解成一个目录，这个目录里面的所有文件都被Git管理起来，每个文件的修改、删除，Git都能跟踪.
第一步：创建一个版本库，创建一个目录：
[root@git ~]# mkdir gittest[root@git ~]# cd gittest/[root@git gittest]# pwd/root/gittest
第二步：git init命令把该目录初始化为Git可以管理的仓库
[root@git gittest]# git init已初始化空的 Git 仓库于 /root/gittest/.git/
使用tree命令可以查看/root/gittest/.git/目录下的树结构
[root@git gittest]# tree /root/gittest/.git//root/gittest/.git/|-- branches|-- config|-- description|-- HEAD|-- hooks| |-- applypatch-msg.sample| |-- commit-msg.sample| |-- fsmonitor-watchman.sample| |-- post-update.sample| |-- pre-applypatch.sample| |-- pre-commit.sample| |-- prepare-commit-msg.sample| |-- pre-push.sample| |-- pre-rebase.sample| |-- pre-receive.sample| `-- update.sample|-- info| `-- exclude|-- objects| |-- info| `-- pack`-- refs |-- heads `-- tags9 directories, 15 files
开始编写一个README自述文件
[root@git gittest]# echo "##README file" > README
使用git status 查看当前工作区的状态
[root@git gittest]# git status位于分支 master尚无提交未跟踪的文件: （使用 "git add <文件> ..." 以包含要提交的内容） README --有一个新的文件README，提示可以使用git add提交至暂存区提交为空，但是存在尚未跟踪的文件（使用 "git add" 建立跟踪）
使用git add 命令 将刚在工作区创建的README提交至暂存区
[root@git gittest]# git add README --将README提交到暂存区[root@git gittest]# git status --查看当前工作区的状态位于分支 master尚无提交要提交的变更： （使用 "git rm --cached <文件> ..." 以取消暂存） 新文件： README --新的文件README，提示可以使用git rm --cached <文件> 取消暂存
使用git commit -m "描述信息"将暂存区的文件提交至本地仓库，
[root@git gittest]# git commit -m "first README" -- -m表示添加说明，first README为说明内容，此内容自定义[master（根提交） 6c2a0d6] first README 1 file changed, 1 insertion(+) create mode 100644 README[root@git gittest]# git status --查看当前工作区的状态，提交之后，暂存区无内容可以提交位于分支 master无文件要提交，干净的工作区
六、文件对比
有时候我们修改了本地的一个文件，但临时有事走开了，回来的时候忘记了自己做了哪部分的修改。
此时就要用上git diff命令，进行文件对比。[root@git gittest]# echo "##new add test" >> README --向README文件添加内容[root@git gittest]# git status --查看当前工作区的状态位于分支 master尚未暂存以备提交的变更： （使用 "git add <文件> ..." 更新要提交的内容） （使用 "git checkout -- <文件> ..." 丢弃工作区的改动） 修改： README --显示README文件已经被修改过了修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）[root@git gittest]# git diff README --使用git diff 命令对比README文件查看和上次提交到仓库的内容与现在的文件哪些地方被修改过了diff --git a/README b/READMEindex 9383c5a..29dcf26 100644--- a/README+++ b/README@@ -1 +1,2 @@ ##README file+##new add test --最前面的+号表示README文件新增加的内容
知道自己修改了什么，那么接下来就可以放心的提交了
[root@git gittest]# git add README --提交至暂存区[root@git gittest]# git commit -m "second README" --提交到本地仓库[master c973a69] second README 1 file changed, 1 insertion(+) --表示README文件1行被修改，新增1行[root@git gittest]# git status --再次查看状态时，显示无内容可提交位于分支 master无文件要提交，干净的工作区
七、版本回退
什么是版本库呢？版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。
在实际工作中，我们提交的版本可以有很多，很难记得每次提交了什么内容，或是什么时候提交的，这里就要用上git log命令来查看提交的版本。[root@git gittest]# git log --查看提交日志commit c973a69ebb25b5def81d4b6ce57f487a97f37369 (HEAD -> master)Author: xiaozuoxiansen <2947853874@qq.com>Date: Mon Feb 5 14:35:14 2018 +0800 second README --这是我第二次提交commit 6c2a0d6fb6fa30103d60e4d993357c3dbffa5c8bAuthor: xiaozuoxiansen <2947853874@qq.com>Date: Mon Feb 5 14:23:42 2018 +0800 first README --这是我第一次提交
可以看出，最近提交的一次显示在最上面。
也可以看到有两个版本，时间点也可以看得到，提交人和邮件也可以看得到，第一行的commit 后面的那一连串的字符是commit id是唯一标识符。在生产环境中我们提交的版本有太多太多，要是这么看的话，不方便看，此时我们可以加上--pretty=oneline参数：这样显示就简洁多了。
[root@git gittest]# git log --pretty=onelinec973a69ebb25b5def81d4b6ce57f487a97f37369 second README6c2a0d6fb6fa30103d60e4d993357c3dbffa5c8b first README
在Git中，我们首先要知道当前是哪个版本，以前有哪些版本，用HEAD表示当前版本，上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。也可以指定版本的commit id的前4位以上也可以。
[root@git gittest]# git log --pretty=oneline --列出版本号c973a69ebb25b5def81d4b6ce57f487a97f37369 second README6c2a0d6fb6fa30103d60e4d993357c3dbffa5c8b first README[root@git gittest]# git reset --hard 6c2a --回退到commit id开头为6c2a的版本HEAD 现在位于 6c2a0d6 first README[root@git gittest]# git log --pretty=oneline --查看当前的版本6c2a0d6fb6fa30103d60e4d993357c3dbffa5c8b first README[root@git gittest]# cat README --查看内容，回退成功##README file
现在你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？
在Git中，总是有后悔药可以吃的。当你用 git reset --hard HEAD^回退到second README版本时，再想恢复到first README，就必须找到first README的commit id。Git提供了一个命令git reflog用来记录你的每一次命令。[root@git gittest]# git reflog --列出了所有的commit的操作和reset回退的操作，还显示了对应的commit id6c2a0d6 (HEAD -> master) HEAD@{0}: reset: moving to 6c2ac973a69 HEAD@{1}: commit: second README6c2a0d6 (HEAD -> master) HEAD@{2}: commit (initial): first README[root@git gittest]# git reset --hard c973a69 --输入最后一次提交的commit id 回退HEAD 现在位于 c973a69 second README[root@git gittest]# git log --pretty=oneline --查看当前的版本c973a69ebb25b5def81d4b6ce57f487a97f37369 (HEAD -> master) second README6c2a0d6fb6fa30103d60e4d993357c3dbffa5c8b first README[root@git gittest]# cat README --验证下内容，是新后一次提交的内容##README file##new add test 总结：
- 1.HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
- 2.回退版本前，用git log可以查看提交历史，以便确定要回退到哪个版本。
- 3.要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
八、修改、撤销、删除
1. 管理修改
什么是修改？比如你新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建一个新文件，也算一个修改。
为什么说Git管理的是修改，而不是文件呢？我们还是做一个测试。
第一步：对README文件做一个修改，比如加一行内容[root@git gittest]# echo "hello world" >> README --向README文件添加内容[root@git gittest]# cat README ##README file##new add testhello world
第二步：添加
[root@git gittest]# git add README[root@git gittest]# git status 位于分支 master要提交的变更： （使用 "git reset HEAD <文件> ..." 以取消暂存） 修改： README
第三步：再次修改README文件，比如再加一行内容
[root@git gittest]# echo "test" >> README --向README文件添加内容[root@git gittest]# cat README ##README file##new add testhello worldtest
第四步：提交
[root@git gittest]# git diff README --是工作区(work dict)和暂存区(stage)的比较diff --git a/README b/READMEindex 1d755e7..0745038 100644--- a/README+++ b/README@@ -1,3 +1,4 @@ ##README file ##new add test hello world+test[root@git gittest]# git diff --cached README --是暂存区(stage)和分支(master)的比较diff --git a/README b/READMEindex 29dcf26..1d755e7 100644--- a/README+++ b/README@@ -1,2 +1,3 @@ ##README file ##new add test+hello world[root@git gittest]# git diff HEAD -- README --查看工作区和版本库里面最新版本的区别diff --git a/README b/READMEindex 29dcf26..0745038 100644--- a/README+++ b/README@@ -1,2 +1,4 @@ ##README file ##new add test+hello world+test[root@git gittest]# git commit README -m "third README" --加了文件名，全部被提交[master bcb96a1] third README 1 file changed, 2 insertions(+)[root@git gittest]# git commit -m "third README" --不加文件名，只有暂存区被提交
2. 撤销修改
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。
[root@git gittest]# echo "场景一 test" >> README --向README文件添加内容[root@git gittest]# cat README ##README file##new add testhello worldtest场景一 test[root@git gittest]# git status --查看状态，显示README文件被修改位于分支 master尚未暂存以备提交的变更： （使用 "git add <文件> ..." 更新要提交的内容） （使用 "git checkout -- <文件> ..." 丢弃工作区的改动） 修改： README修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）[root@git gittest]# git checkout -- README --此时如果要撤消修改，则执行该命令[root@git gittest]# git status --再次看状态，显示没有文件修改或添加位于分支 master无文件要提交，干净的工作区[root@git gittest]# cat README --再次查看README内容时，内容已经撤消成功##README file##new add testhello worldtest
git checkout -- file 命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令
场景2：当你不但改乱了工作区某个文件的内容，还add添加到了暂存区时，想丢弃修改，这时要撤消的话，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作。
[root@git gittest]# echo "场景二 test" >> README --向README文件添加内容[root@git gittest]# cat README ##README file##new add testhello worldtest场景二 test[root@git gittest]# git status --查看状态，显示README文件被修改位于分支 master尚未暂存以备提交的变更： （使用 "git add <文件> ..." 更新要提交的内容） （使用 "git checkout -- <文件> ..." 丢弃工作区的改动） 修改： README修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）[root@git gittest]# git add README[root@git gittest]# git status --当我们修改一个文件执行了git add后，再看状态时，会提示执行git reset HEAD可以撤消到工作区位于分支 master要提交的变更： （使用 "git reset HEAD <文件> ..." 以取消暂存） 修改： README[root@git gittest]# git reset HEAD README --把README暂存区修改的内容撤消到工作区重置后取消暂存的变更：M README[root@git gittest]# git status --再次查看状态时，显示文件已经到了工作区位于分支 master尚未暂存以备提交的变更： （使用 "git add <文件> ..." 更新要提交的内容） （使用 "git checkout -- <文件> ..." 丢弃工作区的改动） 修改： README修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）[root@git gittest]# git checkout -- README --再执行git checkout -- README把修改的内容从工作区里撤消[root@git gittest]# cat README --再次查看README内容时，内容已经撤消成功##README file##new add testhello worldtest
3. 删除文件
场景一：误删了工作区的某个文件；
如果误删了工作区的某个文件，可以从仓库里恢复，测试如下：[root@git gittest]# rm README --删除文件rm：是否删除普通文件 "README"？y[root@git gittest]# ls --文件已经被删除[root@git gittest]#[root@git gittest]# git status --查看状态，显示工作区文件README文件被标记为删除位于分支 master尚未暂存以备提交的变更： （使用 "git add/rm <文件> ..." 更新要提交的内容） （使用 "git checkout -- <文件> ..." 丢弃工作区的改动） 删除： README修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）[root@git gittest]# git checkout -- README --此时执行git checkout --可以将删除的文件撤消[root@git gittest]# git status 位于分支 master无文件要提交，干净的工作区[root@git gittest]# ls --再查看时文件已经恢复回来README
场景二：确认要删除仓库的某个文件，git rm命令
测试如下：[root@git gittest]# git rm README --删除工作区的文件READMErm 'README'[root@git gittest]# git status --查看状态，README已经被标识为delete位于分支 master要提交的变更： （使用 "git reset HEAD <文件> ..." 以取消暂存） 删除： README[root@git gittest]# git commit -m "delete README" -执行提交到仓库[master 09be905] delete README 1 file changed, 4 deletions(-) delete mode 100644 README[root@git gittest]# ls --文件已经被彻底删除[root@git gittest]#
九、远程仓库GitHub
Git分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。最开始只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。
实际工作环境中，是找一台电脑充当服务器的角色，7 * 24小时开机，个人电脑都从这个“服务器”仓库克隆一份到自己的电脑上，并且各自把各自的提交推送到服务器仓库里，也从服务器仓库中拉取别人的提交。当然这里不讲本地环境中的仓库，我们讲官方GitHub代码托管网站，这是一个免费代码托管服务，所以，只要注册一个GitHub账号，就可以免费获得Git远程仓库。
GitHub官方网站： 大家自行注册。GitHub注册成功后，我们还需要进行一些设置，创建ssh-key才可以将个人电脑中的内容提交到GitHub中来，GitHub为什么要ssh-key呢？因为GitHub需要识别出你推送提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。
GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。
温馨提示：在GitHub上免费托管的Git仓库，任何人都可以看到，且还可以评论，但只有你自己才可以修改，所以，敏感信息就要慎重了。
第一步：创建ssh-key
[root@git ~]# ssh-keygen -t rsa -C ”2947853874@qq.com“ --把邮箱换成你自己的邮箱，然后一直回车到结束Generating public/private rsa key pair.Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa.Your public key has been saved in /root/.ssh/id_rsa.pub.The key fingerprint is:76:82:32:ca:9e:34:b1:d3:28:b9:02:97:49:3b:73:e6 ”2947853874@qq.com“The key''s randomart image is:+--[ RSA 2048]----+| || || || . . || ..+o . S . ||.oB*oo . o ||+.O*. ||.= +E ||o o |+-----------------+[root@git ~]# ll ~/.ssh/ --查看家目录下的.ssh目录下有两个文件id_rsa私钥，不可泄露， id_rsa.pub公钥，对外提供的，可以放心提供给任何人。总用量 8-rw------- 1 root root 1679 2月 5 15:56 id_rsa-rw-r--r-- 1 root root 405 2月 5 15:56 id_rsa.pub[root@git ~]# cat ~/.ssh/id_rsa.pub --查看公钥内容，复制，后面有用ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDYyuSvWHN/0xR4aEiCLcPlkPcdBt82J8MDAVDSVt+5PSAZUIe61JpB5PP5QvSN5+C9qmBgxgeNuriOd+odCyhV8SUxt8SVLpcntG8yjjaE/zFVdB2Nb3B+w13f4FIxBo+6MjboyJUi6xnjrrbPtk8L4hfmIO/3TQ1SXceycIDanXNsuzgWT0sYxIcTMfHyhNY5ogIILutyTkHziGWoJH2TY73D1GUE+u0a/NbezBIeJeEJ/jowsoVVTY4ZcKjxL1r0ivc/AB7+bUriMSDZpmsk4A473EidFoa5fNv+14Gk1Nsve5WpmntFHWRhqye3QtZkMsOEcnVYw6UMomzsvh/h ”2947853874@qq.com“
第二步：登陆GitHub网站
点击头像 >> 点击settings >> 点向SSH and GPG keys >> New SSH key >> Title自定义 >> Key 就是上面的id_rsa.pub的内容复制上来 >> Add SSH key
点击“Add SSH key”之后，如下图所示：
第三步：创建远程仓库
点击头像旁边的 + 号 >> New repository >> Repository name 处填写仓库名称（自己命名，我这写的是test） >> 点击Create repository 创建仓库
点击“Create repository ”之后，如下图所示：
GitHub上刚创建的仓库test仓库是空的，GitHub在界面上提示，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库。 根据GitHub的提示，在本地的learngit仓库下运行以下两条命令：
第一条：git remote add origin 注意：把上面的xiaozuoxiansen替换成你自己的GitHub账户名，test替换为你自己在GitHub上创建的仓库名，否则，你在本地关联的就是我的远程库，关联没有问题，但是你以后推送是推不上去的，因为你的SSH Key公钥不在我的账户列表中。[root@git gittest]# git remote add origin https://github.com/xiaozuoxiansen/test.git[root@git gittest]#
第二条：git push -u origin master
把本地库的内容推送到远程GitHub仓库，用git push命令，实际上是把当前分支master推送到远程。由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令：git push
[root@git gittest]# git push -u origin masterUsername for 'https://github.com': xiaozuoxiansen --要求你输入GitHub官方的帐号Password for 'https://xiaozuoxiansen@github.com': --要求你输入GitHub官方帐号对应的密码对象计数中: 11, 完成.压缩对象中: 100% (4/4), 完成.写入对象中: 100% (11/11), 902 bytes | 451.00 KiB/s, 完成.Total 11 (delta 0), reused 0 (delta 0)To https://github.com/xiaozuoxiansen/test * [new branch] master -> master分支 'master' 设置为跟踪来自 'origin' 的远程分支 'master'。
推送成功后，可以在GitHub页面中看到远程库的内容已经和本地是一样的
前面说到的是在GitHub创建仓库，且把本地的仓库关联到GitHub中的公共仓库。
接下来讲从远程仓库中克隆到本地仓库中来现在，假设我们从零开始，那么最好的方式是先创建远程库，然后从远程库克隆。登陆GitHub，创建一个新的仓库，名字叫project，勾选Initialize this repository with a README，这样GitHub会自动为我们创建一个README.md文件。
创建完毕后，可以看到README.md文件：
接下来用命令git clone将GitHub的远程仓库克隆到本地来。 [root@git gittest]# git clone https://github.com/xiaozuoxiansen/project.git正克隆到 'project'...remote: Counting objects: 3, done.remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0展开对象中: 100% (3/3), 完成.[root@git gittest]# [root@git gittest]# [root@git gittest]# lsproject[root@git gittest]# ls project/README.md
注意把Git库的用户名xiaozuoxiansen换成你自己的，然后进入project目录看看，已经有README.md文件了。
十、创建于合并分支
分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。
Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。
第一步：创建dev分支，然后切换到dev分支：
[root@git gittest]# git checkout -b dev --git checkout命令加上-b参数表示创建并切换分支切换到一个新分支 'dev'# 相当于以下两条命令[root@git gittest]# git branch dev --创建分支[root@git gittest]# git checkout dev --切换分支切换到分支 'dev'
第二步：用git branch命令查看当前分支
[root@git gittest]# git branch --列出所有分支，当前分支前面会标一个*号* dev master
第三步：在dev分支上正常提交
[root@git gittest]# echo "creating a new branch" >> README --向README文件添加内容[root@git gittest]# git add README --提交[root@git gittest]# git commit -m "branch test"[dev e4fc3ca] branch test 1 file changed, 1 insertion(+) [root@git gittest]# git checkout master --切换回master分支切换到分支 'master'您的分支与上游分支 'origin/master' 一致。[root@git gittest]# cat README --再查看README文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变##README file##new add test
第四步：把dev分支的工作成果合并到master分支上
[root@git gittest]# git merge dev --我们把dev分支的工作成果合并到master分支上更新 c973a69..e4fc3caFast-forward README | 1 + 1 file changed, 1 insertion(+)[root@git gittest]# cat README ##README file##new add testcreating a new branch
git merge命令用于合并指定分支到当前分支。合并后，再查看README文件的内容，就可以看到，和dev分支的最新提交是完全一样的。
第五步：合并完成后，就可以放心地删除dev分支了
[root@git gittest]# git branch -d dev --删除dev分支已删除分支 dev（曾为 e4fc3ca）。[root@git gittest]# git branch --删除后，查看branch，就只剩下master分支了* master
因为创建、合并和删除分支非常快，所以我们在使用分支完成某个任务时，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
转载于:https://blog.51cto.com/13525470/2069073