【Git】Git05-04：Github分支管理与协作流程

正经教主2025-11-23 20:13

📚前言

官方文档： GitHub 入门文档 - GitHub 文档

关于国内访问github访问的速度问题，请参考：加速github访问速度方法：Watt Toolkit

第五章·第四部分： Github分支管理与协作流程

目录

[一、🔎 核心概念与业务逻辑](#一、🔎 核心概念与业务逻辑)

二、自己仓库的远程分支创建

[2.1 方法 1：基于本地分支推送创建（推荐，99% 场景用）](#2.1 方法 1：基于本地分支推送创建（推荐，99% 场景用）)

[2.2 方法 2：GitHub 网页端直接创建（少用，适合快速建分支）](#2.2 方法 2：GitHub 网页端直接创建（少用，适合快速建分支）)

[2.3 本地分支修改推送github](#2.3 本地分支修改推送github)

[三、自己仓库的远程分支合并到 GitHub 主仓库](#三、自己仓库的远程分支合并到 GitHub 主仓库)

[3.1 方法 1：GitHub 网页端 PR 合并法（推荐，99% 场景用）](#3.1 方法 1：GitHub 网页端 PR 合并法（推荐，99% 场景用）)

[3.2 方法 2：本地命令行合并法（快捷，适合个人项目）](#3.2 方法 2：本地命令行合并法（快捷，适合个人项目）)

[3.3 两种方法对比（选对场景更高效）](#3.3 两种方法对比（选对场景更高效）)

[四、自己的仓库创建 Fork（很少用）](#四、自己的仓库创建 Fork（很少用）)

[4.1方法 1：GitHub 网页端操作（最常用，无需命令）](#4.1方法 1：GitHub 网页端操作（最常用，无需命令）)

[4.2 方法 2：命令行操作（适合习惯终端的用户）](#4.2 方法 2：命令行操作（适合习惯终端的用户）)

[4.3 自己仓库的Fork同步原仓库的更新](#4.3 自己仓库的Fork同步原仓库的更新)

[五、自己仓库的 Fork更新到原仓库](#五、自己仓库的 Fork更新到原仓库)

前提准备（必须先完成）

[方法 1：PR 合并法（推荐，规范且留痕）](#方法 1：PR 合并法（推荐，规范且留痕）)

[方法 2：命令行直接推送法（快捷，适合个人场景）](#方法 2：命令行直接推送法（快捷，适合个人场景）)

两种方法对比（选对场景更高效）

[六、别人仓库的分支操作【常用】（Fork + PR 流程）](#六、别人仓库的分支操作【常用】（Fork + PR 流程）)

[6.1 流程总览](#6.1 流程总览)

[6.2 具体操作步骤（含命令 + 示例）](#6.2 具体操作步骤（含命令 + 示例）)

附录

远程分支的常见操作（关联之前的教程）

[自己仓库的「远程分支」vs「自己仓库的 Fork」（核心区别）](#自己仓库的「远程分支」vs「自己仓库的 Fork」（核心区别）)

一、🔎 核心概念与业务逻辑

1.1 分支

分支的核心作用：为不同开发任务（新功能、bug 修复、测试）创建「独立的代码分支」，开发完成后再合并到主分支，保证主分支的稳定性。

1.1.1 分支的本质与类型

在Git中，分支实际上是一个指向某个提交（Commit）的可变指针 。Git的默认主分支名可能是 master 或 main。

  • 主分支（Master/Main） ：用于保存稳定、可发布 的代码。在GitHub Flow中，main 分支的代码应随时可部署。

  • 开发分支（Develop） ：在Git Flow等策略中，作为功能集成的分支，稳定性介于主分支和功能分支之间。

  • 功能分支（Feature Branch） ：用于开发单个新功能或修复，通常基于主分支或开发分支创建，完成后通过Pull Request (PR)合并回去。

  • 发布分支（Release Branch） ：用于准备新版本发布，基于Develop分支创建，允许进行最后的微调和修复，完成后需合并到Master和Develop分支。

  • 热修复分支（Hotfix Branch） ：用于快速修复生产环境中的紧急问题，基于Master分支创建，修复完成后需合并回Master和Develop分支。

1.1.2🌿主流分支策略

不同项目规模对应不同分支策略

1). GitHub Flow（轻量型，适合个人 / 小团队 / 持续部署项目）

核心逻辑：只有 1 个稳定主分支（main），所有开发都在临时功能分支完成，流程极简：

适用场景：个人项目、快速迭代的小团队、持续部署（合并到 main 就自动部署）的项目。

2). Git Flow（规范型，适合中大型项目 / 多版本发布）

核心逻辑：有 2 个长期分支（main+develop），多个临时分支（feature/release/hotfix），流程更严谨：

适用场景：需要多版本管理（比如 v1.0、v2.0）、多人协作分工明确、有严格测试流程的中大型项目。

1.2 远程分支管理

1.2.1 概念解析
  • 远程分支（remote branch）：存储在 GitHub 服务器上的分支（比如origin/main，origin/feature/login），与本地分支对应
  • Fork（复刻）：当你没有别人仓库的「写权限」时，复制别人的仓库到自己的 GitHub 账号下（相当于「私人副本」），后续在自己的副本上开发
  • 上游仓库（upstream）： 被你 Fork 的「原仓库」（比如你 Fork 了xxx/xxx-project，这个原仓库就是你的 upstream），用于同步原仓库的最新代码
  • Pull Request（PR）：「合并请求」：当你在分支（自己仓库的分支 / Fork 仓库的分支）完成开发后，向目标分支（比如 main）发起请求，让仓库管理者审核你的代码并合并
  • 冲突（Conflict）：两个分支修改了「同一文件的同一部分」（比如 A 分支改了index.js第 10 行，B 分支也改了第 10 行），Git 无法自动判断保留哪部分，需要手动解决
1.2.1 示意图

以核「小王」操作「小李」开源项目为例，解释远程分支示意图：

二、自己仓库的远程分支创建

自己仓库的远程分支，本质是「同一个仓库内的并行代码线」，创建方式主要依赖「本地分支推送」（最常用）或「GitHub 网页端直接创建」，所有分支都归属同一个仓库。

2.1 方法 1：基于本地分支推送创建（推荐，99% 场景用）

总思路：这是最常用的方式 ------ 先在本地创建分支开发，再推送到 GitHub，自动生成对应的远程分支（无需提前在网页端操作）。

操作步骤（含命令 + 原理 + 示例）：

1. 克隆仓库到本地
复制代码 
git clone <仓库地址>

例子：

  • HTTPS:

    • git clone https://github.com/username/repo.git

  • SSH:

    • git clone git@github.com:username/repo.git

这会创建一个本地文件夹 repo/，并自动设置 origin 指向远程仓库。

2. 查看远程仓库信息（可选）

已克隆到本地的仓库，想查看其远程仓库时用。

复制代码 
git remote -v

输出示例：

origin git@github.com:username/repo.git (fetch) origin git@github.com:username/repo.git (push)

3. 同步更新（可选）

已克隆到本地的仓库，在创建分支修改之前，避免远程仓库发生了修改而不一致，可以先同步更新一下

复制代码 
#同步前查看确认远程仓库（可选）
git remote
#长输出格式，用下面目录
git remote -v

#方法 A：直接拉取（pull）
git pull origin main 


#方法 B：分步操作（更安全）
git fetch origin 
git merge origin/main 
#或使用 rebase（保持提交历史整洁）：
git fetch origin 
git rebase origin/main 

#方法 C：强制本地与远程一致（危险，慎用）
git fetch origin 
git reset --hard origin/main ​
4. 基于最新主分支创建功能分支

创建本地功能分支：

bash

复制代码 
# 创建分支前，确认当前分支（可选）
#查看本地所有分支（当前分支前会有「*」标记）
git branch
# 或者查看本地 + 远程所有分支（包含 GitHub 上的分支）
git branch -a
#如果需要，切换目标分支，如本地main分支
git switch main


# 方式一：创建并切换到本地功能分支（命名规范：feature/功能名）
git switch -c feature/comment  # 示例：创建「评论功能」分支
# 可用的老版本命令：git checkout
git checkout -b feature/comment  # 新建「支付功能」分支并切换过去

#方式二：先创建分支，在切换
# 创建分支：git branch 分支名
git branch feature/comment  
#切换分支 switch
git switch feature/comment  
#可用的老版本命令：git checkout
git checkout feature/comment

实际执行界面参考：

  • 💡注意：
    • 创建分支时，会基于「当前所在分支」的代码复制一份（所以创建功能分支前，需先切换到目标分支）。
    • 切换分支后，本地文件会自动同步为该分支的代码（如切换到 feature/login 后，修改的代码仅影响该分支）。
5. 推送本地分支到 GitHub，自动创建远程分支

分支内容修改后，提交修改

复制代码 
# 查看修改
git status

# 添加到暂存区
git add .

# 提交到本地分支
git commit -m "分支备注说明"

然后，将变更提交后的分支，推送到Github

bash

复制代码 
# 语法：git push -u 远程仓库别名 本地分支名:远程分支名
git push -u origin feature/comment:feature/comment

# 简化写法（（默认远程分支名和本地一致））
git push -u origin feature/comment
  • 关键参数解释 ：

    • -u：全称--set-upstream，作用是「关联本地分支和远程分支」。后续再推送这个分支时，直接用git push即可（无需重复写origin feature/comment）；
      *

      方式 命令 后续操作 适用场景
      用 -u（推荐） git push -u origin feature/comment 直接执行 git push 即可推送，无需额外参数 日常开发、长期维护的分支
      不用 -u git push origin feature/comment 每次推送需重复指定：git push origin feature/comment 临时分支、仅推送一次的场景

    • origin：你自己仓库的远程别名（GitHub 默认命名，可通过git remote -v查看）；

    • 若远程仓库中没有feature/comment分支，Git 会自动创建这个远程分支。

3. 验证远程分支是否创建成功
  • 命令行验证：git branch -r（查看所有远程分支，会显示origin/feature/comment）；
  • 网页端验证：打开你的 GitHub 仓库，点击顶部「Code」旁的分支下拉框，能看到feature/comment分支（和 main 分支并列）。

2.2 方法 2：GitHub 网页端直接创建（少用，适合快速建分支）

无需本地操作，直接在 GitHub 网页端创建远程分支（适合临时分支或无需本地开发的场景）。

1. 操作步骤（可视化）
  1. 打开你的 GitHub 仓库（比如https://github.com/你的用户名/my-project）；
  2. 点击顶部「main」（当前分支名称）的下拉框；
  3. 在输入框中输入新分支名称（比如bugfix/login-error），点击「Create branch: bugfix/login-error from 'main'」；
    • 注意：默认基于主分支（main）创建，也可点击「Choose a branch to base on」选择其他分支作为基础；
  4. 创建成功后，仓库代码会和基础分支完全一致，且会自动切换至分支，可以通过分支下拉框切换main或现有分支。
2. 后续本地同步（网页端创建后需做）

如果网页端创建了远程分支，本地需要拉取这个分支才能开发：

bash

复制代码 
# 拉取远程新分支到本地，并自动切换到该分支
git switch bugfix/login-error  # Git 2.23+版本支持（自动关联远程分支）

# 老版本Git（低于2.23）：先拉取远程分支信息，再创建本地分支
git fetch origin  # 拉取所有远程分支的最新信息
git checkout -b bugfix/login-error origin/bugfix/login-error  # 基于远程分支创建本地分支

2.3 本地分支修改推送github

在已经建立了远程分支的本地分支，进行了相应的开发修改后，同样使用git push推送修改。完整过程如下：

2.3.1 前提确认（可选）

  1. 确认当前所在分支是「已修改的远程分支对应的本地分支」： bash

    运行

    复制代码 
    git branch  # 查看当前分支（前面带 * 号）
# 示例输出：* feature/login （说明当前在本地 feature/login 分支，正确）
    • 若不在目标分支，先切换：git switch 分支名（如 git switch feature/login）；

  2. 确认本地分支已和远程分支关联（之前推送时用了 -u 就已关联）：

    bash

    运行

    复制代码 
    git branch -vv  # 查看分支关联状态
# 示例输出：feature/login 1234567 [origin/feature/login] 提交备注（说明已关联，正确）
    • 若未关联（无 [origin/分支名]），后续推送时需补全关联命令（下文会讲）。
2.3.2 完整操作步骤（含命令 + 作用 + 示例）
步骤 1：查看本地修改内容（可选但推荐）

作用：确认修改的文件和内容，避免误提交无关文件。

bash

运行

复制代码 
git status  # 查看哪些文件被修改/新增/删除
git diff    # 查看具体修改的代码（按 q 退出查看）

示例输出：

plaintext

复制代码 
On branch feature/login
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   src/login.js  # 已修改的文件
        new file:   src/login.css  # 新增的文件

no changes added to commit (use "git add" and/or "git commit -a")
步骤 2：将修改添加到暂存区

作用：告诉 Git 哪些修改需要纳入本次提交（暂存区是本地提交的 "准备区"）。

bash

运行

复制代码 
# 方法1：添加指定文件（精准控制，推荐）
git add src/login.js src/login.css  # 示例：添加修改的2个文件

# 方法2：添加所有修改/新增/删除的文件（快捷，适合修改文件少的场景）
git add .  # 注意：是英文句号，代表当前目录下所有修改

验证 ：再次执行 git status，会显示「Changes to be committed」，说明文件已加入暂存区。

步骤 3：提交修改到本地分支

作用：将暂存区的修改 "保存" 到本地分支的提交历史中（本地操作，未同步到 GitHub）。

bash

运行

复制代码 
# 语法：git commit -m "提交备注"（备注必须清晰，说明修改内容）
git commit -m "feat: 完善登录功能（添加样式文件+优化表单校验逻辑）"

提交备注规范（和之前一致，便于追溯）：

  • feat：新功能 / 功能优化；
  • fix：修复 bug；
  • docs：文档修改；
  • style：代码样式调整（不影响逻辑）；
  • refactor：代码重构。
步骤 4：推送到 GitHub 对应的远程分支

作用：将本地分支的提交同步到 GitHub 上的远程分支（核心步骤，完成后 GitHub 会更新）。

bash

运行

复制代码 
# 情况1：本地分支已和远程分支关联（之前用了 -u 推送过）
git push  # 直接推送，无需写额外参数（Git 会自动推送到关联的远程分支）

# 情况2：本地分支未关联远程分支（首次推送或未用 -u ）
# 语法：git push -u 远程仓库别名 本地分支名:远程分支名（默认远程分支名和本地一致）
git push -u origin feature/login
  • 参数说明 ：-u 是「关联本地和远程分支」，后续再推送该分支时，直接用 git push 即可；
  • 验证成功 ：推送后终端显示「100%」「done」，打开 GitHub 仓库的对应分支（如 feature/login），能看到最新的提交记录。
步骤 5：后续补充操作（可选）

（1）查看远程分支的提交记录

bash

运行

复制代码 
# 查看本地分支的提交历史（含远程同步的记录）
git log --oneline  # 简洁显示（哈希值+提交备注）

# 查看远程分支的提交记录（确认是否推送成功）
git log origin/feature/login --oneline

（2）推送时提示 "远程分支有更新，需要先拉取"

若多人协作同一远程分支，别人已推送过提交，你推送时会提示「failed to push some refs」，需先拉取远程分支的最新代码，避免覆盖他人提交：

bash

运行

复制代码 
# 拉取远程分支的最新代码，合并到本地分支
git pull origin feature/login

# 若拉取时出现冲突，按之前教程解决（手动修改冲突文件→git add→git commit）
# 解决后再推送
git push

2.4📖小结

  • 归属：和主分支（main）属于「同一个仓库」，共享仓库的所有配置（比如 README、权限、Issues 等）；
  • 关系：远程分支和本地分支是「对应关系」（通过git branch -vv可查看关联状态）；
  • 操作：可推送代码更新、发起 PR 合并到主分支、合并后删除（不影响仓库本身）。

三、自己仓库的远程分支合并到 GitHub 主仓库

核心逻辑：自己仓库的远程分支（如 feature/xxx）合并到主仓库（main），本质是「同一仓库内的分支合并」------ 推荐用「GitHub 网页端 PR 合并法」（规范、留痕，适配分支保护规则），也支持「本地命令行合并法」（快捷高效）。

3.1 方法 1：GitHub 网页端 PR 合并法（推荐，99% 场景用）

通过「Pull Request（PR）」合并，适合：

  • 需保留合并记录（方便后续追溯）；
  • 主仓库开启了「分支保护规则」（禁止直接推送 main 分支）；
  • 想先审核代码再合并（即使是个人项目，也能避免误合并）。

操作步骤（全可视化，无需复杂命令）：

步骤 1：进入你的 GitHub 仓库

打开仓库地址（如 https://github.com/你的用户名/my-project），确保已登录账号。

步骤 2：发起 PR（合并远程分支到 main）
  1. 点击顶部导航栏的「Pull requests」→ 点击「New pull request」；
  2. 配置「源分支」和「目标分支」（核心！别选错）：
    • 「base branch」（目标分支）：选择 main（要合并到的主分支）；
    • 「compare branch」（源分支）：选择你要合并的远程功能分支（如 feature/login）；配置后，页面会显示「 Able to merge」（绿色对勾，无冲突）或「Can't automatically merge」（红色警告，有冲突）。
    • 点击「 Create pull request」
  3. 填写 PR 信息：
    • 「Title」：简洁描述合并目的（如「feat: 合并登录功能到主分支」）；
    • 「Description」：可选，详细说明修改内容（如「实现了账号密码登录、记住密码功能，测试通过」）；
  4. 点击「Create pull request」，完成 PR 创建。
步骤 3：审核并合并 PR
  1. 进入 PR 页面
  2. 进入申请详情页，点击「Files changed」查看修改的文件，确认代码无误（比如没有多余的调试代码、语法错误）；
  3. 若代码无问题，点击「Merge pull request」（合并按钮）；
  4. 选择合并方式（推荐默认选项）：
    • 「Create a merge commit」：保留完整的分支合并记录（最常用，可追溯）；
    • 「Squash and merge」：将分支的所有提交压缩为 1 个提交（使 main 分支历史更简洁）；
    • 「Rebase and merge」：将分支提交 "嫁接" 到 main 分支末尾（无合并节点，历史线性）；
  5. 点击「Confirm merge」，完成合并！
步骤 4：删除临时远程分支（可选但推荐）

合并后，远程的功能分支（如 feature/login）已无用，删除可保持仓库整洁：

  • 在 PR 合并成功页面，点击「Delete branch」按钮，直接删除远程分支；

  • 本地也可删除对应的功能分支： bash

    运行

    复制代码 
    # 切换到 main 分支
git switch main
# 删除本地功能分支（-d 仅删除已合并的分支）
git branch -d feature/login
步骤 5：同步本地 main 分支（关键）

合并后，GitHub 上的 main 分支已更新，但本地的 main 分支还是旧版本，需同步：

bash

运行

复制代码 
# 切换到本地 main 分支
git switch main
# 拉取远程 main 分支的最新代码（含合并后的功能）
git pull origin main

3.2 方法 2：本地命令行合并法（快捷，适合个人项目）

直接在本地合并功能分支到 main 分支，再推送到 GitHub，适合：

  • 个人项目（无需审核，想快速合并）；
  • 主仓库未开启分支保护（允许直接推送 main 分支）；
  • 临时小修改（如文档更新、小 bug 修复）。

操作步骤（全命令行，步骤少）:

步骤 1：切换到本地 main 分支并同步最新代码

bash

运行

复制代码 
# 1. 切换到本地 main 分支
git switch main
# 2. 拉取远程 main 分支的最新代码（避免本地 main 是旧版本）
git pull origin main
步骤 2：合并本地功能分支到 main 分支

bash

运行

复制代码 
# 语法：git merge 本地功能分支名
git merge feature/login
  • 若合并时提示「无冲突」，直接进入下一步；
  • 若提示「冲突」，按以下步骤解决：
    1. 用编辑器打开冲突文件，删除冲突标记（<<<<<<<、=======、>>>>>>>），保留正确代码；
    2. 提交冲突解决结果：git add 冲突文件名 → git commit -m "fix: 解决合并冲突"。
步骤 3：将合并后的 main 分支推送到 GitHub

bash

运行

复制代码 
# 推送本地更新后的 main 分支到远程 main 分支
git push origin main
步骤 4：删除本地和远程功能分支（可选）

bash

运行

复制代码 
# 1. 删除本地功能分支
git branch -d feature/login

# 2. 删除远程功能分支（若需保留可跳过）
git push origin --delete feature/login

3.3 两种方法对比（选对场景更高效）

对比维度 网页端 PR 合并法 本地命令行合并法
核心优势 规范、留合并记录、支持分支保护、可审核 快捷、步骤少、无需网页端操作
适用场景 团队协作、需追溯记录、主仓库有分支保护 个人项目、临时小修改、无分支保护
操作复杂度 中等（可视化操作，步骤清晰） 简单（全命令行，适合熟悉终端的用户）
冲突处理 需在本地解决冲突后重新推送 PR 直接在本地解决冲突，无需额外推送
合并记录 保留完整分支合并节点，可追溯 合并记录直接写入 main 分支，无独立 PR 记录

⚠️ 关键提醒：如果你的主仓库开启了「分支保护规则」（比如「禁止直接推送 main 分支」「必须通过 PR 合并」），只能用「网页端 PR 合并法」，命令行直接推送会被 GitHub 拒绝（报错「protected branch hook declined」）。

3.4 常见问题排查

  1. PR 显示「Can't automatically merge」（无法自动合并）

  • 原因：功能分支和 main 分支有冲突（同一文件同一部分被修改）；

  • 解决：回到「前提准备」步骤，重新执行 git pull origin main 拉取 main 最新代码，在本地解决冲突后推送功能分支，PR 会自动更新为「可合并」。

  1. 命令行推送 main 分支时提示「权限被拒绝」

  • 原因：SSH 配置错误，或主仓库有分支保护规则禁止直接推送；

  • 解决：

    • 检查 SSH 配置（cat ~/.ssh/id_rsa.pub 确认公钥已添加到 GitHub）；

    • 若提示「protected branch」，切换到「网页端 PR 合并法」。

  1. 合并后本地 main 分支还是旧版本

  • 原因：忘记执行 git pull origin main 同步远程 main 分支；

  • 解决：切换到 main 分支，执行 git pull origin main 即可同步最新代码。

  1. 想撤销合并操作（合并后发现问题）

场景 1：PR 已合并但未推送本地（仅本地合并后发现问题）

bash

运行

复制代码 
# 撤销最后一次合并提交（回到合并前的状态）
git reset --hard HEAD~1

场景 2：已推送合并后的 main 分支到 GitHub（谨慎使用！）

bash

运行

复制代码 
# 1. 本地撤销合并并强制推送（会覆盖远程 main 分支，团队协作时慎用）
git reset --hard HEAD~1
git push origin main --force-with-lease  # --force-with-lease 比 --force 更安全，避免覆盖他人提交

# 2. 或在 GitHub 网页端撤销 PR（合并后 90 天内可操作）：
# 进入 PR 详情页 → 点击「Revert」→ 填写撤销说明 → 「Create revert commit」→ 合并撤销 PR

⚠️ 团队协作时，若已推送合并后的代码，优先用「GitHub 网页端 Revert PR」，避免强制推送覆盖他人提交。

3.5 📖小结

合并远程分支到主仓库的核心流程：「同步最新代码 → 解决冲突 → 合并 → 推送更新」，关键是：

  1. 优先用「网页端 PR 合并法」，即使是个人项目，也能保留完整记录，后续便于追溯；
  2. 合并前必须同步 main 分支最新代码，减少冲突；
  3. 若主仓库有分支保护规则，严格按规则通过 PR 合并，不要强行命令行推送。

四、自己的仓库创建 Fork（很少用）

GitHub 支持给自己的仓库创建 Fork（本质是创建自己仓库的「独立副本」），但默认在网页端隐藏了直接操作的按钮（因为 Fork 设计初衷是跨用户 / 组织协作，自己仓库通常用分支即可），但有两种简单方法可以实现，下面分「网页端（推荐）」和「命令行」详细说明操作步骤。

4.1方法 1：GitHub 网页端操作（最常用，无需命令）

核心逻辑：通过修改 URL 绕开默认隐藏的 Fork 按钮，直接触发 Fork 流程，步骤如下：

步骤 1：进入你自己的目标仓库

打开你要 Fork 的仓库（比如你的仓库地址是 https://github.com/你的用户名/my-project），确保你已登录自己的 GitHub 账号。

步骤 2：手动修改仓库 URL，触发 Fork

在浏览器地址栏中，将原 URL 格式从：

plaintext

复制代码 
https://github.com/你的用户名/仓库名

修改为：

plaintext

复制代码 
https://github.com/fork/你的用户名/仓库名

示例：

原仓库 URL：https://github.com/zhangsan/my-blog修改后 URL：https://github.com/fork/zhangsan/my-blog

输入修改后的 URL 并回车，会自动跳转到「Fork 确认页面」。

步骤 3：确认 Fork 配置

跳转后，页面会显示「Create a new fork」（和 Fork 别人仓库的页面一致）：

  • 「Owner」：默认是你自己的 GitHub 账号（不可修改，因为是 Fork 给自己）；
  • 「Repository name」：默认是原仓库名（可修改，比如改成 my-blog-fork，避免和原仓库重名混淆）；
  • 「Description」：可选，填写 Fork 仓库的用途（比如「用于重构实验，不影响原仓库」）；
  • 「Copy the main branch only」：默认勾选，只复制主分支（如果需要复制所有分支，取消勾选）。
步骤 4：完成 Fork

点击页面底部的「Create fork」按钮，等待 1~3 秒，即可创建成功！

验证成功

创建后会自动跳转到新的 Fork 仓库，页面顶部会显示「Forked from 你的用户名 / 原仓库名」（比如「Forked from zhangsan/my-blog」），说明 Fork 成功。此时这个 Fork 仓库是完全独立的，归你所有，可自由修改、删除。

4.2 方法 2：命令行操作（适合习惯终端的用户）

核心逻辑：先克隆自己的原仓库到本地，再在 GitHub 新建一个空仓库，最后将本地克隆的代码推送到新仓库（本质是手动实现「Fork 副本」的效果，和网页端 Fork 功能一致）。

步骤 1：克隆自己的原仓库到本地

bash

运行

复制代码 
# 克隆原仓库（用 SSH 地址，已配置 SSH 可免密码）
git clone git@github.com:你的用户名/my-project.git

# 进入仓库目录
cd my-project
步骤 2：在 GitHub 新建一个空仓库（作为 Fork 副本）
  1. 打开 GitHub 主页，点击右上角「+」→「New repository」；
  2. 填写仓库信息：
    • 「Repository name」：比如 my-project-fork（和原仓库区分）；
    • 「Description」：可选，填写用途；
    • 「Visibility」：和原仓库一致（公开 / 私有）；
    • 关键：不要勾选「Initialize this repository with a README」（保持空仓库，避免后续推送冲突）；
  3. 点击「Create repository」，创建空仓库。
步骤 3：将本地原仓库代码推送到新仓库（实现 Fork 副本）

bash

运行

复制代码 
# 1. 删除本地仓库关联的原仓库远程地址（origin 原本指向原仓库）
git remote remove origin

# 2. 关联新建的空仓库（Fork 副本）的 SSH 地址
git remote add origin git@github.com:你的用户名/my-project-fork.git

# 3. 将本地所有代码（含分支）推送到新仓库
git push -u origin --all
  • --all：推送所有本地分支（如果只想推送主分支，去掉 --all 即可）；
  • -u：关联本地分支和新仓库的远程分支，后续推送直接用 git push。
验证成功

打开新建的 my-project-fork 仓库，会看到和原仓库完全一致的代码和分支，说明手动 Fork 成功（效果和网页端 Fork 完全相同）。

4.3 自己仓库的Fork同步原仓库的更新

Fork 后的仓库是独立的，原仓库后续有新提交（比如合并了新功能），Fork 副本不会自动同步，需要手动配置「上游仓库（upstream）」：

步骤 1：在 Fork 副本的本地仓库中配置 upstream

bash

运行

复制代码 
# 进入 Fork 副本的本地仓库目录
cd my-project-fork

# 添加上游仓库（即你的原仓库 SSH 地址）
git remote add upstream git@github.com:你的用户名/my-project.git

# 验证配置：查看远程仓库关联（会显示 origin 和 upstream）
git remote -v
步骤 2：同步原仓库的最新代码

bash

运行

复制代码 
# 1. 拉取原仓库（upstream）的所有更新（不合并）
git fetch upstream

# 2. 合并原仓库的 main 分支到 Fork 副本的本地 main 分支
git merge upstream/main

# 3. 推送到 Fork 副本的远程仓库（更新远程副本）
git push origin main

这样就完成了 Fork 副本和原仓库的同步，后续需要同步时重复这 3 步即可。

五、自己仓库的 Fork更新到原仓库

由于 Fork 仓库和原仓库是「完全独立的仓库」，修改后的更新本质是「跨仓库代码合并」------ 推荐用「PR 合并法」（规范、留记录），个人场景可直接用「命令行推送法」（快捷高效），下面分步骤详细说明。

前提准备（必须先完成）

在操作更新前，确保满足以下 3 个条件：

  1. 已在 Fork 仓库（比如 my-project-fork）完成修改（代码已提交到本地 Fork 仓库的分支）；

  2. 本地 Fork 仓库已配置「上游仓库（upstream）」（即关联你的原仓库），若未配置，执行以下命令： bash

    运行

    复制代码 
    # 进入本地 Fork 仓库目录
cd my-project-fork

# 添加上游仓库（原仓库的 SSH 地址）
git remote add upstream git@github.com:你的用户名/my-project.git

# 验证配置（显示 origin=Fork仓库、upstream=原仓库，即为成功）
git remote -v

  3. 已同步原仓库的最新代码（避免 Fork 仓库的修改与原仓库脱节，导致冲突）： bash

    运行

    复制代码 
    # 1. 拉取原仓库（upstream）的所有更新（不合并）
git fetch upstream

# 2. 切换到 Fork 仓库的修改分支（比如你开发的 feature/refactor 分支）
git switch feature/refactor

# 3. 合并原仓库的 main 分支到当前修改分支（同步最新代码，避免冲突）
git merge upstream/main
    • 若合并时出现「冲突」，按之前教程的「冲突解决步骤」处理（手动修改冲突文件 → git add → git commit）；
    • 冲突解决后，将同步后的修改推送到远程 Fork 仓库：git push origin feature/refactor。

方法 1：PR 合并法（推荐，规范且留痕）

通过「跨仓库 Pull Request」将 Fork 仓库的修改合并到原仓库，适合：

  • 团队协作场景（需要代码审核、留合并记录）；
  • 希望保留完整操作日志（方便后续追溯修改）；
  • 原仓库开启了分支保护（禁止直接推送 main 分支）。

操作步骤（GitHub 网页端 + 少量命令）

步骤 1：将 Fork 仓库的修改分支推送到远程 Fork 仓库

确保本地 Fork 仓库的修改已推送到 GitHub 上的 Fork 仓库（若已推送可跳过）：

bash

运行

复制代码 
# 推送本地修改分支（比如 feature/refactor）到远程 Fork 仓库（origin）
git push -u origin feature/refactor
步骤 2：在 GitHub 发起「跨仓库 PR」（Fork → 原仓库）
  1. 打开你的 Fork 仓库 （比如 https://github.com/你的用户名/my-project-fork）；
  2. 点击顶部「Pull requests」→「New pull request」；
  3. 关键配置（核心！确保目标是原仓库）：
    • 「base repository」：选择「你的用户名 /my-project」（你的原仓库，即要更新到的目标仓库）；
    • 「base branch」：选择原仓库的接收分支（通常是 main，也可根据需求选其他分支）；
    • 「compare repository」：默认是「你的用户名 /my-project-fork」（你的 Fork 仓库，即修改后的仓库）；
    • 「compare branch」：选择你在 Fork 仓库中修改的分支（比如 feature/refactor）；配置完成后，页面会显示「可合并」（绿色对勾）或「有冲突」（红色警告，需先解决冲突）。
步骤 3：填写 PR 信息并提交
  • 「Title」：简洁描述修改内容（比如「refactor: 重构首页代码结构，优化加载速度」）；
  • 「Description」：可选，详细说明修改目的、改动点（比如「修改了 index.js 的渲染逻辑，删除冗余代码，加载时间从 2s 优化到 500ms」）；
  • 点击「Create pull request」，完成 PR 创建。
步骤 4：审核并合并 PR（你作为原仓库所有者）
  1. 进入原仓库的「Pull requests」页面（https://github.com/你的用户名/my-project/pulls），找到刚才创建的 PR；
  2. 查看「Files changed」确认修改内容无误（若有问题可在评论区备注，返回 Fork 仓库修改后重新推送，PR 会自动更新）；
  3. 若无误，点击「Merge pull request」→ 选择合并方式（默认「Create a merge commit」即可，保留合并记录）；
  4. 点击「Confirm merge」，完成合并！此时原仓库的 main 分支就包含了 Fork 仓库的修改。
步骤 5：后续清理（可选但推荐）
  • 合并后，在 PR 页面点击「Delete branch」，删除 Fork 仓库远程的 feature/refactor 分支；
  • 本地 Fork 仓库也可删除该分支：git switch main && git branch -d feature/refactor。

方法 2：命令行直接推送法（快捷，适合个人场景）

由于你是原仓库的所有者（拥有「写权限」），可直接将 Fork 仓库的修改分支推送到原仓库，再合并到主分支，适合：

  • 个人项目（无需审核，想快速更新）；
  • 临时修改（比如小 bug 修复，无需留 PR 记录）；
  • 原仓库未开启分支保护（允许直接推送主分支）。

操作步骤（全命令行，无需网页端）：

步骤 1：切换到 Fork 仓库的修改分支，确保修改已提交

bash

运行

复制代码 
# 进入本地 Fork 仓库目录
cd my-project-fork

# 切换到修改分支（比如 feature/refactor）
git switch feature/refactor

# 确保所有修改已提交（无未提交文件，可通过 git status 检查）
git status  # 显示「nothing to commit」即为正常
步骤 2：直接推送到原仓库的临时分支

不直接推送到原仓库的 main 分支（避免污染稳定分支），先推送到原仓库的一个临时分支（比如 temp/refactor-from-fork）：

bash

运行

复制代码 
# 语法：git push 上游仓库别名 本地修改分支:原仓库临时分支名
git push upstream feature/refactor:temp/refactor-from-fork
  • 解释：upstream 是原仓库的别名，feature/refactor 是 Fork 仓库的修改分支，temp/refactor-from-fork 是在原仓库新建的临时分支（用于存放 Fork 的修改）。
步骤 3：合并到原仓库的主分支（本地或网页端）
方式 A：本地合并（推荐，快捷）

bash

运行

复制代码 
# 1. 克隆原仓库到本地（若已克隆，直接进入目录）
git clone git@github.com:你的用户名/my-project.git
cd my-project

# 2. 拉取刚才推送的临时分支（确保本地有该分支）
git fetch upstream temp/refactor-from-fork  # 若原仓库本地别名是 origin，用 git fetch origin

# 3. 切换到原仓库的 main 分支
git switch main

# 4. 合并临时分支到 main 分支
git merge temp/refactor-from-fork

# 5. 推送合并后的 main 分支到原仓库远程
git push origin main
方式 B：网页端合并（和方法 1 的步骤 4 一致）
  1. 打开原仓库的「Branches」页面，找到 temp/refactor-from-fork 分支；
  2. 点击该分支旁的「New pull request」，目标分支选 main；
  3. 审核无误后合并，合并后删除 temp/refactor-from-fork 临时分支。
步骤 4：清理临时分支（可选）
  • 删除原仓库远程的临时分支：git push upstream --delete temp/refactor-from-fork；
  • 删除本地 Fork 仓库的修改分支：git branch -d feature/refactor。

两种方法对比（选对场景更高效）

对比维度 PR 合并法 命令行直接推送法
核心优势 规范、留合并记录、支持审核 快捷、无需网页端操作、步骤少
适用场景 团队协作、需追溯记录、分支保护 个人项目、临时修改、无协作需求
操作复杂度 中等（网页端 + 少量命令） 简单（全命令行，步骤少）
风险程度 低（合并前可检查冲突，有审核环节） 中（直接推送原仓库，需确保修改无误）

⚠️ 注意：若原仓库开启了「分支保护规则」（比如禁止直接推送 main 分支、必须通过 PR 合并），只能用「PR 合并法」，命令行直接推送会被 GitHub 拒绝。

六、别人仓库的分支操作【常用】（Fork + PR 流程）

当你想给别人的开源项目贡献代码（但没有原仓库的写权限）时，需要通过「Fork + 分支开发 + PR」的流程，核心逻辑是：在自己的 Fork 仓库（原仓库的副本）上开发，再向原仓库发起合并请求。

6.1 流程总览

Fork 原仓库 → 克隆到本地 → 配置上游仓库 → 创建功能分支 → 开发提交 → 同步原仓库最新代码 → 推送到自己的 Fork 仓库 → 向原仓库发起 PR → 配合审核修改

6.2 具体操作步骤（含命令 + 示例）

步骤 1：Fork 别人的仓库（GitHub 网页端）
  1. 打开目标仓库（比如https://github.com/别人用户名/open-project）；
  2. 点击右上角的「Fork」按钮，等待几秒，会自动复制仓库到你的 GitHub 账号下（比如https://github.com/你的用户名/open-project）。
步骤 2：将自己 Fork 的仓库克隆到本地

作用：把远程的 Fork 仓库下载到本地，方便开发。

bash

运行

复制代码 
# 语法：git clone 你的Fork仓库的SSH地址（避免输入密码，已配置SSH）
git clone git@github.com:你的用户名/open-project.git

# 进入仓库目录
cd open-project

获取 SSH 地址：打开你 Fork 后的仓库 → 点击「Code」→ 选择「SSH」→ 复制地址。

步骤 3：配置「上游仓库」（upstream）

核心作用：你的 Fork 仓库是原仓库的「快照」，原仓库后续会有其他贡献者提交代码，配置 upstream 后，你能随时同步原仓库的最新代码，避免你的分支和原仓库脱节。

bash

运行

复制代码 
# 1. 添加上游仓库（原仓库的SSH地址）
git remote add upstream git@github.com:别人用户名/open-project.git

# 2. 验证配置是否成功（查看所有远程仓库关联）
git remote -v

成功结果：会显示两个远程仓库：

  • origin：你的 Fork 仓库（自己能写）；
  • upstream：原仓库（只能读，用于同步最新代码）。
步骤 4：创建功能分支（基于原仓库的 main 分支）

注意 ：必须基于upstream/main（原仓库的最新主分支）创建功能分支，否则 PR 可能因代码过时被拒绝。

bash

运行

复制代码 
# 1. 拉取上游仓库的最新代码（同步到本地，但不合并）
git fetch upstream

# 2. 基于上游仓库的main分支，创建自己的功能分支
git switch -c feature/optimize-button upstream/main

解释 ：feature/optimize-button是你的功能分支（比如「优化按钮样式」），基于upstream/main创建，确保代码是原仓库的最新版本。

步骤 5：开发并提交代码（和自己仓库操作一致）

在feature/optimize-button分支开发（比如修改按钮的颜色、大小），完成后提交：

bash

运行

复制代码 
git add .
git commit -m "feat: 优化按钮样式（增加圆角+hover效果）"
步骤 6：同步上游仓库的最新代码（关键步骤）

在你开发期间，原仓库可能有其他贡献者合并了 PR，导致原仓库的main分支更新，你需要同步这些更新，避免冲突：

bash

运行

复制代码 
# 1. 再次拉取上游仓库的最新代码
git fetch upstream

# 2. 合并上游main分支到你的功能分支
git merge upstream/main

若出现冲突：按照「第二部分的冲突解决步骤」处理（手动修改冲突文件→提交→推送）。

步骤 7：将功能分支推送到自己的 Fork 仓库（origin）

bash

运行

复制代码 
git push -u origin feature/optimize-button

说明 ：这里推送到的是origin（你的 Fork 仓库），不是upstream（原仓库，你没有写权限）。

步骤 8：向原仓库发起 PR（GitHub 网页端）
  1. 打开你 Fork 后的仓库（https://github.com/你的用户名/open-project）；
  2. 点击「Pull requests」→「New pull request」；
  3. 关键配置（避免出错！）：
    • 「base repository」：选择「别人用户名 /open-project」（原仓库）；
    • 「base branch」：选择原仓库的目标分支（通常是main）；
    • 「compare repository」：选择「你的用户名 /open-project」（你的 Fork 仓库）；
    • 「compare branch」：选择你的功能分支feature/optimize-button；
  4. 填写 PR 标题和描述（要清晰说明你做了什么修改，为什么修改，比如「优化按钮样式，提升用户体验」）；
  5. 点击「Create pull request」，完成 PR 发起。
步骤 9：配合审核并修改（若需要）
  • 原仓库的维护者会审核你的 PR，可能会提出修改意见（比如代码规范、逻辑优化）；
  • 你需要在本地的feature/optimize-button分支修改代码，修改后执行git add .→git commit→git push，PR 会自动更新；
  • 维护者审核通过后，会合并你的代码到原仓库的main分支，此时你就完成了一次开源贡献！
步骤 10：后续清理（可选）

PR 合并后，你可以删除自己 Fork 仓库的feature/optimize-button分支（GitHub 网页端 PR 页面点击「Delete branch」），以及本地的该分支：

bash

运行

复制代码 
git switch main
git branch -d feature/optimize-button

附录

远程分支的常见操作（关联之前的教程）

  1. 查看所有远程分支 ：git branch -r（前缀origin/表示远程分支）；

  2. 删除远程分支 （功能合并后清理）：

    bash

    复制代码 
    # 语法：git push origin --delete 远程分支名
git push origin --delete feature/comment

  3. 取消本地分支与远程分支的关联 ：

    bash

    复制代码 
    git branch --unset-upstream 本地分支名  # 比如 git branch --unset-upstream feature/comment

  4. 更新远程分支列表 （本地看不到远程已删除的分支时）：

    bash

    复制代码 
    git fetch origin --prune  # 简写 git fetch -p，删除本地缓存的已不存在的远程分支

自己仓库的「远程分支」vs「自己仓库的 Fork」（核心区别）

很多人会混淆这两个概念 ------ 本质区别是「分支是同一仓库内的并行线，Fork 是独立的仓库副本」，具体对比用表格 + 场景举例说明，一目了然：

对比维度 自己仓库的远程分支（比如 origin/feature/xxx） 自己仓库的 Fork（比如你的用户名 /my-project-fork）
本质 同一仓库内的「并行代码线」（仓库不变，只是代码版本分支） 基于原仓库复制的「独立仓库」（全新的仓库，和原仓库是 "副本 - 原品" 关系）
归属关系 属于「同一个仓库」（比如 my-project），所有分支共享仓库权限、配置 属于「你的独立仓库」（和原仓库无直接归属，原仓库删除不影响 Fork 仓库）
数据同步 本地分支↔远程分支通过git push/pull直接同步（无需额外配置） Fork 仓库↔原仓库需配置「upstream 上游仓库」，通过git fetch/pull upstream同步
权限控制 继承原仓库权限（你是仓库所有者，可操作所有分支） Fork 仓库是你的独立仓库，你拥有完全控制权（可修改权限、删除仓库等）
合并逻辑 分支间合并通过「仓库内 PR」（比如 feature 分支→main 分支，无需跨仓库） Fork 仓库合并到原仓库需「跨仓库 PR」（但你是原仓库所有者，PR 本质是自己审核自己）
占用空间 不额外占用仓库存储（分支仅存储代码差异，Git 底层共享相同代码版本） 占用独立存储（Fork 仓库是完整副本，和原仓库占用相同空间，后续修改独立累计）
适用场景 同一仓库内的功能开发、bug 修复（比如开发新功能、临时测试） 特殊场景：比如需要保留原仓库的 "纯净版本"，同时在副本中做破坏性修改（比如重构、测试实验性功能）；或多人协作时隔离权限（但自己仓库无需隔离）
相关推荐
sean9083 小时前
git filter-repo(优秀的 git repo 历史重写工具) 实战
git·repo·工具
hen3y3 小时前
清理 Git 代码库大文件历史记录
运维·git
CoderJia程序员甲4 小时前
GitHub 热榜项目 - 日榜(2025-11-22)
ai·开源·llm·github·ai教程
小Lu的开源日常4 小时前
踩坑日记：为什么Git 突然 Push 不上去了
git·ssh·github
LZ7工作室5 小时前
MAC编程：在MACOS安装和使用 Git 的方法
网络·git·macos·github·个人开发
T***16077 小时前
Git增强现实案例
git·ar
Arva .9 小时前
git常用
git
久莜9 小时前
【Git】使用教程
git
果子火火9 小时前
Git clone couldn‘t connect to server
git
热门推荐
01GitHub 镜像站点02BongoCat - 跨平台键盘猫动画工具03【保姆级教程】免费使用Gemini3的5种方法！免翻墙/国内直连04UV安装并设置国内源05Google Antigravity：无法登录？早期错误、登录修复和用户反馈指南06安娜的档案(Anna’s Archive) 镜像网站/国内最新可访问入口（持续更新）07Linux下V2Ray安装配置指南08今天 Cloudflare 全球事故，连 GPT 和你的网站都一起“掉线”了09全球最强模型Grok4，国内已可免费使用！（附教程）1046个Nano-banana 精选提示词，持续更新中