GitHub 入门 与 2023年2月18日10:29:02

用 GitHub 有一段时间了，之前一直用来做 Hexo 的服务器，直到前阵子搞 GitHub Action 因为命令不熟，把 GitHub 上的源码强制拉到本地把本地的 Hexo 搞崩了，博客源码都没了 ，哭辽 。。。

参考内容：

• 《GitHub入门与实践 (大塚弘记) 》

今天周六

好消息：今天周六

坏消息：今天阴天

什么是 Github

GitHub 是为开发者提供 Git 仓库的托管服务，这是一个让开发者与 朋友、同事、同学及陌生人共享代码的完美场所。GitHub 除提供 Git 仓库的托管服务外，还为开发者或团队提供了一 系列功能，帮助其高效率、高品质地进行代码编写。

GitHub 与 Git 的区别

在 Git 中，开发者将源代码存入名叫“Git 仓库”的资料库中 并加以使用。而 GitHub 则是在网络上提供 Git 仓库的一项服务。 也就是说，GitHub 上公开的软件源代码全都由 Git 进行管 理。理解 Git，是熟练运用 GitHub 的关键所在。

Git 的导入

Git 仓库管理功能是 GitHub 的核心。因此，使用 GitHub 之前必须 先掌握 Git 的相关知识，同时本地的设备还要安装 Git 的环境。Git 属于分散型版本管理系统，是为版本管理而设计的软件。版本管理就是管理更新的历史记录。它为我们提供了一些在软件开 发过程中必不可少的功能，例如记录一款软件添加或更改源代码的过 程，回滚到特定阶段，恢复误删除的文件等。

• 安装 Git

• 初始配置：姓名和邮箱地址

  $ git config --global user.name "Firstname Lastname"
  $ git config --global user.email "example_email@example.com"
  

• SSH Key

  GitHub 上连接已有仓库时的认证，是通过使用了 SSH 的公开密钥 认证方式进行的。

  • 创建 SSH Key

    $ ssh-keygen -t rsa -C "example_email@example.com"
    Generating public/private rsa key pair.
    Enter file in which to save the key (/c/Users/***/.ssh/id_rsa):
    Created directory '/c/Users/***/.ssh'.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /c/Users/***/.ssh/id_rsa
    Your public key has been saved in /c/Users/***/.ssh/id_rsa.pub
    The key fingerprint is:
    ***************************************************
    The key's randomart image is:
    ****************************************************
    

    id_rsa 文件是私有密钥，id_rsa.pub 是公开密钥。

• 添加公开密匙

  cat ~/.ssh/id_rsa.pub可以查看公开密匙内容

  GitHub 账户 => 设置 => SSH Keys => Add SSH Key

  

​ 添加成功之后，创建账户时所用的邮箱会接到一封提示“公共密钥 添加完成”的邮件。完成以上设置后，就可以用手中的私人密钥与 GitHub 进行认证和 通信了。

​ ssh -T git@github.com

• GitHub 创建仓库说明

尝试在已有仓库中添加代码并加以公开

git clone git@github.com:xxx/Hello-GitHub.git

cd Hello-GitHub/

手动在目录下创建一个文件，并添加至 GitHub 仓库。通过 git add 命令将文件加入暂存区 A，再通过 git commit命令 提交。 添加成功后，可以通过 git log命令查看提交日志。

之后只要执行 push，GitHub 上的仓库就会被更新：

git push 常见错误：! [rejected]

当本地仓库与远程仓库版本不一致时会出现该问题，养成先 pull 最新代码再修改的习惯即可 ，在修改本地代码前，先使用 git pull 拉取远程最新代码，然后再进行修改（推荐--rebase）

git pull 远程仓库名 远程分支名 --rebase

也可强制推送【仅推荐在确认代码没问题的情况下使用】：

git push --force

详细说明，请参考：

上述操作就是初次在 GitHub 建立仓库以及公开代码的流程

Git 学习

常用命令

基本操作	操作说明	具体演示
git init 初始化仓库	使用 Git 进行版本管理必须先初始化仓库，如果初始化成功，会在目录下生成 .git 隐藏目录，里面存储着管理当前目录内容所需的仓库数据，这个目录被称为“附属于该仓库的工作树”。
git status 查看仓库状态	工作树和仓库在被操作的过程中，状态会不断发生变化。在 Git 操 作过程中时常用 git status命令查看当前状态，可谓基本中的基本。
git add 向暂存区添加文件	如果只是用 Git 仓库的工作树创建了文件，那么该文件并不会被记入 Git 仓库的版本管理对象当中。因此我们用 git status命令查看 README.md 文件时，它会显示在 Untracked files 里。要想让文件成为 Git 仓库的管理对象，就需要用 git add命令将其加入暂存区（Stage 或者 Index）中。暂存区是提交之前的一个临时区域。	-----
git commit 保存仓库的历史记录	git commit命令可以将当前暂存区中的文件实际保存到仓库的历 史记录中。通过这些记录，我们就可以在工作树中复原文件	git commit -m "First commit" 提交信息，不加 - m ，会进入比较详细的提交信息编写
git log 查看提交日志	g i t l o g命令可以查看以往仓库中提交的日志 git log --pretty=short可以只显示第一行简述信息 git log xxx.xx只要在 git log命令后加上目录名，便会只显示该目录下的日志。 如果加的是文件名，就会只显示与该文件相关的日志。 $ git log -p如果想查看提交所带来的改动，可以加上 - p参数，文件的前后差 别就会显示在提交信息之后。可在 - p 加上具体内容来查看具体文件提交前后差别
git diff 查看更改前后 的差别	git diff命令可以查看工作树、暂存区、最新提交之间的差别。不妨养成这样一个好习惯：在执行 git commit命令之前先执行 git diff HEAD命令，查看本次提交与上次提交之间有什么差别，等 确认完毕后再进行提交。这里的 HEAD 是指向当前分支中最新一次提交 的指针

分支操作

master 分支是 Git 默认创建的分支。

基本操作	操作说明	具体演示
git branch 显示分支一览表	git branch命令可以将分支名列表显示，同时可以确认当前所在 分支（*）。
git checkout -b 创建、切换分支	git branch feature-XXX git checkout feature-XXX git checkout -切换回上一分支	当新建一个本地仓库的时候没有任何操作的情况下操作分支时就会出现这样一个报错信息，根据提示可以知道是因为没有一个叫"master"的提交对象，如果你使用git branch会发现分支列表没内容，这是因为你首先需要进行一次提交操作，因为分支的指针是要指向提交的，但是进行一次提交就需要有一次 add 操作，所以在新建一个本地仓库后最好就进行一次 add => commit 操作。
特性分支	特性分支顾名思义，是集中实现单一特性（主题），除此之外不进 行任何作业的分支。在日常开发中，往往会创建数个特性分支，同时在 此之外再保留一个随时可以发布软件的稳定分支。稳定分支的角色通常 由 master 分支担当。	之前我们创建了 feature-A 分支，这一分支主要实现 feature-A，除 feature-A 的实现之外不进行任何作业。即便在开发过程中发现了 BUG， 也需要再创建新的分支，在新分支中进行修正。基于特定主题的作业在特性分支中进行，主题完成后再与 master 分 支合并。只要保持这样一个开发流程，就能保证 master 分支可以随时供 人查看。
git merge 合并分支	我们假设 feature-A 已经实现完毕，想要将它合并到主干分 支 master 中。	首先切换到 master 分支，创建合并提交以记录本次分支合并 git merge --no-ff feature-A
git log --graph 以图表形式查看分支	git log --graph命令可以用图表形式输出提交日志，非常直 观，请大家务必记住。
git reset 回溯历史版本	回溯到创建 feature-A 分支前，git rest --hard 命令,只要提供目标时间点的哈希值 ，就可以完全恢复至该时间点的状态	git reset --hard fd0cbf0d4a25f747230694d95cac1be72d33441d
	创建 fix-B 分支,修改README文件并提交 git checkout -b fix-B
	推进至 feature-A 分支合并后的状态	首先恢复到 feature-A 分支合并后的状态，执行 git reflog 命令，查看当前仓库执行过的操作的日志。git log命令只能查看以当前状态为终点的历史日志。所以这里 要使用 git reflog命令，查看当前仓库的操作日志.
	消除冲突	现在只要合并 fix-B 分支，就可以得到我们想要的状态，进行合并操作发现被操作的文件出现了冲突，修正让 feature-A 与 fix-B 的内容并存于文件之中。
		冲突解决后，执行 git add命令与 git commit命令提交解决后的结果。
	git commit --amend 修改提交信息
git rebase -i 压缩历史	在合并特性分支之前，如果发现已提交的内容中有些许拼写错误等， 不妨提交一个修改，然后将这个修改包含到前一个提交之中，压缩成一 个历史记录。	自行修改错误，然后提交

尝试 Pull Request

Pull Request 是自己修改源代 码后，请求对方仓库采纳该修改时采取的一种行为。

只要 Pull Request 被顺利采纳，我们就会成为这个项目的 Contributor （贡献者），我们编写的这段代码也将被全世界的人使用。这正是社会化编程和开源开发的一大乐趣。

使用教材中提供的仓库进行一次PR

Fork到自己的仓库中：

clone 到本地仓库：

在特性分支中修改代码，创建一个名为work的分支，用来发送PR：

查看修改是否已经正确进行：

确认添加并提交至本地仓库：

创建远程分支：

要从 GitHub 发送 Pull Request，GitHub 端的仓库中必须有一个包 含了修改后代码的分支。

这个时候在 GitHub 就可以查看到 work 分支了：

发送PR：

在 GitHub 切换到 work 分支可以查看分支间差异，确认无误后右上角绿色按钮创建PR：

一次尊贵的PR就完成了。

们从远程仓库实际获取（fetch）最新源代码，与自己仓库的 分支进行合并。要让仓库维持最新状态，只需要重复这一工作即可。

接受 Pull Request

下面我们来作为管理者接收我们的PR，首先将我们发送PR的仓库Clone到本地：

获取咱们的远程仓库：

创建用于检查的分支，并检查提交内容，确认无误后删除检查分支：

接受PR：

在 push 修改之前，我们先检查一遍本地代码与远程仓库的区别：

确实区别为我们提交的内容，进行 push ：

嘿 ，Surprise! 没权限。

嘿 ，有问题：

可以通过其他人的PR！！！