本文提到的我的仓库仅对我教学班上的学生开放。如有不便，敬请原谅！

Part 1、使用Git

我推荐的git服务平台是国产的gitee。我在服务平台上创建了自己的（远端）仓库(repository，简称repo)，然后在本地通过git客户端，上传(push)或者下载(pull)仓库更新。 如果你需要托管自己的代码，那么推荐在gitee.com中创建自己的账号。

一、 安装Git客户端

在Ubuntu下，试试这条命令：

git --version

如果提示git未安装，那么请发出如下命令安装git:

sudo apt install git -y

二、 配置SSH

（一）准备工作

  1. 确认登录账户

    请首先确认登录账户是什么。假设是 abc。以下的操作都是在为abc这个账户配置SSH。

    • 如果登录账户换成了def，那么为abc的配置不会起作用，需要重新为def配置。
    • 建议不使用root账户。

  2. 准备密钥和配置文件

    假设分发给大家的密钥和配置文件放到了压缩包paf.zip里；这个压缩包里包含了三个文件：config（配置文件）、paf（私钥文件）和paf.pub（公钥文件）。

    • WSL和虚拟机

      将压缩包解压。假设解压到D:盘根目录中。检查是否解压出D:\ssh-key这个目录，以及那三个文件是否在这个目录下。

      如果没有，那么就创建一个，然后将三个文件剪切到这个目录下。

    • macOS

      将压缩包解压。假设解压到桌面上。然后在终端中发出如下命令：

        alias ll='ls -la'

（二）复制秘钥和配置文件

假设你的登录账户名是 abc。

  1. 确认是否存在~/.ssh目录。

    在终端中发出如下命令：

     ll ~/.ssh

    如果没有，那么发出如下命令：

     mkdir -p ~/.ssh

  2. 确认是否已经配置过SSH

    发出如下命令：

     cd ~/.ssh
 ll config

    如果系统显示说没有此文件，那么说明你以前没有配置过SSH。

    如果有，那么后续就不能直接用我给的config覆盖你自己的。此时，发出如下命令：

     mv config config.bak

  3. 复制文件

    • WSL

      从Windows主机的文件系统复制过去：

        cd /mnt/d/ssh-key
  cp config paf paf.pub ~/.ssh
  cd ~/.ssh

    • 虚拟机

      从Windows主机远程复制过去：

      1）首先查看虚拟机的ip地址，以便用于远程复制：

        ifconfig

      显示的内容类似于：

        eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1400
  inet 172.19.79.176  netmask ...
  ...

      记住显示信息中的ip地址：172.19.79.176。

      2）在Windows中，打开Powershell，在其中输入远程复制命令：

        d:
  cd ssh-key
  scp config paf paf.pub abc@172.19.79.176:~/.ssh

      系统可能提示你输入虚拟机系统的密码。

      实际操作中，用你的账户名和真实IP替换命令中的对应部分。

    • macOS

      将加压到桌面上的三个文件复制到/Users/abc/.ssh目录下。此后桌面上的文件可以删除了。

  4. 修改文件权限

    一条条发出如下指令：

     cd ~/.ssh
 touch known_hosts
 chmod 644 config paf.pub known_hosts
 chmod 600 paf

    如果你想保留原来的设置，那么请这么做：

     cat config.bak >> config

    追加完后，用vim打开config编辑一下，使格式符合要求。

  5. 然后测试一下SSH是否配置好。

     ssh -T paf

    其中，命令中的主机名paf就是我们此前在config文件中配置好的。

    如果是第一次连接，会显示如下信息：

     The authenticity of host 'gitee.com (180.76.198.77)' can't be established.
 ED25519 key fingerprint is ...
 This key is not known by any other names.
 Are you sure you want to continue connecting (yes/no/[fingerprint])?

    此时请输入yes。

    注意！paf是示例的名字，真正的名字是老师分发给你的私钥文件的名字。

    如果你看到出现了类似信息：

     Hi Anonymous (DeployKey)! You've successfully authenticated, but ...
 Note: Perhaps the current use is DeployKey.
 Note: DeployKey only supports pull/fetch operations

    那就表明配置成功了。

    注：后面两条信息说明分发的密钥时Deploy Key，没有push权限。

    配置过程中如果出现问题，请阅读文档08。

三、 拉取仓库

（一） 首次克隆远端仓库到本地

第一次操作时，本地仓库不存在，因此需要将远端仓库克隆到本地。

  • WSL

    假设你要将仓库克隆到Windows的目录D:盘根目录下（对应WSL中的目录是/mnt/d）。在终端中发出如下命令：

      cd /mnt/d
  git clone git@paf:baizj/paf.git

  • 虚拟机和macOS

    假设你要将仓库克隆到~/myprog目录下。在终端中发出如下命令：

      mkdir -p ~/myprog
  cd ~/myprog
  git clone git@paf:baizj/paf.git

此后，你会看到文档克隆进度信息。

克隆完成后，我放在远端服务器上的内容就被克隆到你指定的目录下了。例如上例：在Windows下是D:\paf（此目录在WSL中是/mnt/d/paf），在Linux和macOS下是~/myprog/paf。

（二） 以后的拉取

克隆后，原则上就不能再次克隆，只需要随时拉取仓库就行了。

以WSL为例：

cd /mnt/d/paf
git pull

（三） 注意事项

我分发给大家的秘钥为部署秘钥，即你没有推送(push)的权限，你在本地仓库的修改将无法推送到远端仓库中。

这会导致一个问题：如果你直接在克隆的本地仓库中修改了文档，那么Git会提示你，本地仓库有更新，但你却无权推送。

基于上述理由，如果你要修改我给你的代码，那么请将代码复制到其他目录中，不要直接修改原始代码。否则，你将在下次拉取时，Git会提示，你的修改与远端仓库发生冲突而无法拉取。

如果发生了冲突，解决问题最简单的方法是：将目录重命名，然后重新克隆一次。

如未经同意，请勿随意复制、扩散仓库的内容。谢谢！

四、 在Code中使用Git

Code中集成了git工具，请自行查阅如何配置和使用。

Part 2、背景知识：版本控制

本节内容摘自百度百科

一、版本控制的概念

版本控制最主要的功能就是追踪文件的变更。它将什么时候、什么人更改了文件的什么内容等信息忠实地了记录下来。每一次文件的改变，文件的版本号都将增加。除了记录版本变更外，版本控制的另一个重要功能是并行开发。软件开发往往是多人协同作业，版本控制可以有效地解决版本的同步以及不同开发者之间的开发通信问题，提高协同开发的效率。并行开发中最常见的不同版本软件的错误(Bug)修正问题也可以通过版本控制中分支与合并的方法有效地解决。

二、版本控制的内容

版本控制包括：检入检出控制、分支和合并、历史记录。

  1. 检入检出控制

    软件开发人员对源文件的修改不能在软件配置管理库中进行，对源文件的修改依赖于基本的文件系统并在各自的工作空间下进行。为了方便软件开发，需要不同的软件开发人员组织各自的工作空间。一般说来，不同的工作空间由不同的目录表示，而对工作空间的访问，由文件系统提供的文件访问权限加以控制。

    访问控制需要管理各个人员存取或修改一个特定软件配置对象的权限。开发人员能够从库中取出对应项目的配置项进行修改，并检入到软件配置库中，对版本进行“升级”；配置管理人员可以确定多余配置项并删除。

    同步控制的实质是版本的检入检出控制。检入就是把软件配置项从用户的工作环境存入到软件配置库的过程，检出就是把软件配置项从软件配置库中取出的过程。检人是检出的逆过程。同步控制可用来确保由不同的人并发执行的修改不会产生混乱。

  2. 分支和合并

    版本分支(以一个已有分支的特定版本为起点，但是独立发展的版本序列)的人工方法就是从主版本——称为主干上拷贝一份，并做上标记。在实行了版本控制后，版本的分支也是一份拷贝，这时的拷贝过程和标记动作由版本控制系统完成。版本合并(来自不同分支的两个版本合并为其中一个分支的新版本)有两种途径，一是将版本A的内容附加到版本B中；另一种是合并版本A和版本B的内容，形成新的版本C。

  3. 历史记录

    版本的历史记录有助于对软件配置项进行审核，有助于追踪问题的来源。历史记录包括版本号、版本修改时间、版本修改者、版本修改描述等最基本的内容，还可以有其他一些辅助性内容，比如版本的文件大小和读写属性。

Part 3、背景知识：代码托管平台

为了更高效更安全地进行版本控制，我们一般使用成熟的代码托管平台对代码进行管理。

最流行的代码托管平台是GitHub。你可能感到惊讶的是，这个平台的核心系统–Git–的作者就是Linux内核的作者Linus Torvalds。

Git是一种开源的分布式版本控制系统。它被广泛地使用在其他不同的托管平台中。其中比较著名的是免费的GitLab。

这里我推荐使用国内的托管平台Gitee。

但在使用之前，我们先来浅学一些基础知识。

Part 4、背景知识：关于SSH安全连接

一、 SSH秘钥

使用分布式版本控制系统，就意味着本地系统要与远端服务器进行通信。目前，两端之间的通信都需要使用SSH建立起一条安全可信的连接。这种可信连接需要使用一对用某种算法（常用的是RSA算法，以下均以此算法为例）生成的秘钥，一个是私钥，不公开；一个是公钥，可以公开。这对秘钥会部署在本地和远端服务器中。换句话说，只要是本地或远端服务器之一没有部署配对的秘钥，那么本地将无法与远端建立连接。

在本地，秘钥信息一般存放在文本文件中：私钥文件默认名为id_rsa，公钥文件默认名为id_rsa.pub。这两个文件存放在系统的~/.ssh目录中。

秘钥文件绝对不能手工修改！！！另外，它们在本地的读写权限也应该限制在最小范围内。

二、 连接多台服务器

当本地发起SSH连接请求时，如果没有显式配置，那么本地系统会使用默认文件名的秘钥。这样一来，本地就只能连接一个固定远端，除非你要连接的多个远端全都部署了一样的秘钥，但这显然不合理也不太可能。

如果本地需要连接多个远端，那么每个连接都需要一对秘钥。显然，这些秘钥对在文件名上就要做出区分。这是，需要为SSH编写一个配置文件config（也放在~/.ssh目录中），用来描述当用户选择哪个远端时，启用哪对秘钥。以下是我分享的config文件的样本。

Host gitee
    HostName gitee.com
    IdentityFile ~/.ssh/pk1

Host github
    HostName github.com
    IdentityFile ~/.ssh/pk2

样本中前三行：

  • 第一行：声明远端主机名是gitee。以后命令中就使用这个名字。
  • 第二行：说明远端主机域名是gitee.com。
  • 第三行：指定使用的秘钥文件是pk1，及其同名但带.pub后缀的文件。

样本中后面几行的含义与前三行一样，不过配置了连接到其他服务器的信息。

默认的秘钥文件可以继续存在。如果指定的主机名不在config中，那么系统将尝试启用默认的秘钥；如果它们不存在，那么连接将会失败。

三、 fingerprint和known_hosts文件

在第一次连接远端主机的时候，系统会将该主机的fingerprint添加到一个与秘钥文件在同一个目录里、名叫known_hosts的文本文件中。如果该文件不存在，则创建一个。显然，这需要发起连接命令的账户有在~/.ssh目录里的写权限。