这篇博文本来是想在俱乐部 (opens new window)博客写的,不过最近俱乐部博客正计划用 WordPress 重构,链接可能会失效,于是就放到个人博客了。

本文将简要介绍 Windows Subsystem for Linux、Ubuntu、Git 的配置及简单使用。

# 为什么要学习 Git

Git 是什么?为什么要学习 Git?

Git —— 维基百科

什么叫 分布式 版本控制 软件?

什么是版本控制?假设你正在写一个非常重要的程序,为了保险,你可能会对每天下班时的版本进行存档、备份;同时,由于你可能在一个基础版本 A 上尝试添加新功能,写到一半(称作版本 B)失败了,需要回到 A;但是过了几天你又发现 B 版本的代码有可以借鉴的部分,所以需要结合最新的版本和 B 的代码。如果不借助软件来进行管理,可能后果就是你创建了一堆 程序-1.0 程序-2.0 程序-20201119 程序-新功能(失败了呜呜呜) 程序-定稿(修改版)-真定稿 文件夹。

更混乱的是,软件开发通常不是一个人,要是几个人的一堆版本混在一起,要进行管理就更混乱了。

于是,我们需要版本控制软件 Version Control Software 来做这件事情。

# Git 版本控制基本概念:提交和分支

Git 做的事情,就是在项目文件夹中创建一个 .git 文件夹,保存你的每一次提交 commitgit 的版本管理以提交为单位)。

对于单人的项目,你随时可以进行一次提交 git commit,保存这个版本的代码,也可以回到之前的任意一次提交时的版本。这些都是以提交为基础,可见提交真的是 Git 最重要的概念。

对于多人项目,Git 引入了分支 branch 的概念。

分支和提交(时间线为从左到右)

在 Git 图上,提交是每一个点(这个点保存了你提交时的代码版本),分支就是由点(提交)串起来的线。

上图的 Git 仓库中存在四个分支,正式版 master、开发版 dev、每个人的工作分支 michael bob

master 分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;

那在哪干活呢?Michael 和 Bob 都在自己的分支上干活,每个人都有自己的分支。每个人的开发分支都是从 dev 分裂出来的;开发得差不多后,时不时地往 dev 分支上合并 merge 自己的代码。等到一个稳定的版本要发布时(如 v1.0.0),就把 dev 的代码合并到 master

即使是单人的项目也可以弄一堆分支出来,用于开发新功能什么的。当然,单人的项目一般不会有这么多分支,就是一条直线。比如,我的博客的分支图(由 VS Code 的 Git Graph 插件 (opens new window)生成)如下:

我的博客的分支图

# Git 分布式

Git 为什么是分布式的呢?

Git 每次是把远端(GitHub 或其他同类网站)的整个库克隆下来 git clone,提交是在本地创建一个新的点(提交),而上传到远端需要使用 git push 进行推送。所以,Git 中本地和云端的内容是基本相同的,Git 库内容不仅存于云端,还分布在每个开发者的电脑上。

Git 远端的默认名为 origin,所以你可能会看到 origin/master,这指的是这个仓库在 GitHub(或同类网站)上的 master 分支。

我们平时最好在提交之后,及时 push 至 GitHub 上,这也是起了将代码备份到云端的效果(顺便一提,数据无价,备份很重要!!!!这学期我们班已经有三个人电脑挂了,要是没有备份,实验报告和论文就没了)。

# 为什么要学习 WSL

Git 软件本身是跨平台的,为什么不直接在 Windows 上使用 Git,而是在 WSL 上使用 Git 呢?

我在 WSL 下使用 Git,最大的原因是 Linux 命令行的自动补全:

在 bash 或 zsh 等 shell 中输入 gitgit 后有空格)然后按两次 Tab,它会提示接下来可能的命令;
输入 git a 然后按两次 Tab,它会提示 a 开头的可能命令;
如果输入 git ad (此时 shell 已经能确定是 git add 了)然后按一次 Tab,就会自动补全为 git add

bash 自动补全

可以说,自动补全可以大幅降低萌新对命令行的学习成本,而这是 Windows 的 shell —— cmd 和 powershell 都不具备的(这两个只能补全文件名,不能补全命令)。所以,使用 CLI 工具时,我更提倡使用 WSL 作为基础。

当然,为了某些能集成 Windows 下 Git 的应用(如 VS Code、各大 IDE、Tortoise Git 这个第三方 Git GUI),我也在 Windows 下安装了 Git,不过,用 Git 命令行时,我也一直使用的是 WSL 下的 Git。

当然,如果你觉得安装一个 WSL 占空间、太麻烦、不必要,也可以跳过 WSL,体验 Windows 上的 Git。

# 安利工具 Visual Studio Code 和 Windows Terminal

Windows Terminal (opens new window) 是微软(抬头看看俱乐部名)官方推出的终端应用程序(terminal,可以简单地理解是 cmd powershell bash 等 shell 的外壳),美观好看,且启动速度快。

前为 Windows Terminal,后为 Powershell

在这里安利 Windows Terminal 是因为后面将介绍的 WSL 和 Git 都是 CLI(命令行)的形式,因此一款高颜值的终端应用程序是很有必要的~

一些 Windows Terminal 使用小技巧

为安装了 Windows Terminal 的同学提供一个小练习:输入 cmd 可以启动命令提示符,那么输入什么(不超过三个字母)能启动 Windows Terminal 呢?你可以尝试自行百度 / Google,或自行寻找答案。


Visual Studio Code (opens new window) 是微软(再次抬头看看俱乐部名)官方推出的一款很强大的文本编辑器(注意,不是 IDE),可以替代 Notepad++ 等同类软件,具有开源、集成 terminal、插件众多、UI 好看、开箱即用同时自定义程度高、能同步设置等优点。(最近写微信小程序,发现它的开发软件也是基于 VS Code 魔改的)

我就正在 Visual Studio Code 中编写这篇博客。

套娃警告

在这里安利 Visual Studio Code,是因为它装上插件 (opens new window)以后,能和 WSL 无缝衔接,作为 WSL 的文本编辑器,不会使用 vim、nano 等命令行文本编辑器的同学就可以使用 VS Code 作为 WSL 的文本编辑器啦~

在 wsl 中输入 code <文件名> 即可启动 VS Code 编辑文本文件

一些 Visual Studio Code 使用小技巧 (opens new window)

# Windows Subsystem for Linux 下载和安装

微软提供了官方中文教程 (opens new window),我就不再赘述了。

对于 WSL1 和 WSL2 的选择,官方也提供了对比文 (opens new window),由于我更常在 WSL 中使用 Git 和 Hexo 对 C 盘的文件进行操作,对“跨 OS 文件系统的性能”需求大,因此选择了 WSL1。

Linux 开发版的选择上,本文将以 Ubuntu 20.04 LTS 作示范。

由于下载安装比较费时间,请各位同学在沙龙开始之前完成 WSL 的安装。之后的部分将在沙龙上讲述,并且会在沙龙后进行更新~


开始菜单的 Ubuntu

下载完成后,点击开始菜单的 Ubuntu 即可开始安装。

安装过程

如果没有出现上面这个界面,而是显示 0x80004003 或类似错误提示,请读者以 WSL + 错误码作关键字进行搜索,或对照上文中提到的 WSL 官方中文教程。

然后就是初始化账号和密码,这和其他系统安装均类似。注意输入密码时,用户的输入并不会回显在屏幕上,这是为了安全考虑,还请读者不要见怪。

输入账号、密码、确认密码均正确后,即可进入系统,如下。

进入系统

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

上面这行字表示,如果需要以管理员身份运行某些命令(如安装软件),需要在命令前加 sudo。这句的效果类似于 Windows 的用户账户控制,授予管理员权限才可以安装程序。

Windows 用户账户控制


如果配置的过程中关闭了初始化用户名和密码的窗口,会导致初始化用户失败,WSL 将以 root 身份(而不是定义的用户)运行。此时可以执行以下命令,卸载 WSL,然后点击开始菜单的 Ubuntu 重新安装。

wsl --unregister Ubuntu-20.04

其中 Ubuntu-20.04 根据发行版不同而不同,可在 cmd 下使用 wsl -l 命令查询。

# Ubuntu 安装软件

在 Windows 上,安装软件的方式一般是找到官网的下载页面,下载 exe 或 msi,然后运行。

也有如 360 软件管家这类软件管理工具。

在 Ubuntu 上,使用的是官方的软件管理程序 apt

apt

下载安装软件的命令为 sudo apt install。下文将演示使用 apt 安装 screenfetch

在 sudo apt update 之前 sudo apt install screenfetch

和 360 软件管家不同的是,apt 并不会自动在线获取软件的最新信息,而是将这些信息缓存在本地。我们刚完成系统安装,信息都还没有缓存,所以需要手动 sudo apt update

sudo apt update

接下来就是 sudo apt install screenfetch 了。

sudo apt install screenfetch

安装前提示,需要下载 833 KB 文件,安装后占用 3040 KB 空间。输入 y 继续下一步。然后就是一行行提示划过。到最后如果没有出现报错,即是安装完成。

安装完成

输入 screenfetch 并回车,测试是否成功安装。

screenfetch


请读者自行尝试:

  1. 没有 sudo 时执行 apt updateapt install screenfetch 会发生什么。
  2. 本教程使用的是 Ubuntu 的官方源,可能会出现访问不畅、网速跑不满带宽等情况。于是出现了开源网站镜像站,我们也可以从镜像站获取相同的软件。著名的镜像站有清华 (opens new window)中科大 (opens new window)阿里云 (opens new window)。我校也有镜像站 (opens new window),但暂只向校内用户提供访问。请读者尝试自行搜索并更换镜像站。

# 配置 Git 个人信息和 SSH 秘钥

WSL Ubuntu 提供了 Git,因此不需要安装。

首先完成用户身份配置。请将下文的 lyh543lyh543@outlook.com 替换为自己的用户名和邮箱。虽然这步设置并不影响访问权限等,但推荐设置,这样提交中会包含你的用户名和邮箱。

git config  --global user.name lyh543
git config  --global user.email lyh543@outlook.com

配置好后,使用 git config -l 可查看是否配置成功。

git config -l


SSH 协议是 HTTPS 以外,访问 GitHub 的另一协议。

SSH 协议使用公钥、私钥认证,而不是使用密码认证。也就是说,使用 SSH 协议可以省去每次输密码的过程。

大概分为两步:

  1. 本地生成密钥对;
  2. 设置 GitHub 上的公钥;

生成密钥对使用命令 ssh-keygen

ssh-keygen

生成过程的文件夹选择、密码均可以直接按回车,默认即可。

公钥 public key 存储在 /home/msc/.ssh/id_rsa.pub,私钥 private key/home/msc/.ssh/id_rsa

然后使用 cat ~/.ssh/id_rsa.pub 查看你的公钥:

cat ~/.ssh/id_rsa.pub

接下来就是将公钥存到 GitHub:

  1. 登陆你的 github 帐户。然后 Account Settings -> 左栏点击 SSH Keys -> 点击 Add SSH key
  2. 然后你复制上面的公钥内容,粘贴进“Key”文本域内。 title 域随意。
  3. 点击 Add key
  4. 使用 ssh -T git@github.com 测试一下连接。
$ ssh -T git@github.com
The authenticity of host 'github.com (192.30.255.113)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com,192.30.255.113' (RSA) to the list of known hosts.
Hi lyh543! You've successfully authenticated, but GitHub does not provide shell access.

前三行是因为你的电脑尚未和 GitHub 建立安全连接,需要进行确认以防止中间人攻击。在安全的网络下(比如宿舍等)一般不会出错,而且这些信息都可以在对应公司的官网上查到,如GitHub 的 SSH 密钥指纹 (opens new window)

看到最后一句就是 OK 了。

接下来我们将完成:

  1. 把别人的仓库复制一份给自己,这个过程称为 fork
  2. 在自己的仓库中提交代码并推送至 GitHub
  3. 将自己仓库中的修改发给原仓库,并请求合并,这个过程称为 pull request

# fork 仓库并 clone 到本地

我们想要为别人的仓库贡献代码,但我们并没有别人仓库的写权限。于是,我们可以把别人的代码复制 fork 一份给自己,在自己的仓库修改后,发给别人审核,仓库所有者同意即可合并代码。

Git 本身是没有 fork 的,因此需要在 GitHub 官网上进行 fork。

跳转到别人的仓库,点击 fork 即可。

fork

稍等片刻以后,就可以在自己的账户下看到 fork 的仓库:

fork 的仓库

找到 Clone 的链接。我们想要使用 SSH 协议,因此需要复制带 SSH 的链接。

然后在 Ubuntu 中输入 git clone <link>

git clone git@github.com:lyh543/2020-members.git

如果是在 Windows 路径下进行的 clone,可以从 Windows 文件资源管理器看到本地有了 2020-members 文件夹。

# 提交自己的代码、推送至 GitHub

在文件夹中加入自己的代码,然后在 Git 仓库目录下(如果在上面的路径,还需要 cd 2020-members 更改当前文件夹到 2020-members),然后依次执行

git add --all
git commit -m "修改了 XX 文件,添加了 YY 文件"
git push

其中 修改了 XX 文件,添加了 YY 文件 将会被记录到这次提交中,可使用 git log 看到。推送后,也可以在 GitHub 的仓库页面看到。

add commit push 这三条命令在 Git 初期学习中,已经足够使用(我接触 Git 的三年内都只用到这三条命令 hhhh)。

至于分支管理等,可以需要的时候、有兴趣的时候再系统性地学。推荐廖雪峰的 Git 教程 (opens new window)

# 提交 Pull Request

将本地的修改推送到自己的远端仓库后,还需要到 GitHub 官网进行 Pull RequestPull Request 这个命名其实很奇怪,个人更喜欢 GitLab 的叫法 Merge Request,表示请求别人合并你的代码。只是大家 提交 Pull Request 发 PR 叫惯了,就这么叫吧。

在 fork 的仓库的 Pull Request 选项卡下即可新建 Pull Request。

Pull Request 选项卡

在下面的界面选择对应的 head repobranch 为自己的仓库和分支,base repobranch 为目标的仓库和分支。

新建 Pull Request

然后点击 Create Pull Request,输入 title 和 comment(这是方便仓库所有者理解你为什么要发这个 PR,你更新了什么等)即可。

然后就是等仓库所有者读了你的代码以后,如果觉得可以,就会合并进他的仓库了。