编辑“︁Git Forking工作流”︁

== Git Forking工作流 ==

'''Git Forking工作流'''是一种分布式协作模型，主要应用于开源项目开发。该工作流的核心特点是开发者不直接向主仓库推送代码，而是通过个人远程副本（Fork）提交变更，再通过Pull Request（PR）发起代码评审与合并请求。

=== 核心概念 ===
* '''Fork'''：在Git托管平台（如GitHub/GitLab）上创建原仓库的独立副本，拥有完全控制权
* '''Clone'''：将远程Fork副本下载到本地开发环境
* '''Remote'''：本地仓库需同时配置Fork仓库（origin）和原仓库（upstream）的远程地址
* '''Pull Request'''：向原仓库维护者发起代码合并的正式请求

=== 工作流程详解 ===
<mermaid>
graph TD
    A[原仓库] -->|Fork| B(开发者个人仓库)
    B -->|Clone| C[本地仓库]
    C --> D[创建特性分支]
    D --> E[提交变更]
    E --> F[推送到个人仓库]
    F -->|Pull Request| A
    A -->|代码评审| G[合并到主分支]
</mermaid>

==== 1. 创建Fork ====
在托管平台点击"Fork"按钮，生成与原仓库独立的副本：
[[File:GitHub Fork Button.png|thumb|right|GitHub Fork按钮示例]]

==== 2. 克隆仓库 ====
<syntaxhighlight lang="bash">
# 克隆个人Fork副本（非原仓库）
git clone https://github.com/your-username/project.git
cd project

# 添加上游仓库远程地址
git remote add upstream https://github.com/original-owner/project.git
</syntaxhighlight>

验证远程配置：
<syntaxhighlight lang="bash">
git remote -v
# 输出示例：
# origin    https://github.com/your-username/project.git (fetch)
# origin    https://github.com/your-username/project.git (push)
# upstream  https://github.com/original-owner/project.git (fetch)
# upstream  https://github.com/original-owner/project.git (push)
</syntaxhighlight>

==== 3. 同步更新 ====
保持本地仓库与原仓库同步：
<syntaxhighlight lang="bash">
git fetch upstream
git checkout main
git merge upstream/main
</syntaxhighlight>

==== 4. 开发流程 ====
<syntaxhighlight lang="bash">
# 创建特性分支（禁止直接修改main分支）
git checkout -b feature-x

# 进行代码修改后...
git add .
git commit -m "实现X功能"

# 推送到个人远程仓库
git push origin feature-x
</syntaxhighlight>

==== 5. 发起Pull Request ====
在GitHub/GitLab界面：
1. 切换到你的feature-x分支
2. 点击"New Pull Request"
3. 选择base仓库（原仓库/main）←→ head仓库（你的仓库/feature-x）
4. 填写PR描述，关联Issue（如有）

=== 冲突解决 ===
当原仓库更新导致PR出现冲突时：
<syntaxhighlight lang="bash">
git fetch upstream
git checkout feature-x
git rebase upstream/main
# 手动解决冲突后...
git add .
git rebase --continue
git push -f origin feature-x
</syntaxhighlight>

=== 数学表示 ===
Fork工作流可形式化表示为：
<math>
\begin{cases}
Fork(R) \rightarrow R' \\
Commit(R', \Delta) \rightarrow R'_{\Delta} \\
PR(R'_{\Delta}, R) \rightarrow Merge(R \cup \Delta)
\end{cases}
</math>
其中：
* <math>R</math> = 原仓库
* <math>R'</math> = Fork副本
* <math>\Delta</math> = 代码变更集

=== 实际案例 ===
'''Linux内核开发'''采用改进的Forking工作流：
1. Linus Torvalds维护主仓库（https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git）
2. 开发者Fork后通过邮件列表发送补丁
3. 子系统维护者审核后通过pull request合并

=== 优势与局限 ===
{| class="wikitable"
|+ 工作流对比
! 优势 !! 局限
|-
| 降低主仓库维护压力 || 需要主动同步上游变更
|-
| 支持大规模协作 || 合并周期可能较长
|-
| 天然隔离开发环境 || 新手可能混淆远程配置
|}

=== 最佳实践 ===
* 保持特性分支短生命周期
* 每次PR聚焦单一功能
* 使用<code>git rebase</code>替代<code>git merge</code>保持历史线性
* PR描述遵循项目模板
* 通过<code>.gitignore</code>排除构建产物

=== 扩展阅读 ===
* [[Git分布式工作流]]
* [[Pull Request评审技巧]]
* [[开源项目协作规范]]

[[Category:集成部署]]
[[Category:Git]]
[[Category:Git工作流]]