第三讲：开源世界生存基础 ¶

What & Why¶

开源（Open Source）是指将源代码公开到互联网上，任何人都可以在开源许可证（License）的约束下查看、修改甚至重新发布代码。

为了便于管理和协作，通常会使用版本控制系统（Version Control Systems，VCS）来管理代码，其中最流行的工具是 Git。与此同时，既然代码是公开的，就需要一个代码托管平台来存储和管理代码，最为知名的平台是 GitHub。考虑到国内的网络环境，本节课将以浙江大学超算队提供的 ZJU Git 为示范平台。

很好，开源看上去很酷，但我为什么要学它呢？

• 最现实的原因：你躲不掉的。朱 🎳 学长在上节课提到过，早在大一下学期《数据结构基础》课程开始，就有老师要求使用 Git 等工具来管理你的代码。
• 因为确实好用，掌握 Git 后你会觉得相见恨晚，它和其他版本控制方法相比简直是降维打击。
• 因为开源世界超好玩的～如果某个项目你觉得有问题，你可以直接向开发者提出修改建议；如果你觉得某个项目很棒，你可以直接参与进去。这种自由和开放的氛围是无法比拟的，你甚至可以在 GitHub 上吃瓜。

很棒！那我们开始吧！

Git：最优秀的版本控制工具 ¶

你是否遇到过这样的情景？

更进一步，当你高高兴兴地写完了报告，刚把各种备份文件删除，回收站清空，然后导师突发奇想，告诉你他觉得以前的版本更好，叫你回退以前的版本，这时你的心情是什么样的？

Git 就是为了解决这种问题而生的。通过高效的数据结构，它可以帮你记录文件的自创建以来的每一个版本，甚至允许你在不同版本之间自由切换。

远古时期的 Linux 代码

你甚至可以找到 Linux 内核在 GitHub 上的第一次提交！（实际上，因为年代过于久远，这个提交在 GitHub 提交列表上是隐藏的，感兴趣的同学可以自己试试看看能不能把它找出来😉）

历史 ¶

Linus Torvalds 在开发 Linux 内核时，原本使用的版本管理系统叫 BitKeeper。但是由于当时 BitKeeper 的免费版本加入了限制，他决定开发一款自由、免费的版本管理系统，顺带解决一下历代 VCS 的缺陷，于是 Git 诞生了。

• 2005 年 4 月 8 日，Git 实现自托管。

  

• 10 天后，Linux 内核的开发就转向了 Git。（Fig. 梦开始的地方）

Git 安装及配置 ¶

• Linux / macOS：大部分 Linux 发行版和 macOS 都自带 Git。如果没有，可以通过包管理器直接安装：apt install git / brew install git / ...
• Windows：访问 git-scm.com/downloads/win，下载 64 位版本（64-bit Git for Windows Setup），以默认选项安装即可。

打开终端，输入 git --version，如果正常输出版本号，则说明安装成功。

接下来，我们需要配置 Git 的一些基本信息，例如用户名和邮箱。

git config --global user.name "<你的用户名>"
git config --global user.email "<你的邮箱>"

Git 的数据模型 ¶

从 Git 的交互指令出发很容易让人听得一头雾水，所以我们从底层出发，自下而上地学习 Git。

Git 启动时，会在当前目录下创建一个名为 .git 的隐藏文件夹，这个文件夹就是 Git 的版本库（Repository）。

版本库中，保存着所有文件的历史（History），以及一个叫暂存区（Stage）的东西。

快照 ¶

为了记录文件的历史，Git 会给每一个版本创建一个快照（Snapshot，又称 Commit、提交），不同的快照之间通过一种叫做有向无环图（Directed Acyclic Graph，DAG）的数据结构（大家会在大一下《数据结构基础》的课程中学到）联系起来。

在上面的例子中，历史在 C 快照处产生了两个分支（Branch），并在 I 快照处合并（Merge）。这种分支和合并的操作是 Git 的强大之处，我们会在后面详细讲解。

在 Git 中，每一个快照都由一个十六进制数唯一标识，它相当于快照的 ID。通常只需要前几位就可以唯一确定一个快照，例如之前图片中的 1da177e。但很显然，这种十六进制数不适合人类记忆。因此 Git 允许给快照创建引用（Reference），它是一个指向快照的指针，例如人们通常使用 master、main 等名字来表示最新的快照。

Git 有一个特殊的指针叫做 HEAD，它指向当前所在的分支或者快照，也就是当前正在工作的版本。

通过这种方式，你可以很方便地在不同快照之间切换。

暂存区 ¶

你可能会想象，每次提交都会对当前工作目录（Working Directory）打一个快照，然后保存到版本库中，但实际上并非如此。

设想这样一个场景：你同时修改了两个文件，但只想提交其中一个，这时候就需要一个中间状态来保存你的修改。这个中间状态就是所谓的暂存区。

基础用法 ¶

Let's get our hands dirty!

初始化版本库 ¶

要使用 Git，首先需要创建一个 Git 版本库，这个过程是通过 git init 命令完成的。

mkdir my-repo
cd my-repo
git init

年轻人的第一个 Commit！¶

现在我们已经有了一个空的 Git 版本库，接下来我们尝试往里面添加一些文件。

#include <stdio.h>

int main() {
    printf("Hello World");
    return 0;
}

现在的工作目录中有了一个 hello.c 文件，我们可以使用 git status 命令查看当前版本库的状态。

git status

git add <FILE>

git commit -m "<MESSAGE>"

git log

git commit -m "Add hello.c"

🎉 恭喜你完成了自己的第一个 Commit！下面让我们多添加一些文件。

hello.c：一个简单的 Hello World 程序（真的很简单！）。

除此之外，还有一些其他常用的命令：

• git rm：同时删除本地和版本库中的文件。（等价于rm + git add）
• git rm --cached：将一个已暂存的文件取消暂存。
• git mv：重命名文件。（等价于mv +git rm + git add）
• git log 的一些参数：
  • --oneline：在一行中显示。
  • --graph：显示分支结构。
  • --stat：显示文件的删改信息。
  • --all：显示所有分支的历史。（默认只显示当前分支）
  • 参数可以组合使用，例如 git log --all --graph --oneline。
• git diff <A> <B>：比较两个快照之间的差异，<A> 和 <B> 可以是 Commit ID、ID 简写、引用、HEAD、文件名等。
• git show <COMMIT>：查看某次提交的详细信息，<COMMIT> 同上。
• git revert <COMMIT>：创建一个新的提交，撤销某次提交的修改。

分支 ¶

分支（Branch）是一个非常重要的概念。它允许你在不影响主线的情况下进行开发，然后再将你的工作合并到主线上。

• 创建分支
  • git branch <BRANCH>：基于当前的 HEAD。
  • git branch <BRANCH> <COMMIT>：基于某个快照。
• 查看分支
  • git branch：查看本地分支。
  • git show-branch（更加详细）
• 切换分支（检出）
  • git checkout <BRANCH>：切换到某个分支。
  • git checkout -b <BRANCH>：创建并切换到某个分支。
• 删除分支
  • git branch -d <BRANCH>：删除本地分支。

void print_hello() {
    printf("Hello from dev branch!");
}

Detached HEAD 问题 ¶

所谓 Detached HEAD，指的是 HEAD 指向的不是一个分支，而是一个具体的快照。

如果在这种情况下进行修改并提交，新的提交不属于任何分支，它只能通过 Commit ID 来访问，相当于丢失了。

合并 ¶

git merge <BRANCH1> [<BRANCH2> ...] -m "<MESSAGE>"

将一个或多个分支合并到当前分支。合并本身也是一次提交，-m 参数后面是提交信息。

• Already up-to-date：当前分支只比要合并的分支新，不需要合并。
• Fast-forward：要合并的分支只比当前分支新，只需要挪动指针即可，不需要新的提交。
• 如果都有新的提交，Git 会尝试自动合并，如果有冲突（Merge Conflict），需要手动解决（解决冲突后需要再次add + commit）。

void print_hello() {
    printf("Hello from main branch!");
}

实际上，Merge 还有很多其他的策略。

• Squash Merge：将多个 Commit 合并为一个。
• Rebase：变基，将当前分支的历史平移到目标分支，可以使得历史更加线性。（会篡改历史，不推荐多人协作时使用）
• GitHub Rebase，GitHub 提供的一种 Rebase 方式，将目标分支在当前分支上重放。

篡改历史 ¶

成为历史的罪人

Git 的历史一般情况下是不可篡改的，但实际上还是有一些方法可以对历史进行修改：

• git commit --amend：修改最新的提交 message。
• git reset <COMMIT>：回退到某个快照。（你可能更应该使用更加温和的 git revert）
• git rebase -i <COMMIT>：交互式 Rebase，功能非常强大，不到万不得已不要使用！

在 VSCode 中使用 Git ¶

Visual Studio Code 默认集成了 Git，点击左侧源代码管理（Source Control）按钮即可打开图形化的 Git 界面。

.gitignore 文件 ¶

在实际开发中，有一些文件是不需要纳入版本库的，例如编译生成的文件、日志文件、缓存文件等。这时候就需要在根目录下创建一个 .gitignore 文件。

.gitignore 文件是一个文本文件，每一行是一个匹配规则，例如：

# Logs
logs
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*
lerna-debug.log*

node_modules
.DS_Store
dist
dist-ssr
coverage
*.local
cache

/cypress/videos/
/cypress/screenshots/

# Editor directories and files
.vscode/*
!.vscode/extensions.json
.idea
*.suo
*.ntvs*
*.njsproj
*.sln
*.sw?

*.tsbuildinfo
.vercel

语法：

• # 开头的行是注释。
• * 代表通配符，匹配多个字符。例如 *.c 匹配所有 .c 结尾的文件。
• ** 通配多个目录。例如 a/**/b 匹配 a/b、a/x/b、a/x/y/b 等。
• / 开头只匹配根目录，否则匹配任意目录。
• ! 开头是取消忽略。

官方文档：git-scm.com/docs/gitignore，GitHub 也提供了一个模板。

GitHub / ZJU Git 基础 ¶

设想多人协作的场景，每个人都在本地有自己的版本库，那如何实现同步呢？

答案是每个人都使用一个“权威”的远程版本库（Remote Repository）。

远程版本库 ¶

远程版本库也是一个普通的 Git 版本库，只不过由于不需要工作目录和暂存区，所以一般使用裸版本库。

• git clone <SRC> <DEST>：克隆一个远程版本库到本地，会自动添加一个名为 origin 的远程版本库，可以通过 git remote 管理。
• git push：将本地的提交推送到远程版本库。
• git pull：将远程版本库的提交拉取到本地，等价于git fetch + git merge。

远程版本库可以简单地理解成是本地的一个 origin/main 分支。

ZJU Git¶

作为一个全球顶尖的三本，怎么能没有一个自己的 Git 服务器呢？

网址：git.zju.edu.cn，只能通过校网或 WebVPN 访问。

注册账号 ¶

使用统一身份认证登录。

设想一下，ZJU Git 如何确定你的身份呢？

• 本地 Git 的用户名和邮箱要和 ZJU Git 匹配：你可能需要重新设置本地的用户名和邮箱。
• 建立本地与远程的身份验证机制：使用 SSH 密钥。

ssh-keygen -t ed25519 -C "<你的邮箱>"

创建仓库 ¶

git remote add origin <你的仓库地址>
git branch -M main
git push -uf origin main

• git remote add origin <地址>：添加一个名为 origin 的远程版本库。
• git branch -M main：将当前分支重命名为 main。
  • -M：强制重命名，如果分支已经存在，会覆盖。
• git push -uf origin main：将本地的 main 分支推送到远程 origin 版本库中。
  • -u：设置上游分支，意味着之后可以直接使用 git push 和 git pull。
  • -f：强制推送，会覆盖远程版本库的内容（其他情况下不要使用）。

多人协作 ¶

• Fork：你可以复制一个仓库到你自己的账号下，这个操作叫做 Fork，你可以在这个仓库上自由地修改、提交。
• Pull Request（PR）：当你修改完一个仓库后，你可以向原仓库提交一个 Pull Request，请求原仓库的所有者合并你的修改。

GitHub 简介 ¶

所谓 GitHub，就是 Git 的 Hub（我在说什么）。

GitHub 是全球最大的代码托管平台，拥有数亿的开发者（截至 2023 年 1 月）和数以亿计的代码仓库。

开源项目基础 ¶

许可证 ¶

公开源代码不代表你可以拿它做任何想做的事，这个时候就需要许可证（License）。

常用软件开源许可证：

• MIT：非常宽松的许可证，几乎没有限制。
• GPL：GNU General Public License，有传染性，要求派生作品也必须开源。
• Unlicense：放弃所有权利，代表进入公共领域。

参考 choosealicense.com。

在根目录下创建名为 LICENSE 的文件，然后在其中附上许可证的内容。如果不同部分采用了不同的许可证，那么需要在每个文件的开头注明。

GitHub 能够自动识别常见的许可证类型，并在仓库的主页上显示。

除此之外，还有非软件类许可证，最常使用的是 CC（Creative Commons，知识共享）系列许可证，目前最广泛使用的版本是 4.0，它包含如下几种：

• CC 0：放弃所有权，进入公共领域。
• CC BY：BY 表示必须署名。
• CC BY-SA：SA 表示必须使用相同许可证（Share-Alike）。
• CC BY-NC：NC 表示禁止商业用途（Non-Commercial）。
• CC BY-NC-SA：三个要求都有。
• CC BY-ND：ND 表示禁止分发、修改（No-Derivatives，禁止演绎）。
• CC BY-NC-ND：三个要求都有。

往往通过一段文字即可表示许可：

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

结语 ¶

通过今天的学习，想必你已经对开源有了更深的了解，欢迎你加入开源的大家庭！

一些学习资源：

• Pro Git
• Git Flight Rules
• Learning Git Branching
• Githug

下一次课，李英琦学长将为大家带来 Markdown 和 LaTeX 等排版相关的内容（实际上这个讲义就是用 Markdown 写的），敬请期待～