（十六）Fork、上游与版本发布

1. 从自己的远程副本向原项目贡献

准备向一个自己不能直接推送的项目贡献时，先在 GitHub 选择 Fork，建立归自己所有的远程副本。然后 clone 自己的 fork，把原仓库另存为 upstream：

# 替换为自己的 fork 和原项目地址，origin 指向自己，upstream 指向原项目。
git clone https://github.com/YOUR_ACCOUNT/reading-git.git reading-contribution
cd reading-contribution
git remote add upstream https://github.com/ORIGINAL_OWNER/reading-git.git
git fetch upstream
# 在主线同步上游，然后建立贡献分支。
git switch main
git merge --ff-only upstream/main
git push origin main
git switch -c docs/run-guide

完成修改后推送到自己的 origin，在 GitHub 创建“自己的功能分支 → 原仓库 main”的 PR。fork 是托管平台上的仓库关系，clone 是在电脑上取得本地仓库，branch 是仓库里的提交引用。Fork 工作流

2. 完成一次 Fork 操作

打开 GitHub 的公开示例仓库 octocat/Hello-World，点击 Fork → Create a new fork。Owner 选择自己的账户，Repository name 填写 python-notes-fork-lab，保留只复制默认分支的选项，再点击 Create fork。公开仓库的 fork 也保持公开；前面自己建立的私有仓库和这里的公开派生仓库分别用于练习两种工作流。Fork 的可见性

从 octocat/Hello-World 的 Fork 表单创建自己的派生仓库

完成后先看仓库名下方的 forked from octocat/Hello-World。它说明 GitHub 记录了派生关系；只新建一个空仓库再推送同样的代码，不会自动得到这条关系。此时 Sync fork 显示默认分支与上游一致。

接着在本地克隆自己的 fork，补上 upstream。这个上游的默认分支叫 master，命令便使用 master；其他项目按页面显示的默认分支填写。

# origin 是自己的 fork，upstream 是准备跟进的原项目。
git clone https://github.com/YOUR_ACCOUNT/python-notes-fork-lab.git reading-contribution
cd reading-contribution
git remote add upstream https://github.com/octocat/Hello-World.git
git fetch upstream
git remote -v
# 先让本地主线跟上原项目，再把这条主线推到自己的 fork。
git switch master
git merge --ff-only upstream/master
git push origin master
# 单独建立贡献分支，避免把每次练习都堆在主线上。
git switch -c docs/reading-example

git remote -v 应显示两组地址：origin 指向自己的账户，upstream 指向 octocat。fetch upstream 下载提交并更新 upstream/master；当前文件要等 merge 整合后才变化。若页面显示落后上游，也可以在 fork 首页选择 Sync fork → Update branch，随后在本地先 fetch，再更新自己的主线。

在编辑器新建 READING.md，填写下面的内容：

<!-- 用一个独立文件练习贡献，便于在比较页核对整项变化。 -->
# Reading example

Practice one small change on a separate branch.

# 审阅新文件，提交后把功能分支推到自己的 fork。
git add -- READING.md
git diff --cached
git commit -m "Add a reading example for the Git lesson"
git push -u origin docs/reading-example
# 列出相比上游新增的提交，并查看整个贡献的文件范围。
git log --oneline upstream/master..HEAD
git diff --stat upstream/master...HEAD

回到自己的 fork，切到 docs/reading-example。页面会显示该分支比上游多一个提交。打开 Contribute → Open pull request，进入跨仓库比较页。

比较页左边是接收修改的 base repository：octocat/Hello-World，base：master；右边是提供修改的 head repository：自己的 fork，compare：docs/reading-example。先检查下面的差异确实只有 READING.md，再编写贡献说明。图中停在填写 PR 的页面；课堂练习到这里即可，参加实际项目时再按该项目的贡献说明提交。

一条修改的去向可以沿着这条线核对：本地功能分支 → 自己 fork 的同名分支 → 比较页选定的上游分支。git push origin 只更新自己的 fork；原项目维护者接受并合入 PR 后，上游才会包含这项修改。

3. 用 tag 标记一次可运行版本

# 在已经检查过的提交上建立附注标签，标签名不随之后的分支提交前进。
git tag -a v0.1.0 -m "阅读统计第一个可运行版本"
git show v0.1.0
git push origin v0.1.0

branch 会随新提交前进，tag 用名字保留选定版本的位置。在 GitHub 的 Releases 中可以从 tag 创建发布说明，交代行为变化、安装入口与附件。Release 是托管平台围绕 tag 组织的发布记录；Python wheel 的构建继续使用第六章的 python -m build，给 Git 打标签不会自动生成或上传安装包。