Git&GitHub

1、将内容Push到GitHub上

1.1、在GitHub上创建新项目

要上传文件到GitHub，需要先在上面创建一个新的项目。首先在GitHub网站的右上角单击＋按钮，在弹出的下拉列表中选择New repository选项：

接着填写项目名称：

1. Repository name可任意填写，只要不重复即可
2. 可填写仓库描述
3. 存取权限选中Public单选按钮，可免费使用，选中Private则需交费$7/月
4. 可选是否添加readme文件
5. 可选根据语言的.gitignore忽略文件
6. 可选开源协议

单击Create repository按钮，即可新增一个Repository。接下来会看到引导画面：

这里有以下两点需要说明：

1. 如果是新项目，按照create a new repository on the command line的提示进行操作；如果是要上传现存项目，则按照push an existing repository from the command line的提示进行操作。
2. 在图的中间有两个按钮可供切换，分别是HTTPS按钮和SSH按钮，可根据个人需要进行选择。如果单击SSH按钮，需要设置SSH Key（关于SSH Key的设置，可参考后续的介绍。因为这里已经设置好SSH Key了，所以只需单击“SSH”按钮）。

如果仔细观察，就会发现选择全新开始与上传现有项目的最后两个步骤是一样的。

假设现在什么都没有，要重新开始一个项目，找一个空的目录，然后照着提示进行操作即可。首先创建一个README.md文件：

mkdir demo
cd demo
echo "# git push demo" > README.md

接下来就是我们熟悉的Git了（用git init指令针对目录进行Git初始化）：

git init 
git add .
git commit -m "first commit"

接下来就要准备把内容推上远端的Git服务器上了。首先，需要设置一个远端节点。例如：

git remote add origin git@github.com:ActonZhang1024/demo.git

这里有以下三点需要说明：

1. git remote指令主要进行与远端有关的操作。
2. add指令是指要加入一个远端的节点。
3. 这里的origin是一个代名词，指的是后面那串GitHub服务器的位置。

按照惯例，远端的节点默认使用origin这个名称。如果是从服务器上Clone下来的，其默认名称就是origin。但这只是惯例，不用该名称或之后想要更改都可以。例如，更改为七龙珠dragonball：git remote add dragonball git@github.com:ActonZhang1024/demo.git

设置好远端节点后，接下来就是把内容推上去：

git push -u origin master

这个简单的Push指令其实做了以下几件事：

1. 把master分支的内容推向origin位置。
2. 在origin远端服务器上，如果master不存在，就创建一个名为master的分支。
3. 如果服务器上存在master分支，就会移动服务器上master分支的位置，使它指到当前最新的进度上。
4. 设置upstream，就是-u参数做的事情，这个稍后说明。

如果理解了上面指令的意思，就可以再做一些变化。例如，远端节点为dragonball，想把cat分支推上去，可以使用如下命令：

git push dragonball cat

这样就会把cat分支推上dragonball这个远端节点所代表的位置，并且在上面创建一个名为cat的同名分支（或更新进度）。

返回GitHub网站，刷新一下页面，刚才那个引导指令的画面变成了如下：

该画面表示已经顺利地把本地项目的内容推到这个远端的项目中了。

1.2、upstream

upstream翻译成中文，就是“上游”。看起来很难理解，但其实就是另一个分支的名称而已。

在Git中，每个分支可以设置一个上游（但每个分支最多只能设置一个上游），它会指向并追踪（track）某个分支。通常，upstream会是远端服务器上的某个分支，但要设置在本地端的其他分支也可以。

如果设置了upstream，当下次执行git push指令时，就会用它来当默认值。例如：

git push -u origin master

就会把origin/master设置为本地master分支的upstream，当下次执行git push指令而不加任何参数时，Git就会猜出是要推往origin远端节点，并且把master分支推上去。

反之，如果没有设置upstream，则必须在每次Push时都跟Git讲清楚、说明白：

git push origin master

否则，只是执行git push指令而不带其他参数，Git就会不知道该Push什么分支，以及要Push到哪里：

$ git push 
fatal: The current branch master has no upstream branch. To push the current branch and set the remote as upstream, use      git push --set-upstream origin master

1.3、如果不想要相同的分支名称

前面提到Push的指令为：

git push origin master

其实上面这个指令与下面这个指令是一样的效果：

git push origin master:master

意思是把本地的master分支推上去后，在服务器上更新master分支的进度；如果不存在该分支，就创建一个master分支。但如果推上去之后想更改名称，可以把后面的名称改掉：

git push origin master:cat

这样把本地的master分支推上去之后，就不会在线创建master分支了，而是创建一个名为cat的分支（或更新进度）。

2、Pull下载更新

与Push指令相反，Pull指令是拉回本机更新。但在介绍Pull指令之前，需要先介绍一下Fetch指令。

2.1、Fetch指令

接着上一节那个GitHub的示例，试着执行下面这个指令：

git fetch

你会发现没有任何信息，那是因为现在的进度与在线版本是一样的（因为只有自己一个人在做）。为了营造有不同进度的效果，可以到GitHub网站上直接编辑某个文件。例如，选中README.md文件，单击右上角出现的Edit this file按钮：

单击下方的Commit changes按钮，即可进行存档并新增一次Commit。这样一来，在线版本的Commit数就领先本机一次了。再次执行Fetch指令：

git fetch

可以看到有内容被拉回来了。此时查看一下状态：

2.2、Fetch原理

图所示为Fetch之前的状态，HEAD和master分支都不出意外地乖乖待在它们该在的位置。

因为当前项目之前曾推送内容到服务器上，所以远端分支也会记录一份在本机上，同样也是有HEAD和master分支，但会在前面加注远端节点origin，变成origin/ HEAD和origin/master。

因为在第一次推送时使用了-u参数设置upstream，所以当前这个origin/master分支其实就是本地master分支的upstream。

接下来执行Fetch指令。Git看过在线版本的内容后，会把当前线上有但本地没有的内容抓（即复制）一份下来，同时移动origin相关的分支：

先不管origin/master这个分支名称是否有点奇怪，也不管它是本地分支还是远端分支，对Git来说，它就是一个从master分支分出去的分支而已。

既然这个分支是从master分支分出去的，而且进度比master分支还要新，那么如果master分支想要跟上它，该怎么做呢？这个情境对大家来说是不是有点熟悉？没错，接下来要做的就是合并（Merge）：

git merge origin/master

因为origin/master分支和master分支本是“同根生”，所以可以看到上面合并的过程是使用快转模式（Fast Forward）进行的。

2.3、Pull指令

如果能理解Fetch指令在做什么，那么Pull指令就好理解了，因为：

git pull = git fetch + git merge

Pull指令其实就是去线上将内容抓下来（Fetch），并且更新本机的进度（Merge）。

再次在线上浏览器修改README.md：

使用git pull：

git pull

注意，本次merge还是使用了快转模式（Fast Forward），如果不希望使用快转模式，可以使用–no-ff参数，即： git pull --no-ff

2.4、Pull+Rebase

在执行git pull指令时，也可以加上-- rebase参数，它在Fetch完成之后，就会使用Rebase方式进行合并：

git pull --rebase

在多人共同开发时，大家都在自己的分支进行Commit，所以拉回来用一般的方式合并时，常会出现为了合并而生成额外的Commit的情况。为了合并而生成的Commit本身并没有什么问题，但如果不想要这个额外的Commit，可考虑使用Rebase方式进行合并。

3、为什么有时候推不上去

在执行Push指令时偶尔会出现错误信息：

$ git push 
To https://github.com/eddiekao/dummy-git.git ! [rejected] master -> master (fetch first) error: failed to push some refs to 'https://github.com/eddiekao/dummy-git.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

这段信息的意思是“在线版本的内容比本地计算机中的内容还要新，所以Git不让推上去”。

3.1、问题复现

通常这种状况会发生在多人一起开发的时候，其情境如图所示。

1. Sherly和Eddie在差不多的时间都从Git服务器上拉了一份文档下来准备进行开发。
2. Sherly手脚比较快，先完成了，于是把做好的成果推了一份上去。
3. Eddie不久后也完成了，但当他要推上去的时候发现推不上去了……

再次在线上浏览器修改README.md内容：

修改本地的README.md：

保存到暂存区并提交：

git add .
git commit -m "local update"

尝试推送，问题复现：

git push

3.2、解决方案一：先拉再推

因为本地计算机中的内容是比较旧的，所以应该先拉一份在线版本的内容回来更新，然后再推一次：

git pull

解决冲突问题：

然后再提交并推送：

git add .
git commit -m "fixed conflicts"
git push

3.3、解决方案二：强制推送

只要加上了--force或-f参数，它就会强制推上去，把之前的内容覆盖：

git push -f

4、Clone指令

4.1、Clone Repository

按照前面的介绍进行推（Push）、拉（Pull）时有一个前提，就是已经有这个项目了。

如果在GitHub上看到某个项目很有趣，想要下载后查看，只要使用Clone指令就可以把整个项目复制一份下来。

同样可以选择HTTPS或SSH，这里选择SSH。连接之后，便可使用Clone指令把它复制下来：

git clone git@github.com:ActonZhang1024/demo.git

这个指令会把整个项目复制一份并存储在同名的目录中。如果想要复制下来之后存储到不同名称的目录中，只要在后面加上目录名称即可：

git clone git@github.com:ActonZhang1024/demo.git other_dir_name

Clone指令会把整个项目的内容复制一份到本地计算机中，这里所说的内容不是只有文件，还包括整个项目的历史记录、分支、标签等。

4.2、Clone与Pull指令的区别

这两个指令的应用场景是不同的：

1. 如果这个项目你是第一次看到，想要下载到自己的计算机中，应使用Clone指令
2. 如果已经下载了，只是想更新为最新的在线版内容，则使用Pull（或Fetch）指令。

简单地说，Clone指令通常只在第一次下载时使用，而之后的更新就只能使用Pull/Fetch指令了。

5、与其他开发者互动（Pull Request）

在GitHub上有非常多的开源项目，有些项目你很感兴趣，也很想帮忙，于是联系项目的原作者跟他说：“我觉得你的项目很有趣，开个权限给我吧，我来帮你加一些功能”。想想看，如果你是原作者，有不认识的人让你开权限给他，你愿意吗？

在GitHub上有个有趣的机制：

1. 先复制（Fork）一份原作者的项目到自己的GitHub账号下。
2. 因为复制的项目已经在自己的GitHub账号下，所以就有了完整的权限，可以随意更改。
3. 改完后，将自己账号下的项目推送（Push）上去。
4. 发个通知，让原作者知道你帮忙做了一些事情，请他看一下。
5. 原作者看完后如果觉得可以，就会把你做的这些修改合并（Merge）到他的项目中。

其中，步骤（4）中的那个“通知”，就是发送一个请原作者拉回去（Pull）的请求（Request），称为PR（Pull Request）。

5.1、Fork示例

准备工作：

项目地址：https://github.com/ActonZhang1024/demo
角色A：项目的原作者，https://github.com/ActonZhang1024
角色B：想要帮忙的路人，https://github.com/dellmessenger10

第一步Fork项目：

角色B登录项目网址，可以看到页面右上角有3个按钮，如图所示：

单击Fork按钮，进入图所示的页面：

可以修改仓库名和描述信息，点击按钮即可把原作者的项目复制一份到角色B的账号下。

现在这个项目的确已被放到角色B的账号下，而且标注了Forked from“角色A”。这表明角色B对放在自己账号下的这个项目有完整的存取权限了。

第二步：Clone回来修改

git clone https://github.com/dellmessenger10/demo.git

为了方便操作，我们不进行add、commit和push操作了，直接在线上浏览器修改：

第三步：发PR给原作者

回到自己的项目页面，单击New pull request按钮，如图所示：

在弹出的Comparing Changes页面中单击Create pull request按钮：

在弹出的Open a pull request页面中输入PR的相关信息：

此外，在此还可以选择要将PR发送到原项目的哪个分支。设置完毕后，单击Create pull request按钮，即可完成PR的发送：

第四步：原作者收下PR

切换回角色A（原作者），即可在项目页面中看到Pull requests的数量增加了：

打开新的PR，可以看到其中都做了哪些修改：

如果觉得可以接受，单击Merge pull request按钮，即可合并这次的Commit：

最后查看合并后的结果：

5.2、应用情景

除开源项目外，企业内部的项目也适合使用发送PR的方式来开发。在开发产品时，通常会挑选一个固定分支作为可以上线的正式版本分支，一般使用master或production分支作为正式分支。当多人参与同一个项目时，让每个人都可以Commit到项目正式上线的分支不是一种好的做法，这时便可使用PR方式来进行。

每位开发者都先将公司的项目Fork一份到自己的账号下，待功能完善后再发PR回公司的项目。负责管理这个项目的人收到PR后，进行Code Review并确认无误后便可进行合并，这样就可让这个产品分支处于随时可以上线的状态。

也许一开始会觉得这样很麻烦，但随着协同开发的人越来越多，就越需要制定规则。

5.3、“怎样跟上当初fork的项目的进度”

如果在发送PR前，其他人抢先一步，也发送了PR，且原作者接受了，那么该项目的进度就会领先于自己账号下的项目进度。如果要让自己账号下Fork过来的项目进度跟上原项目当前的进度，应该怎么做？对此，GitHub网站上目前并没有提供相应的功能，但你可以通过以下两种做法来达成这个目的。

1、砍掉重练

这招就是把Fork过来的项目删除，再重新Fork一次，这样保证会是最新版本。虽然这招技术含量不高，但很好用，完全不需要任何代码或指令就可以完成，而且很多人都在使用。

2、跟上游同步

比较有技术含量的做法（也是比较正统的做法），就是把原作者的项目设置成上游项目，Fetch回来后再手动合并。

“第一步：设置原作者项目的远端节点

例如，下面是Fork过来的项目：

$ git remote -v 
origin https://github.com/eddiekao/dummy-git.git (fetch) 
origin https://github.com/eddiekao/dummy-git.git (push)

使用git remote指令加上-v参数可以看到更完整的信息。可以看出，当前这个项目只有一个远端节点origin。接下来帮它加上另一个远端节点，这个远端节点指向的位置就是原作者的项目：

$ git remote add dummy-kao https://github.com/kaochenlong/dummy-git.git

其实大部分的教程都会教你使用upstream作为原项目远端节点的名称，但为避免与默认的upstream混淆，所以这里使用dummy- kao作为指向原项目的远端节点。这时在这个项目中就有两个远端节点，一个是原来的origin，一个是原项目的dummy-kao：

$ git remote –v 
dummy-kao  https://github.com/kaochenlong/dummy-git.git (fetch) 
dummy-kao  https://github.com/kaochenlong/dummy-git.git (push) 
origin https://github.com/eddiekao/dummy-git.git (fetch) 
origin https://github.com/eddiekao/dummy-git.git (push)

第二步：抓取原项目的内容

接下来，使用Fetch指令取得原项目最新版本的内容：

$ git fetch dummy-kao  

Fetch下来之后，在本地的远端分支会往前移动吗？如果想要跟上刚抓下来的进度，就使用Merge指令（使用Rebase也可以）：

git merge dummy-kao/master

这样，你本机的进度就与原项目的进度一样了。

第三步：推回自己的项目

这个步骤要不要做就看你自己了，毕竟在本地计算机上已经是最新版本了。如果你希望在GitHub上Fork的那个项目也更新到最新版，只要推上去就行了：

git push origin master 

这样一来，本地计算机中的项目，以及在GitHub上从原项目Fork过来的项目就都是最新进度了。

6、删除远端的分支

6.1、GitHub线上删除

单击中间的branches（分支）标签，可以看到当前所有的分支：

单击某一分支右下角的图标，即可删掉该分支。

6.2、命令行删除

如果是使用以下指令，就把远端的分支删掉了：

git push origin :cat

是的，就是在分支前面加上冒号，而且是用Push指令来删除远端分支。

7、git push -f的使用场景

7.1、整理历史记录

有时项目Commit的历史记录太乱了，想要“大刀阔斧”地整顿一下，于是使用了Rebase指令（关于如何使用Rebase指令，可参阅第7章）。因为Rebase等于是修改已经发生的事实，所以正常来说是推不上去的。

这时就可使用Force Push指令来解决这个问题，但使用前务必知会一下同一个项目的队友，请他们到时候以你这份进度为主。

7.2、只用在自己身上。

我自己在工作的时候，通常会开一个分支出去做，但做完发现Commit太过琐碎，便会使用Rebase指令整理一下这个分支。虽然Rebase指令是修改历史记录的，但因为仅影响我自己这个分支，所以并不会影响其他人正常使用：

git push -f origin features/my_branch

这样只会强制更新features/my_branch分支的内容，不会影响其他分支。

8、使用GitHub免费制作个人网站

GitHub除了提供免费的Git服务器，如果推上去的分支刚好叫作gh-pages，也可以用GitHub当作静态文件的服务器。它比一般的虚拟主机要便宜得多，也安全得多，不过也有一些限制：

1. 仅呈现静态页面内容，如果是用PHP或ASP编写的，则不会响应。
2. 不支持.htaccess之类的配置文件，所以无法设置用户密码。
3. 仅能使用Git上传，没有FTP之类的东西。
4. 不像Repository有Private的设置，所有的GitHub Pages都是公开的，甚至Private项目中的页面也是公开的。

从整体上来说，GitHub Pages的优点还是多于缺点，至少它稳定、安全又免费。

8.1、示例

首先在GitHub上创建一个全新的项目：

文本框中输入“username .github.io”（其中username是指自己的GitHub账号。

接着找一个空的目录，创建index.html，内容如下：

mkdir blog
cd blog
git init
vim index.html

<!DOCTYPE html> 
<html>   
<head>     
	<meta charset="utf-8">     
	<title> 你好，GitHub</title>   
</head>   
<body>     
	<h1> Hi! </h1>   
</body> 
</html>

然后Push到Github：

git add .
git commit -m "first commit"
git remote add origin git@github.com:ActonZhang1024/ActonZhang1024.github.io.git
git push -u origin master

顺利推上去之后，回到项目页面，可以看到内容已经被推上去了：

然后，在仓库设置中设置发布源的分支：

这时，输入网址https://ActonZhang1024.github.io/即可连接页面：

另外，市面上也有一些比较好用的第三方套件，如Jekyll、Octopress。可以利用这些套件，以Markdown语法编写，系统会帮你转成HTML格式或生成整个Blog，甚至可以一行指令直接上传到GitHub Pages上。详情可参阅这些套件的官方网站：

• Jekyll: https://jekyllrb.com/
• Octopress: http://octopress.org/

8.2、客制化网址

GitHub Pages支持客制化（或称定制化）网址。如果原来的网址不好记，只需简单两步即可完成客制化：

1. 在该项目的根目录下创建一个名为CNAME的文件，内容只需输入要客制化的那个网址。
2. 请管理网域的人帮你设置一组CNAME指到eddiekao.github.io.即可。

9、更新文件（Patch）

9.1、制作更新文件

下面介绍更新文件（Patch）的制作方法。假设当前的历史记录如下：

接下来使用git format-patch指令生成几个更新文件：

git format-patch ca64c49..ab86f4e

后面的参数ca64c49…ab86f4e表示会生成从ca64c49这个Commit（不包括本身）到ab86f4e这个Commit的更新文件。

9.2、使用更新文件

要使用由format-patch指令生成的修正文件，需使用git am指令：

git am /demo/*

可以一次使用一个更新文件，或者像这样一口气把刚刚生成在/demo目录中的更新文件全部用上，Git会根据文件的名称依序套在现有的项目上。