Featured image of post 一些GitHub+Git使用技巧
Learning

一些GitHub+Git使用技巧

^_^

回滚

在 GitHub Desktop 中，“回滚”（Rollback）根据你所处的阶段（是否已提交、是否已推送）有不同的操作方法。

以下是三种最常见的场景及其在 GitHub Desktop 中的具体操作步骤：

场景一：代码改乱了，但还没有 Commit（提交）

情况：你在本地修改了文件，但还没有点击 “Commit to main”，想要放弃这些修改，恢复到上次提交时的样子。

操作步骤：

  1. 打开 GitHub Desktop，确保停留在 Changes（更改）标签页。 image.png|720x498

  2. 你会看到所有被修改的文件列表。

  3. 回滚单个文件：右键点击该文件，选择 Discard changes（丢弃更改）。 image.png|720x488

  4. 回滚所有文件：点击左上角的 Changes 下拉菜单，选择 Discard all changes。 image.png

    • ⚠️ 警告：此操作不可逆，修改的内容将永久丢失。

场景二：刚刚 Commit 了，但还没有 Push（推送）

情况：你刚刚提交了一个版本，发现提交信息写错了，或者漏了文件，想要撤销这最后一次提交，把代码变回提交前的状态。

操作步骤：

  1. 切换到 History（历史记录）标签页。

  2. 在列表最顶部找到你刚刚提交的那条记录（HEAD）。

  3. 右键点击 这条提交记录。

  4. 选择 Undo commit（撤销提交）。 image.png

  5. 此时，该提交会消失，代码修改内容会重新回到 Changes 标签页中，你可以重新修改或再次提交。

    • 注意：这只会撤销本地最后一次提交，不会影响远程仓库。

场景三：已经 Push 到 GitHub 了，想要回滚

情况：代码已经推送到了远程仓库，但发现这个版本有问题，需要回退。这里有两种策略：

策略 A：安全回滚（推荐，使用 Revert）

原理：创建一个新的提交，这个提交的内容是“反向操作”之前的错误提交。这样不会破坏历史记录，适合多人协作。 操作步骤：

  1. 在 History 标签页中，找到你想要回滚的那次提交。 image.png

  2. 右键点击 该提交。

  3. 选择 Revert commit（回退提交）。 image.png|720x399

  4. GitHub Desktop 会自动创建一个新的提交，抵消之前的更改。

  5. 点击 Push origin 将这次“回退操作”推送到远程。

策略 B：强制回退（危险，使用 Reset）

原理：将分支指针直接移动到过去的某个节点，之后的提交记录会“消失”。如果其他人已经拉取了代码，这会导致严重冲突。 仅适合个人项目或你确定没人使用该项目时。 GitHub Desktop 的限制：为了安全，GitHub Desktop 的图形界面不支持直接对历史深处的提交进行 Reset --hard 操作。 解决方法（需配合命令行）：

  1. 在 GitHub Desktop 中，点击菜单栏 Repository -> Open in Terminal (或 Command Prompt)。
  2. 在弹出的命令行窗口中，输入以下命令（将 <commit-id> 替换为你想要回到的那个版本的哈希值）：
    1
2
3
4
5

    # 回退到指定版本，保留修改文件在本地
git reset --soft <commit-id>

# 或者：回退到指定版本，彻底丢弃之后的修改（极度危险）
git reset --hard <commit-id>
  3. 如果已经推送到远程，需要强制推送：
    1

    git push --force

场景四：只想恢复某个文件到历史版本

情况：整个项目不用回滚，只想把 config.js 恢复到昨天的版本。

操作步骤：

  1. 在 History 中找到包含该文件正确版本的那次提交。
  2. 在下方文件列表中找到该文件。
  3. 右键点击 该文件。
  4. 选择 View file at this commit（查看此提交时的文件）。
    • 注意：GitHub Desktop 目前没有直接的“还原此文件到该版本”的按钮。
  5. 你需要手动复制文件内容，覆盖掉你当前的文件，然后重新 Commit。
    • 进阶方法：如果熟悉命令行，在终端输入 git checkout <commit-id> -- <文件名> 会更快捷。

💡 最佳实践建议

为了避免频繁回滚带来的风险，建议养成以下习惯：

  1. 多建分支（Branch）：
    • 在开发新功能前，点击 Current Branch -> New Branch。
    • 在分支上开发，如果搞砸了，直接删除该分支即可，不影响主分支（main/master）。
  2. 小步提交：
    • 不要攒一大把代码再 Commit。每完成一个小功能就提交一次，这样回滚的粒度更细，风险更小。
  3. 推送前检查：
    • 在点击 Push origin 之前，务必在 History 里确认最后一次提交是正确的。一旦推送，回滚成本会变高。

总结：

  • 没提交：用 Discard changes。
  • 刚提交没推送：用 Undo commit。
  • 已推送：用 Revert commit（安全）或 命令行 Reset（危险）。
  • ⚠️upload failed, check dev console

git config 全局配置

1
2

git config --global pull.rebase true 
git config --global rebase.autostash true

配置后的效果说明

  1. pull.rebase true 生效表现

    GitHub Desktop 顶部的拉取按钮，会从默认的 Pull origin 自动变为 Pull origin with rebase。

    此后每次点击拉取，都会默认用 rebase 变基模式整合远程代码，而非 merge 合并，彻底避免生成无意义的 merge 提交，保持提交历史线性整洁。

  2. rebase.autostash true 生效表现

    当你有未提交的本地修改时执行拉取 / 变基操作，Git 会自动临时暂存你的改动，变基完成后自动恢复，无需你手动在 GitHub Desktop 里点击「Stash All Changes」，彻底解决「工作区不干净无法执行 rebase」的报错。

补充注意事项

  1. 仓库级别的配置会覆盖全局配置：如果某个仓库之前单独设置过 pull.rebase，需要进入仓库目录，执行 git config --unset pull.rebase 清除本地配置，全局规则才会生效。
  2. GitHub Desktop 虽自带内置 Git，但会优先读取用户目录下的全局 .gitconfig，上述配置方法完全兼容，不会出现不识别的问题。
  3. 变基会修改提交历史，仅对自己本地未推送到远程的提交使用，不要对已共享到远程的分支做变基，避免团队协作出现冲突。
comments powered by Disqus