fork git介绍

Fork(Git可视化客户端)完整介绍 Markdown文档

⚠️ 分清两个完全不同概念：

1. Fork（网页功能）：GitHub/Gitee上面复制别人仓库的操作（无软件）
2. Fork（软件）：一款Windows/Mac平台的Git图形化GUI客户端工具，就是下面介绍的软件

一、什么是 Fork 软件

Fork 是一款原生、高性能、简洁好用的 Git 可视化桌面客户端，官方标语：a fast and friendly git client for Mac and Windows（一款快速友好的Git客户端）。

简单来讲： 不用再敲 git add / git commit / git push 等一堆命令，通过鼠标点击界面，就可以完成几乎所有 Git 的操作。

💡前提：电脑必须先安装好Git本体，Fork只是可视化外壳，本身不带Git内核。

基础信息

项目	详情
支持系统	Windows、macOS，无Linux版本
软件性质	闭源商业软件
费用规则	个人免费使用；企业商用需要购买授权；一次性买断，无订阅费
官网	https://git‑fork.com

Fork软件核心优势

1. 速度极快 原生程序，大型仓库、上万条提交记录也不会卡顿，是它最大亮点，对比Sourcetree、TortoiseGit流畅很多。
2. 界面干净清爽 布局简单：仓库列表‑提交历史‑代码差异区，没有多余广告、冗余功能。
3. 新手友好 所有Git操作可视化，分支图谱一眼看懂，降低命令行学习门槛。
4. 高级Git功能强大 交互式变基、冲突解决、cherry‑pick、图片对比，很多GUI工具不好用的功能，Fork体验优秀。

主要功能清单

✅ 基础日常功能（小白最常用）

• 新建仓库 git init
• 克隆远程仓库 git clone
• 文件修改预览、逐行暂存代码（可以只提交文件中一部分改动）
• Commit（提交）、Amend（修改上一次提交）
• Fetch / Pull（拉取）、Push（推送）
• 分支创建、切换、合并、删除
• Tag标签管理
• Stash储藏临时改动

界面布局说明

1. 左侧边栏：仓库管理器、分支列表、标签、储藏、子模块
2. 中上区域：所有提交历史图谱（彩色线条直观展示各个分支走向）
3. 下方Changes区：当前修改的文件列表
4. 右侧Diff对比区：文件修改前后的代码对比（红色删除、绿色新增）

新手最简单上手流程

1. 电脑提前安装好Git（必须）
2. 官网下载安装 Fork软件
3. 打开Fork → File‑>Open：打开你本地已经存在的项目文件夹；或者Clone克隆远程仓库
4. 修改你的项目代码
5. 在Fork下方勾选改动文件 → 填写提交信息 → Commit
6. 点击Push推送到云端仓库

一个四分钟的教学视频

小白避坑提示

1. Fork ≠ Git，必须单独安装Git，否则软件无法运行。
2. Fork只是操作工具，底层执行的还是Git命令，学好基础Git概念（工作区、暂存区、分支）再用GUI工具，不容易懵。
3. 免费仅限个人开发，公司商用需要购买授权。

合并分支选项

Default: Fast-forward if possible（默认：如果可能则快进）这是 Git 的默认行为。

• 机制：如果当前分支（main）在分叉后没有任何新的提交，Git 会直接将 main 的指针移动到 origin/master 的最新提交上。
• 结果：不会产生一个新的”合并提交”节点。历史记录是一条直线，非常干净。
• 适用场景：个人项目或希望保持线性历史的简单开发流程。

No Fast-Forward（禁止快进 / --no-ff）

• 机制：即使满足”快进”的条件，Git 也会强制创建一个新的”合并提交”节点，将两个分支的历史连接起来。
• 结果：历史记录中会出现分叉和汇合的图形。你可以清楚地看到哪些提交是属于这个功能分支的。
• 适用场景：团队协作、正规项目开发。它能保留完整的功能开发上下文，方便日后回滚整个功能或追溯代码来源。

Squash（压缩合并 / --squash）

• 机制：将 origin/master 分支上的所有提交压缩成一个新的提交，然后应用到 main 分支上。
• 结果：origin/master 里原本琐碎的提交记录（如 “fix typo”, “update”, “wip”）都会消失，main 分支上只会多出一个整洁的提交。
• 适用场景：功能分支开发过程中提交很混乱，但合并到主分支时希望保持主分支历史极其简洁的情况。

Don't Commit（不自动提交 / --no-commit）

• 机制：Git 会执行合并操作并将变更写入工作区，但不会自动帮你生成提交记录。
• 结果：你需要手动检查合并后的代码，确认无误后，自己执行 git commit。
• 适用场景：当你需要在这个基础上再做一些微调，或者想在提交前仔细审查合并结果时使用。

提交

Amend 的意思是“修改/追加到上一次提交”。在 Git 中，它的对应命令是 git commit --amend。

勾选后，你当前暂存的改动不会生成一个新的提交记录，而是直接合并进上一次的提交记录中（并且你可以顺便修改上一次提交的说明文字）。所以按钮会变成“Amend Last Commit（修改上一次提交）”。

关于出现的警告 “Amending commit that has already been pushed !” （正在修改已经推送过的提交！），这是一个非常关键的危险提示：

⚠️ 为什么会有这个警告？

因为修改上一次提交会直接改写 Git 历史（会生成一个新的哈希值替换掉旧的）。如果这个提交已经推送到了远程仓库（比如 GitHub/GitLab），并且团队其他人已经拉取了这个旧提交，那么你修改后，别人的本地代码和远程仓库就会彻底冲突，导致他们无法正常合并，需要手动处理复杂的冲突。

🛠️ 怎么选？（操作建议）

1. 如果你还没有推送到远程（或者这是你自己一个人的私有分支）： 可以放心勾选。比如你刚提交完，发现漏加了一个文件，或者提交信息打错了一个字，勾选它直接修正，是最方便的做法。
2. 如果你已经推送到了远程，并且是多人协作的公共分支（比如 main/master）： 绝对不要勾选！ 正确的做法是取消勾选，像平时一样作为一次新的提交（Commit）提交上去。
3. 如果你必须修改已经推送的提交（且只有你一个人在用）： 勾选修改完成后，你需要执行强制推送（Force Push） 才能更新远程仓库。但在团队协作中，强制推送是被严格禁止的，因为会覆盖别人的代码。

💡 针对你当前的情况（修改文档）：

如果你不确定之前的提交是否已经被别人拉取过，最安全的做法是不勾选 Amend，直接点击 Commit 1 File 新增一个提交。这样最稳妥，不会影响到任何人。只有当你确定这仅仅是自己的本地操作时，再去用 Amend。

变基

Rebase 'main' on 'origin/master'

将当前分支（main）变基到远程分支（origin/master）之上(不推荐) 本质上就是把你的本地 main 分支“接”到远程 origin/master 分支的最新提交之后，但它的实现方式不是简单的“拼接”，而是通过“重写历史”来达成线性效果。

具体来说：

1. Git 会先找到 main 和 origin/master 的共同祖先；
2. 然后把你本地 main 上独有的提交“暂存”起来；
3. 接着把 origin/master 的最新状态作为新基底；
4. 最后把你暂存的提交“一个一个重放”到这个新基底上，形成一条全新的、线性的提交链。

⚠️ 关键点：虽然内容一样，但“身份”变了

虽然代码内容没变，但因为它们是“重新应用”到新基底上的，所以这些提交的 哈希值（Commit ID）会完全改变。

• Merge 是“打结”：保留原来的提交 ID，只是多了一个合并节点把两条线连起来。
• Rebase 是“重写”：原来的提交被销毁了，生成了新的提交 ID 接在后面。

main 分支不仅依然存在，而且会变得“更新、更干净”。

• 执行 Rebase 'main' on 'origin/master' 后，你的 main 分支不会消失，而是会发生以下变化：
• 位置前移：它的指针会移动到 origin/master 的最新提交之后。
• 历史重写：它原本独有的提交会被“复制”一份接在后面，旧的提交记录会被丢弃（虽然内容一样，但哈希值变了）。
• 线性化：分叉的曲线会变成一条直线。

你可以把它想象成“剪枝嫁接”：把 main 从老树干上剪下来，嫁接到 origin/master 这根新树干的最顶端。树还在，只是长得更高、更直了。

⚠️ 重要提醒

因为 Rebase 会改变提交的哈希值，如果这个 main 分支已经推送到远程且其他人正在基于它开发，执行 Rebase 会导致他们的本地历史与远程冲突。只对私有分支或尚未推送的本地分支使用 Rebase。

reset 操作

🟢 Soft（软重置）：保留所有修改，且自动暂存

• 效果：将分支指针（HEAD）移动到指定提交，但不改变工作区和暂存区。你之前所有的修改都会被保留在“已暂存”状态，可以直接再次提交。
• 适用场景：你想撤销最近几次提交，但希望保留代码修改，方便重新组织或合并提交信息。比如，你提交了3次，发现提交信息写错了，想合并成一个更清晰的提交。

🟡 Mixed（混合重置）：保留所有修改，但取消暂存

• 效果：将分支指针移动到指定提交，清空暂存区，但保留工作区的文件修改。你的代码改动还在，但需要重新 git add 才能提交。
• 适用场景：你想撤销提交，但不确定哪些修改要保留，或者想重新选择要提交的文件。这是最安全的回滚方式，因为代码不会丢失。

🔴 Hard（硬重置）：丢弃所有本地修改

• 效果：将分支指针、暂存区、工作区全部回滚到指定提交的状态。你之后所有的修改都会被彻底删除，无法恢复（除非有备份）。
• 适用场景：你确定之后的修改都是错误的，或者想完全回到某个干净的历史节点。风险极高，慎用！

一句话总结

• Soft：撤销提交，代码还在，已暂存 → 适合“重做提交”。
• Mixed：撤销提交，代码还在，未暂存 → 适合“重新选择提交内容”。
• Hard：撤销提交，代码全丢 → 适合“彻底放弃修改”。

⚠️ 重要提醒：

reset 会改写历史，如果这些提交已经推送到远程仓库，执行后需要强制推送（git push --force），这会影响其他协作者。只对本地未推送的提交使用 reset。

git reset 或git rebase需要强制推送

是因为你本地的提交历史已经被重写（比如通过 git reset 或 git rebase），与远程仓库的历史不再兼容。Git 默认会拒绝这种“非快进”的推送，以防止意外覆盖他人工作。只有使用 --force（或 -f）才能强行覆盖远程历史。

为什么会出现“不兼容”？ 当你执行 git reset --hard 或 git rebase 时，Git 会丢弃旧的提交记录，并生成新的提交哈希值。这意味着：

• 本地分支的“历史链”被截断或重排；
• 远程仓库仍保留着旧的提交链；
• 两者在 Git 看来是“分叉”的，无法直接合并。

此时，普通的 git push 会被拒绝，因为 Git 认为你试图“覆盖”远程已有的提交，这可能意味着数据丢失。

强制推送的本质 强制推送就是告诉 Git：“我清楚自己在做什么，我要用本地的新历史完全替换远程的历史。”它会：

• 删除远程分支上所有不在你本地历史中的提交；
• 将远程分支指针指向你本地的最新提交；
• 导致其他协作者的本地仓库与远程严重冲突。

⚠️ 重要提醒 强制推送是高风险操作，尤其在团队协作中。如果其他人已经基于你重置前的提交做了开发，他们的代码可能会丢失或产生难以解决的冲突。只在以下情况使用：

• 你的分支是私有的，没有其他人依赖；
• 你已经和团队沟通并获得同意；
• 你确定要彻底放弃远程上的某些提交。

更安全的替代方案

如果你只是想撤销错误提交而不想影响他人，可以考虑：

• git revert <commit-hash>：创建一个新提交来“反向”修改，保留历史完整；
• git push --force-with-lease：比 --force 更安全，它会检查远程是否被你之外的其他人更新过，避免误覆盖。

Git 眼里的真相是什么？

Git 不看文件长得像不像，它只看提交哈希值的父子关系。

• Master 线：9c07aea (根节点，没有爸爸)(就只有一个提交)
• Main 线：825c3c8 (它的爸爸是 096646c，一直往上追溯，永远找不到 9c07aea) 这就是为什么你在截图里看到它们是分叉的，而且如果你直接删除 Master，Git 会警告你“这个提交将永久丢失”，因为它不属于 Main 的任何一条祖先链。

Rebase（变基）是目前“最好”的选择

从你的 Git 历史图来看，这是一个非常典型的分叉（Diverged）状态：

• Main 分支（上方）：你有大约 15 个新的提交（主要是文档和重构）。
• origin/master（下方）：远程主分支停留在很久以前的一个初始提交上。

Rebase（变基）后Rebase 'main' on 'origin/master'

1. 强制推送 Main (如果还没做) 因为你对本地 main 做了 rebase，它的提交哈希值（Commit ID）全变了。如果你直接 git push，Git 会拒绝，因为它觉得你的本地历史和远程不一致。你需要告诉远程：“用我本地的新历史覆盖掉远程的旧历史”。
2. 第二步：删除远程的 Master 一旦确认 main 已经包含了所有历史（就像截图里那样，从底向上连贯），那个孤零零的 origin/master 就没有存在的必要了。 bash
3. 第三步：删除本地的 Master (可选) 如果你的本地还有一个叫 master 的分支（截图里没显示，但可能有），也可以删掉以保持清爽。 bash
4. 第四步：清理远程引用 删除远程分支后，你本地的 Git 记录里可能还会残留一个 origin/master 的影子。运行这个命令来清理：

   git fetch --prune