用 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 "[email protected]"
-
SSH Key
GitHub 上连接已有仓库时的认证,是通过使用了 SSH 的公开密钥 认证方式进行的。
-
创建 SSH Key
$ ssh-keygen -t rsa -C "[email protected]" 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 [email protected]
- GitHub 创建仓库说明
尝试在已有仓库中添加代码并加以公开
git clone [email protected]: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 - 切换回上一分支 |
![]() 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! 没权限。
标签:02,10,GitHub,仓库,Git,git,提交,分支 From: https://www.cnblogs.com/BoiledYakult/p/17133209.html