GitHub实用指南

GitHub实用指南

1.GitHub简介

Git是一个运行在你你电脑的版本控制软件，而Github是基于Git这个版本控制软件打造的网址

GitHub与Git是完全不同的两个东西

在Git中，开发者将源代码存入名叫Git仓库的资料库中并加以使用。而GitHub则是在网络上提供Git仓库的一项服务

也就是说，GitHub上公开的软件源代码全部有Git进行管理。理解Git,是熟练运用GitHub的关键所在。

1.1 集中式和分布式区别

Git属于分散型版本管理系统，是为版本管理而设计的软件，版本管理就是管理更新的历史记录，在Git出现之前，人们普遍采用Subversion等集中型版本管理系统，而现在Git已经成为主流了，下面讲讲两者的区别。

集中式版本控制 CVS和SVN都是是属于集中式版本控制系统（Centralized Version Control Systems，简称 CVCS）

它们的主要特点是单一的集中管理的服务器，保存所有文件的修订版本； 协同开发人员通过客户端连接到这台服务器，取出最新的文件或者提交更新； 这种做法带来了许多好处，特别是相较于老式的本地管理来说，每个人都可以在一定程度上看到项目中的其他人正在做些什么。

但是集中式版本控制也有一个核心的问题：中央服务器不能出现故障：

如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作； 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据；

分布式版本控制

Git是属于分布式版本控制系统（Distributed Version Control System，简称 DVCS）

客户端并不只提取最新版本的文件快照， 而是把代码仓库完整地镜像下来，包括完整的历史记录； 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复； 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份； 目前在公司开发中都是使用Git来管理项目的，所以接下来会重点学习Git的各种用法；

1.2 官网下载安装

Git的官网：git-scm.com/downloads

根据自己的操作系统下载Git即可；

在window操作系统按照默认配置全局安装即可

2.使用GitHub的前期准备

2.1 设置SSH Key

GitHub 上连接已有仓库时的认证，是通过使用了SSH的公开密钥认证方式进行的。现在让我们来创建公开密钥认证所需的 SSHKey，并将其添加至GitHub。已经创建过的读者，请用现有的密钥进行设置

运行下面的命令创建SSH Key

$ssh-keygen -t rsa -C "your_email@example.com"
Generating public/private rsa key pair.
Enter file in which to save the key
(/Userslyour_user_directoryl.sshid_rsa):按回车键
Enter passphrase(empty for no passphrase):输入密码
Enter same passphrase again:再次输入密码

"your_email@example.com"的部分请改成您在创建账户时用的邮箱地址。密码需要在认证时输入，请选择复杂度高并且容易记忆的 组合。

输入密码后会出现以下结果。

输入密码后会出现以下结果。
Your identification has been saved in /Users/your_user_directoryl.sshlid_rsa.
Your public key has been saved in /Userslyour_user_directoryl.sshid_rsa.pub.
The key fingerprint is:
fingerprint值 your_email@example.com
The key's randomart image is:
+--[ RSA 2048]---+
.++l=oo.l
略

id_rsa文件是私有密钥，id_rsa.pub是公开密钥。 添加公开密钥 在GitHub中添加公开密钥，今后就可以用私有密钥进行认证了。 点击右上角的账户设定按钮(Account Settings)，选择SSHKeys菜单之后，就会出现如图3.2的界面。点击Add SSH Key，会出现Title和Key两个输入框。在Title 中输入适当的密钥名称。Key部分请粘贴id_rsa.pub文件里的内容。id_rsa.pub的内容可以用如下方法查看。

$ cat ~/.ssh/id _rsa.pub
ssh-rsa公开密钥的内容your_email@example.com

添加成功之后，创建账户时所用的邮箱会接到一封提示"公共密钥添加完成"的邮件。然后就大功告成啦!

3.实际操作学习Git

3.1 在现有的目录中初始化仓库 git init

如果自己有一个尚未进行版本控制的项目目录，想要用Git来控制它，需要执行如下两个步骤：

在项目目录中，通过鼠标右键打开"Git Bash" 执行git init命令将当前的目录转换为Git仓库 git init命令会创建一个名为.git的隐藏目录，这个.git目录就是当前项目的Git仓库，里面包含了初始的必要文件，这些文件是Git仓库的必要组成部分。

3.2 工作区中文件的4种状态

Git操作的终极结果：让工作区中的文件都处于"未修改"的状态。

3.3 检查文件的状态 git status

可用使用git status命令查看文件处于什么状态，例如：

在状态报告中可用看到新建的index.html文件出现在Untracked files（未跟踪的文件）下面。未跟踪的文件意味着Git在之前的快照（提交）中没有这些文件；Git不会自动将之纳入跟踪范围，除非明确地告诉它"我需要使用Git跟踪管理该文件"。

精简的方式输出的状态报告 git status -s

以git status输出的状态报告很详细，但有些繁琐。如果希望以精简的方式显示文件的状态，可以使用如下两条完全等价的命令，其中 -s是 --short的简写形式： #以精简的方式显示文件状态 git status -s git status --short 未跟踪文件前面有红色的？？标记。

3.4 跟踪新文件 git add index.html

使用命令git add开始跟踪一个文件。所以，要跟踪index.html文件，运行如下的命令即可： git add index.html 此时再运行git status命令，会看到index.html文件在Changes to be committed这行的下面，说明已被跟踪，并处于暂存状态：

以精简的方式显示文件的状态： 新添加到暂存区中的文件前面有绿色的A标记

3.5 提交更新 git commit -m "描述文字"

现在暂存区中有一个index.html文件等待被提交到Git仓库中进行保存。可以执行git commit命令进行提交，其中 -m选项后面是本次的提交消息，用来对提交的内容做进一步的描述： git commit -m "新建了index.html文件"

提交成功之后，再次git status检查文件的状态，得到提示如下： nothing to commit, working tree clean 证明工作区中所有的文件都处于"未修改"的状态，没有任何文件需要被提交。

3.6 对已提交的文件进行修改

目前，index.html文件已经被Git跟踪，并且工作区和Git仓库中的index.html文件内容保持一致。当我们修改了工作区中index.html的内容之后，再次运行git status和 git status -s命令，会看到如下的内容：

文件index.html出现Changes not staged for commit这行下面，说明已跟踪文件的内容发生了变化，但还没放到暂存区。

注意：修改过的、没有放入暂存区的文件前面有红色的M标记。

3.7 暂存已修改的文件 git add index.html

目前，工作区中的index.html文件已被修改，如果要暂存这次修改，需要再次运行git add命令，这个命令是个多功能的命令，主要有如下3个功效： 1、可以用它开始跟踪新文件 2、把已跟踪的、且已修改的文件放到暂存区 3、把有冲突的文件标记为已解决状态

提交已暂存的文件 git commit -m "描述文字" 再次运行git commit -m "提交消息"命令，即可将暂存区中记录的index.html的快照，提交到Git仓库中进行保存。

3.8 跳过使用暂存区域 git commit -a -m

Git标准的工作流程是工作区->暂存区->Git仓库，但有时候这么做略显繁琐，此时可以跳过暂存区，直接将工作区中的修改提交到Git仓库，这时候Git工作的流程简化为了工作区->Git仓库。 Git提供了一个跳过使用暂存区域的方式，只要在提交的时候，给git commit加上 -a选项，Git就会自动把所有已经跟踪过的文件一并提交，从而跳过git add步骤： git commit -a -m "描述消息"

3.9 查看提交历史 git log

如果希望回顾项目的提交历史，可以使用git log这个简单且有效的命令。

想要了解更多的命令可以去这个地址看看

t.csdnimg.cn/f7Avn

4.分支操作

在进行多个并行作业时，我们会用到分支。在这类并行开发的过程中,往往同时存在多个最新代码状态。如图所示，从master分支创建feature-A分支和 fix-B分支后,每个分支中都拥有自己的最新代码。master分支是Git默认创建的分支，因此基本上所有开发都是以这个分支为中心进行的。

不同分支中，可以同时进行完全不同的作业。等该分支的作业完成之后再与master分支合并。比如 feature-A分支的作业结束后与master合并，

通过灵活运用分支,可以让多人同时高效地进行并行开发。

4.1 git branch------显示分支一览表

git branch命令可以将分支名列表显示,同时可以确认当前所在分支。让我们来实际运行git branch命令。

$ git branch
*master

可以看到master分支左侧标有"*"(星号)、表示这是我们当前所在的分支。也就是说，我们正在master分支下讲行开发。结果中没有显示其他分支名,表示本地仓库中只存在master一个分支。

4.2 git checkout -b------创建、切换分支

如果想以当前的master分支为基础创建新的分支 ，我们需要用到git checkout -b命令。

切换到feature-A分支并进行提交

执行下面的命令，创建名为feature-A的分支。

$ git checkout -b feature-A
Switched to a new branch 'feature-A'

实际上，连续下面这两条命令也能收到同样效果。

$ git branch feature-A
$ git checkout feature-A

创建feature-A 这时再来查看分支列表，会显示我们处于feature-A分支下。

$ git branch
* feature-A
  master

4.3 git merge------合并分支

接下来，我们假设feature-A已经实现完毕,想要将它合并到主干分支master 中。首先切换到master分支。

$ git checkout master
Switched to branch 'master'

然后合并feature-A分支。为了在历史记录中明确记录下本次分支合并，我们需要创建合并提交。因此,在合并时加上--no-ff参数。

$ git merge --no-ff feature-A

随后编辑器会启动．用于录入合并提交的信息。

Merge branch 'feature-A'
# Please entar a n  e1ain why this merae is necessary,#especia11x if itoio tmeSsage cond paatream into a topic branch.
#
# Lines stat. 1,and an emotv message abortsthe commit.

默认信息中已经包合了是从feature分支合并过来的相关内容，所以可不必做任何更改。将编辑器中显示的内容保存，关闭编辑器，然后

就会看到下面的结果。

Merge made by the 'recursive' strategy.README.md 2++
1 file changed, 2 insertions(+)

这样一来,feature-A分支的内容就合并到master 分支中了。

5.推送至远程仓库

Git是分散型版本管理系统,但我们前面所学习的,都是针对单一本地仓库 的操作。下面,我们将开始接触远在网络另一头的远程仓库。远程仓库顾名思义,是与我们本地仓库相对独立的另一个仓库。让我们先在GitHub上创建一个仓库,并将其设置为本地仓库的远程仓库。

5.1 git remote add-------添加远程仓库

在GitHub 上创建的仓库路径为"git@github.com:用户名/仓库名.git"。现在我们用git remote add命令将它设置成本地仓库的远程仓库。

git remote add origin git@github.com:用户名/仓库名.git

按照上述格式执行git remote add命令之后，Git会自动将git@github.com:用户名/仓库名.git远程仓库的名称设置为origin(标识符)。

5.2 git push------推送至远程仓库

如果想将当前分支下本地仓库中的内容推送给远程仓库，需要用到git push命令。现在假定我们在master分支下进行操作。

$ git push -u origin master

像这样执行git push命令，当前分支的内容就会被推送给远程仓库的origin的master分支。-u参数可以在推送的同时，将origin仓库的master分支设置为本地仓库当前分支的upstream（上游）。添加了这个参数，将来运行git pull命令从远程仓库获取内容时，本地仓库的这个分支就可以直接从origin的master分支获取内容，省去了另外添加的麻烦

执行该操作后，当前本地仓库master分支的内容将会被推送到GitHub的远程仓库中。在GitHub上也可以确认远程master分支的内容和本地master分支相同。

推送至master 以外的分支

$ git checkout -b feature-D
Switched to a new branch 'feature-D'

我们在本地仓库中创建了feature-D分支，现在将它push给远程仓库并保持分支名称不变。

$ git push -u origin feature-D

现在,在远程仓库的GitHub 页面就可以查看到 feature-D分支了。

6. 从远程仓库获取

上一节中我们把在GitHub上新建的仓库设置成了远程仓库，并向这个仓库push 了 feafure-D分支。现在，所有能够访问这个远程仓库的人都可以获取feature-D分支并加以修改。

本节中我们从守际开发者的角度出发,在另一个目录下新建一个本也仓库，学习从远程仓库获取内容的相关操作。这就相当于我们刚刚执过Push操作的目标仓库又有了另一名新开发者来共同开发

6.1 git clone------获取远程仓库

git clone git@github.com:用户名/仓库名.git

执行git clone命令后我们会默认处于master分支下，同时系统会自动将origin设置成该远程仓库的标识符。也就是说，当前本地仓库的 master分支与GitHub端远程仓库( origin )的master分支在内容上是完全相同的。

git branch -a(注意要在克隆的文件里打开终端执行该命令)

我们用git branch -a命令查看当前分支的相关信息。添加-a参数可以同时显示本地仓库和远程仓库的分支信息。

结果中显示了remotes/origin/feature-D我们的远程合库中已经有了feature-D分支。

6.2 获取远程的feature-D分支

我们试着将feature-D分支获取至本地仓库。

git checkout -b feature-D origin/feature-D

-b参数的后面是本地仓库中新建分支的名称。为了便于理解，我们仍将其命名为feature-D,让它与远程仓库的对应分支保持同名。新建分支名称后面是获取来源的分支名称。例子中指定了origin/feature-D,就是说以名为origin的仓库（这里指github端的仓库）的feature-D分支为来源，在本地仓库创建feature-D分支

现在假定我们是另一名开发者，要做一个新的提交。

可以在index.html里面随便加点，然后按照之前学过的方式提交即可 执行到git commit -m " "

6.3 推送feature-D分支

现在来推送feature-D分支

$ git push

从远程仓库获取feature-D分支，在本地仓库中提交更改,再将feature-D分支推送回远程合库,通过这一系列操作，就可以与其他开发者相互合作，共同培育 feature-D分支，实现某些功能。

6.4 git pull------获取最新的远程仓库分支

现在我们放下刚刚操作的目录，回到原先的那个目录下。这边的本地仓库中只创建了feature-D分支，并没有在feature-D分支中进行任何提交。然而远程仓库的feature -D分支中已经有了我们刚刚推送的提交，这时我们就可以使用git pull命令，将本地的feature-D分支更新到最新状态，当前分支为feature -D分支。

$ git pull origin feature-D

GitHub端远程仓库中的 feature-D分支是最新状态，所以本地仓库中的 feature-D分支就得到了更新。今后只需要像平常一样在本地进行提交再push给远程仓库，就可以与其他开发者同时在同一个分支中进行作业，不断给feature-D增加新功能。

如果两人同时修改了同一部分的源代码, push时就很容易发生冲突。所以多名开发者在同-个分支进行作业时为减少冲突情况的发生，建议更频繁地进行push和 pull操作。

7.trending

Github已经成为全球最大的开源项目托管平台，目前该平台上已经有780万个项目库，平均每天有超过80000个版本库更新，7000名用户建立第一个GitHub软件库。

各种各样的项目都已经托管在Github上，甚至包括 白宫开放数据政策、 芝加哥自行车路线 之类的项目。

当今Github开发团队上线了一个新的Trending（趋势）页面，使得开发者可以很容易地找到一些有潜力的开源项目。

Trending Repositories（趋势库）

在该页面中，在Repositories标签下展示了前25个有潜力的开源项目。其中包括组织/库的名称、所使用的主要编程语言、库描述、Star按钮以及该项目贡献者前5名。

无论是Trending Repositories还是Trending Developers，你都可以按照时间范围（天、周、月）和编程语言来重新筛选。

这个排名是Github根据一系列数据（比如star数、fork数、提交数、follow数以及项目页面浏览量）进行统计的。Github每天会进行8次统计，并根据结果刷新该页面。

Trending页面只显示前25个项目或开发者，你可以通过 search功能来查找更多项目。

8.GitHub action

大家在工作中想必都是通过自动化部署来进行前端项目的部署的，也就是我们在开发完某个需求时，我们只需要将代码推送到某个分支，然后就能自动完成部署，我们一般不用关心项目是如何build以及如何deploy的，这就极大得提高了我们的开发效率。

在没有自动化部署的情况下，前端项目的部署流程一般是这样的：（手动部署）

• 本地开发代码
• build成上线的dist包
• 将打包文件上传到服务器的指定目录

前端项目每次上线都得走一遍这个流程，对于程序员来讲这怎么能忍，宁愿将时间浪费在B乎上也不可能浪费在这些毫无技术的工作流程上，并且人工操作，难免会出错。因此现在来学习一下github action如何实现自动化部署自己的前端项目。

github action支持push驱动，启动一个小虚拟机，帮助我们build 部署和持续开发

在进行学习前 先要有个人令牌以及把令牌配置到该仓库中 可以去下面这个网址学习配置好了再往下面看

如果要自己部署的话就点set up a workflow yourself 也可以选择下方的推荐 这边演示直接点击推荐的

编写GithubAction的流程时，需要创建一个workflow工作流，workflow必须存储在你的项目库根路径下的.github/workflows目录中，每一个 workflow对应一个具体的.yml 文件

一些概念：

name:定义的名字

on:触发它的机制，这里就是当master分支被推送代码时就会执行下面那些代码

workflow: 一个 workflow 就是一个完整的工作流过程，每个workflow 包含一组 jobs任务。

job :执行的具体的一个任务。

runs-on：在哪个操作系统下

step : 每个 step 步骤可以执行指令或者使用一个 action 动作。

我们主要需要改动的就是step，比如需要在wordpress上部署 这里就要写相关的代码 下次推送代码到github后 github就直接帮你部署到该网站了，你就不需要在去wordpress里进行手动部署了 这里我们直接点右上角commit changes 就完成了一个最基本的创建

接下来每一次提交在这里都会生成一个工作流 可以点击该仓库的settings 在左边有个page 再点击save就可以生成一个网址 可以发送给别人看 这是因为github生成了一个小虚拟机

9.pr请求

在GitHub中，PR是指Pull Request（拉取请求）的缩写。Pull Request是一种协作机制，允许开发者将其修改的代码推送到项目的仓库中，并邀请项目负责人或其他开发者审核和接受这些修改。

找到开源项目地址，然后fork一下，就可以把开源项目的代码复制到你的github账号里

点击自己github仓库的github_test项目的Code按钮，复制http或者ssh的链接，例如我复制的是ssh链接为：git@github.com:Chasing987/github_test.git

然后，在本地新建一个文件夹 这个文件夹的名字可以随便命名，最好不要有中文即可 文件夹用vscode打开，然后进入项目文件夹打开终端 执行 git clone git@github.com:Chasing987/github_test.git .

接下来执行如下操作：

通过git remote -v查看是不是只有你自己的仓库的链接，如果是，则需要通过通过下面的命令链接上游代码库

如果你要添加功能，你可以先创建分支，在分支上添加功能

然后，添加功能，随便添加点内容或者文件啥的 记得保存 使用git操作命令，最后推送这远端的github仓库

然后，回到自己的github仓库，刷新一下，就可以有这个分支了

点击Compare & pull request，创建一个pr

随后，就出现下面这个页面了

在开源项目那端，只需要合并即可

pr教程 github.com/lyfCSU/gith...