Git——GitHub远端协作详解

目录

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文件:

shell 复制代码
mkdir demo
cd demo
echo "# git push demo" > README.md

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

shell 复制代码
git init 
git add .
git commit -m "first commit"

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

shell 复制代码
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

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

shell 复制代码
git push -u origin master

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

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

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

shell 复制代码
git push dragonball cat

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

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

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

1.2、upstream

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

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

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

shell 复制代码
git push -u origin master

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

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

shell 复制代码
git push origin master

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

shell 复制代码
$ 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的指令为:

shell 复制代码
git push origin master

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

shell 复制代码
git push origin master:master

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

shell 复制代码
git push origin master:cat

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

2、Pull下载更新

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

2.1、Fetch指令

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

shell 复制代码
git fetch

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

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

shell 复制代码
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):

shell 复制代码
git merge origin/master

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

2.3、Pull指令

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

shell 复制代码
git pull = git fetch + git merge

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

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

使用git pull:

shell 复制代码
git pull

注意,本次merge还是使用了快转模式(Fast Forward),如果不希望使用快转模式,可以使用--no-ff参数,即: git pull --no-ff

2.4、Pull+Rebase

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

shell 复制代码
git pull --rebase

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

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

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

shell 复制代码
$ 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

保存到暂存区并提交:

shell 复制代码
git add .
git commit -m "local update"

尝试推送,问题复现:

shell 复制代码
git push

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

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

shell 复制代码
git pull

解决冲突问题:

然后再提交并推送:

shell 复制代码
git add .
git commit -m "fixed conflicts"
git push

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

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

shell 复制代码
git push -f

4、Clone指令

4.1、Clone Repository

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

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

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

shell 复制代码
git clone git@github.com:ActonZhang1024/demo.git

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

shell 复制代码
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示例

准备工作:

shell 复制代码
项目地址: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回来修改

shell 复制代码
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过来的项目:

shell 复制代码
$ 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。接下来帮它加上另一个远端节点,这个远端节点指向的位置就是原作者的项目:

shell 复制代码
$ git remote add dummy-kao https://github.com/kaochenlong/dummy-git.git

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

shell 复制代码
$ 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指令取得原项目最新版本的内容:

shell 复制代码
$ git fetch dummy-kao  

Fetch下来之后,在本地的远端分支会往前移动吗?如果想要跟上刚抓下来的进度,就使用Merge指令(使用Rebase也可以):

shell 复制代码
git merge dummy-kao/master

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

第三步:推回自己的项目

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

shell 复制代码
git push origin master 

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

6、删除远端的分支

6.1、GitHub线上删除

单击中间的branches(分支)标签,可以看到当前所有的分支:

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

6.2、命令行删除

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

shell 复制代码
git push origin :cat

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

7、git push -f的使用场景

7.1、整理历史记录

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

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

7.2、只用在自己身上。

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

shell 复制代码
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,内容如下:

shell 复制代码
mkdir blog
cd blog
git init
vim index.html
html 复制代码
<!DOCTYPE html> 
<html>   
<head>     
	<meta charset="utf-8">     
	<title> 你好,GitHub</title>   
</head>   
<body>     
	<h1> Hi! </h1>   
</body> 
</html>

然后Push到Github:

shell 复制代码
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上。详情可参阅这些套件的官方网站:

8.2、客制化网址

GitHub Pages支持客制化(或称定制化)网址。如果原来的网址不好记,只需简单两步即可完成客制化:

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

9、更新文件(Patch)

9.1、制作更新文件

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

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

shell 复制代码
git format-patch ca64c49..ab86f4e

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

9.2、使用更新文件

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

shell 复制代码
git am /demo/*

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

相关推荐
小龙报20 分钟前
《彻底理解C语言指针全攻略(3)》
c语言·开发语言·windows·git·创业创新·学习方法·visual studio
foundbug9992 小时前
查看nginx日志文件
linux·nginx·github
whysqwhw3 小时前
使用Wire 基于 KMP实现imdk
github
whysqwhw4 小时前
wire 库介绍
github
前端备忘录4 小时前
创建好git项目仓库后如何将本地项目传上去
git
绝无仅有4 小时前
某大厂跳动Java面试真题之问题与解答总结(五)
后端·面试·github
绝无仅有4 小时前
某大厂跳动Java面试真题之问题与解答总结(四)
后端·面试·github
逛逛GitHub5 小时前
推荐 2 个 GitHub 上集成 Nano banana 的开源项目。
github
代码or搬砖6 小时前
Git学习笔记(二)
笔记·git·学习
sineiy6 小时前
git使用教程
git