当前位置： 首页 > article >正文

git：指令集

article 2025/1/6 7:19:19

以下是对这些 Git 新特性和命令的更详细解读和实际用例分析，帮助更好地理解它们的作用及适用场景：

1. git switch 和 git restore

背景：

  • 传统上，git checkout 是一个多功能命令，用于切换分支、检出文件、创建分支等，但其用途过于复杂，容易导致混淆。

新命令：

  • git switch：专注于切换分支。

    • 用法：
      git switch branch-name  # 切换到指定分支
git switch -c new-branch-name  # 创建并切换到新分支
    • 优点：避免因误用 git checkout 导致的文件检出错误。

  • git restore：专注于还原文件的修改。

    • 用法：
      git restore file.txt  # 恢复工作目录中的指定文件
git restore --staged file.txt  # 从暂存区移除文件的更改
    • 优点：明确分工，降低误操作的风险。

2. git worktree

背景：

  • 需要在一个仓库中同时处理多个分支时，频繁切换分支效率低，且可能导致未提交修改的丢失。

功能：

  • 允许在同一仓库中创建多个工作目录，每个目录可以检出不同的分支或提交。

用法：

git worktree add ../path-to-new-worktree branch-name  # 创建新工作目录并检出分支
git worktree list  # 列出所有工作目录
git worktree remove ../path-to-new-worktree  # 删除指定的工作目录

场景：

  • 同时开发多个功能或修复多个问题，避免频繁切换分支或克隆多个仓库。

3. git sparse-checkout

背景：

  • 在处理大型代码仓库时，检出所有文件可能导致资源浪费或加载缓慢。

功能：

  • 支持稀疏检出，仅检出特定的文件或目录。

用法：

git sparse-checkout init  # 初始化稀疏检出模式
git sparse-checkout set path/to/folder  # 设置稀疏检出的目录
git sparse-checkout add another/folder  # 添加更多目录到稀疏检出范围

场景：

  • 大型单体仓库（monorepo）开发中，仅需特定模块代码时。

4. git range-diff

背景：

  • 在变基或合并多个提交后，理解提交的差异和变化会变得复杂。

功能：

  • 对比两个提交范围的差异，帮助理解提交在变基或历史改写后的具体变化。

用法：

git range-diff upstream..HEAD feature-branch  # 比较两个范围的差异

场景：

  • 代码审查过程中，分析变基后提交历史的变化。

5. git maintenance

背景：

  • 长期使用的仓库可能会出现性能问题，需要定期维护。

功能：

  • 提供自动化的维护任务，如压缩对象、优化文件等。

用法：

git maintenance run  # 立即运行维护任务
git maintenance start  # 启用后台维护
git maintenance stop  # 停止后台维护

场景：

  • 在持续集成环境中，保持仓库高效性能。

6. git log --remerge-diff

背景：

  • 在调试复杂的合并历史时，需要了解某次合并引入的确切更改。

功能：

  • 重建合并提交，显示其引入的差异。

用法：

git log --remerge-diff

场景：

  • 代码审查中，详细分析复杂合并带来的具体更改。

这些新命令和特性各自解决了开发流程中的实际痛点，大幅提升了 Git 的易用性和效率。在日常使用中，以下是常见组合：

  • 使用 git switch 和 git restore 替代 git checkout。
  • 在大型项目中，结合 git worktree 和 git sparse-checkout 提高开发效率。
  • 使用 git maintenance 和 git log --remerge-diff 优化仓库性能和代码审查。

是 Git 的核心操作，用于处理分支切换、回退、更改历史记录以及查看操作记录等功能。以下是它们的作用和具体使用场景：

7. git checkout （切换分支或检出文件）

场景 1：切换分支

# 切换到现有分支 "feature-branch"
git checkout feature-branch

场景 2：创建并切换到新分支

# 创建新分支 "new-feature" 并切换到该分支
git checkout -b new-feature

场景 3：恢复文件

# 恢复文件 "app.js" 到上一次提交的状态
git checkout HEAD app.js

# 从其他分支检出某个文件
git checkout dev -- app.js

注意：

  • git checkout 功能繁多，可能导致误用，因此从 Git 2.23 开始，切换分支和检出文件的功能被拆分为 git switch 和 git restore。

8. git reset （回退到指定提交）

作用：

  • 主要用于撤销提交或重置文件的状态。

三种模式：

  1. --soft：保留工作区和暂存区的更改，仅回退提交记录。

    git reset --soft HEAD~1  # 回退到上一个提交

  2. --mixed（默认）：保留工作区的更改，但清空暂存区。

    git reset HEAD~1

  3. --hard：彻底回退，包括清空工作区的更改，无法恢复！

    git reset --hard HEAD~1

常用操作：

  • 回退到指定提交：
    git reset --hard commit-hash

**仅从暂存区移除文件**
git reset file.txt

注意：

  • reset 会修改提交历史，可能导致数据丢失，不适合已推送的分支。

9. git revert （撤销特定提交）

作用：

  • 创建一个新的提交来反向应用某次提交的更改。

与 reset 的区别：

  • revert 是安全操作，不会修改提交历史，适合已推送的分支。

用法：

  1. 撤销指定提交：

    git revert commit-hash

  2. 批量撤销多个提交：

    git revert commitA..commitB

  3. 自动跳过冲突提示：

    git revert commit-hash --no-edit

场景：

  • 修复已推送的错误提交。
  • 撤销特定功能或 Bug 修复。

10. git reflog （查看历史操作记录）

场景 1：查看所有操作记录

git reflog
  • 输出示例：
    abc1234 (HEAD -> main) HEAD@{0}: reset: moving to HEAD~1
def5678 HEAD@{1}: commit: Fix a bug
ghi9012 HEAD@{2}: checkout: moving from feature to main

场景 2：恢复误删分支

# 假设分支被删除，找到分支最后一次操作的 commit-hash
git reflog

# 创建分支恢复到误删位置
git branch recovered-branch abc1234

场景 3：恢复误用 reset --hard 丢失的提交

# 找到丢失的提交的 commit-hash
git reflog

# 回退到该提交
git reset --hard commit-hash

完整操作案例

案例 1：修复提交历史
  1. 假设你误提交了错误内容：
    git commit -m "Wrong changes"
  2. 使用 reset 回退到暂存区：
    git reset HEAD~1
  3. 修改文件后重新提交：
    git add file.txt
git commit -m "Correct changes"
案例 2：撤销错误的合并
  1. 假设最近一次合并出现问题：
    git merge feature-branch
  2. 使用 revert 撤销合并：
    git revert -m 1 commit-hash
案例 3：恢复误删的分支
  1. 假设你意外删除了分支：
    git branch -d feature-branch
  2. 查找分支的最后一次操作记录：
    git reflog
  3. 恢复分支：
    git branch feature-branch commit-hash
案例 4：稀里糊涂丢了提交，如何恢复
  1. 假设你执行了以下命令丢失了更改：
    git reset --hard HEAD~2
  2. 查找丢失的提交：
    git reflog
  3. 恢复到丢失的提交：
    git reset --hard commit-hash
命令适用场景
checkout切换分支、恢复文件、查看特定提交的文件内容。
reset回退到某个提交，修改提交历史（慎用在已推送分支）。
revert撤销特定提交的更改，生成新的提交（安全撤销）。
reflog查看本地分支的所有操作记录，恢复被误删除或回退的提交。

HEAD 的作用

HEAD 是 Git 中的一个特殊的指针，它始终指向当前活动分支的最新提交。可以理解为 Git 用来追踪“当前工作位置”的标记。通过操作 HEAD，我们可以切换分支、回退提交、检出历史版本等。

HEAD 的主要特性

  1. 指向当前分支的最新提交：

    • 在分支上工作时，HEAD 通常指向该分支的名称，例如 main、dev 等。
    • 例如：
      HEAD -> main
    • 这表示当前 HEAD 绑定到 main 分支，而 main 分支指向它的最新提交。

  2. 可临时指向特定提交：

    • 如果使用 git checkout 检出一个历史提交，HEAD 会处于“分离状态”（detached HEAD），直接指向该提交的哈希值，而不再绑定到某个分支。

HEAD 的作用和常见场景

1. 检出分支
  • 当切换到某个分支时，HEAD 更新为指向该分支的最新提交。
git checkout main
  • 此时，HEAD -> main，表示当前工作目录的内容基于 main 分支。
2. 回退提交
  • 使用 git reset 时，HEAD 可以移动到历史的某个提交。
git reset --hard HEAD~1
  • 此操作将 HEAD 指针向回移动一位，同时更新当前分支。
3. 查看历史提交
  • 通过 HEAD 指向的提交哈希值，可以检出历史版本。
git checkout HEAD~2  # 检出当前分支的前两次提交
  • 此时，HEAD 处于分离状态。
4. 分离 HEAD 状态（Detached HEAD）
  • 如果 HEAD 不再指向分支，而是直接指向某个提交哈希值，就进入了分离状态：
git checkout commit-hash
  • 此时的 HEAD：
    HEAD detached at commit-hash
  • 分离状态常用于查看历史版本或基于某次提交新建分支。
5. 临时恢复文件
  • 使用 HEAD 恢复工作区文件到最新提交状态：
git checkout HEAD -- file.txt
  • 该命令会将 file.txt 恢复到当前提交时的状态。
6. 参考点操作

HEAD 作为当前分支的参考点，可用于多种操作：

命令描述
HEAD~1当前提交的父提交。
HEAD~2当前提交的祖父提交。
HEAD^当前提交的第一个父提交（等价于 HEAD~1）。
HEAD^2当前提交的第二个父提交（用于合并提交）。
HEAD@{n}当前分支的 reflog 中第 n 次变更位置。

HEAD 的常见使用示例

场景 1：快速回到最新提交
  • 如果你临时查看了历史提交，想返回最新的提交：
git checkout main
场景 2：撤销最近一次提交，但保留工作区更改
git reset HEAD~1
场景 3：回退到分支的某个历史状态
git reset --hard HEAD~3
场景 4：对比当前工作区和最新提交的差异
git diff HEAD
场景 5：恢复文件到上次提交的状态
git checkout HEAD -- file.txt
场景 6：创建分支基于特定提交
  • 假设当前 HEAD 在分离状态，想基于它创建新分支：
git checkout -b new-branch

注意事项

  1. 分离状态的风险：

    • 在分离状态中，如果你没有创建新分支，做的所有提交都可能丢失。
    • 建议在需要继续工作的场景下，创建新分支：
      git checkout -b temp-branch

  2. 与 HEAD 相关的误操作：

    • 使用 git reset --hard 修改 HEAD 时，要谨慎操作，避免丢失工作区的更改。

什么是分离状态（Detached HEAD）？

通常情况下，HEAD 是指向一个分支的，比如 main 或 feature-branch。当你在某个分支上工作时，HEAD 会跟踪该分支的最新提交。

但是，当你检出（checkout）一个具体的提交哈希值，而不是分支名时，HEAD 就直接指向该提交，而不是分支。这就是所谓的“分离状态”。

为什么叫分离状态？

在分离状态下：

  1. HEAD 不再跟踪任何分支，而是直接指向某个具体的提交。
  2. 你可以查看或修改代码，但这些更改不会被关联到任何分支上，除非你创建一个新的分支。

如何进入分离状态？

分离状态通常发生在以下情况下：

1. 检出一个具体的提交
git checkout commit-hash
  • 这会让 HEAD 指向指定的提交，而不是当前分支的最新提交。
2. 检出一个标签（Tag）
git checkout v1.0.0
  • 标签通常指向一个具体的提交，检出标签也会导致 HEAD 分离。
3. 检出远程分支未合并的提交
git checkout origin/feature-branch
  • 如果本地没有该分支，直接检出远程分支的提交也会导致分离状态。

分离状态下会发生什么？

  1. 查看代码是安全的：

    • 你可以安全地查看指定提交的代码，不会对其他分支造成影响。

  2. 提交的更改可能丢失：

    • 如果你在分离状态下修改代码并提交：
      git commit -m "Work in detached HEAD"
      这些更改不会自动关联到任何分支，可能导致提交变得“孤立”。

  3. 你需要创建新分支保存工作：

    • 如果不想丢失提交，需要创建一个新分支：
      git checkout -b new-branch

分离状态的工作流程

例子：检出历史提交

假设当前分支是 main，它的提交历史如下：

A -> B -> C -> D (HEAD, main)

你运行以下命令：

git checkout B

此时：

  1. HEAD 会直接指向提交 B。
  2. main 分支仍然指向提交 D。
  3. 工作区的代码被恢复为提交 B 的状态。

结果：

A -> B (HEAD) -> C -> D (main)

如果你在这个状态下修改文件并提交：

git commit -m "New commit"

提交历史会变成这样：

A -> B -> E (HEAD) -> C -> D (main)

注意： 提交 E 不属于任何分支，是孤立的。

解决孤立提交：

  1. 如果你想保留提交 E，需要创建一个新分支：

    git checkout -b temp-branch

    新分支 temp-branch 会指向提交 E，保留你的工作。

  2. 如果你直接切换到其他分支而没有保存，提交 E 会被垃圾回收机制清理掉。

如何离开分离状态？

如果你不打算保留分离状态下的任何修改，可以直接切换回分支：

git checkout main

分离状态的注意事项

  • 分离状态适合以下场景：

    • 检查代码在特定历史版本中的状态。
    • 调试某个历史提交。
    • 基于某个历史提交开始新的开发。

  • 不适合长期工作：

    • 因为分离状态的更改不被分支记录，很容易导致工作丢失。

总结

当你在分离状态下，HEAD 不再绑定到某个分支，而是直接指向某个提交。虽然你可以修改和提交代码，但这些提交是孤立的，必须创建新分支来保存。分离状态通常用于查看或临时操作历史版本，但需要注意保存工作，以免丢失更改。


http://www.kler.cn/a/465506.html

相关文章：

  • 成都和力九垠科技有限公司九垠赢系统Common存在任意文件上传漏洞
  • 形象地理解UE4中的数据结构 TLinkedListBase
  • 离散数学 期末笔记
  • YIG带通滤波器
  • 本地测试文件解析
  • Niushop商城商业插件_cps联盟_包装转换_视频购物_同城配送_上门预约等插件的安装方法
  • ICP备案（阿里云等）
  • html+css网页设计 美食 美食模版1个页面
  • 面试手撕笔记ML/DL
  • 教程：从pycharm基于anaconda构建机器学习环境并运行第一个 Python 文件
  • 【UE5 C++课程系列笔记】19——通过GConfig读写.ini文件
  • 网络原理之TCP和UDP
  • Java-多种方法实现多线程卖票
  • 在mac上通过Vundle安装YouCompleteMe(YCM)
  • LeetCode题练习与总结：超级洗衣机--517
  • vue，使用unplugin-auto-import避免反复import，按需自动引入
  • Dpath之详解（Detailed Explanation of Dpath）
  • 借助 FinClip 跨端技术探索鸿蒙原生应用开发之旅
  • spring boot IDEA启动两个端口服务nginx负载
  • 如何使用Python自动化发送消息：用pynput库批量输入并发送文本
  • 网络安全：交换机技术
  • leetcode 面试经典 150 题：多数元素
  • 工信部电子标准院计算机视觉证书报考指南！
  • 项目引入MybatisPlus
  • npm提示Install fail! Error_ EBUSY_ resource busy or
  • STM32G431收发CAN