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

git：指令集

news 来源：原创 2025/5/10 17:32:03

以下是对这些 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` （回退到指定提交）

作用：

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

三种模式：

--soft：保留工作区和暂存区的更改，仅回退提交记录。
```
git reset --soft HEAD~1  # 回退到上一个提交
```
--mixed（默认）：保留工作区的更改，但清空暂存区。
```
git reset HEAD~1
```
--hard：彻底回退，包括清空工作区的更改，无法恢复！
```
git reset --hard HEAD~1
```

常用操作：

回退到指定提交：

git reset --hard commit-hash**仅从暂存区移除文件**
git reset file.txt

注意：

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

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

作用：

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

与 reset 的区别：

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

用法：

撤销指定提交：
```
git revert commit-hash
```
批量撤销多个提交：
```
git revert commitA..commitB
```
自动跳过冲突提示：
```
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：修复提交历史

假设你误提交了错误内容：
```
git commit -m "Wrong changes"
```
使用 reset 回退到暂存区：
```
git reset HEAD~1
```

修改文件后重新提交：

git add file.txt
git commit -m "Correct changes"

案例 2：撤销错误的合并

假设最近一次合并出现问题：
```
git merge feature-branch
```
使用 revert 撤销合并：
```
git revert -m 1 commit-hash
```

案例 3：恢复误删的分支

假设你意外删除了分支：
```
git branch -d feature-branch
```
查找分支的最后一次操作记录：
```
git reflog
```
恢复分支：
```
git branch feature-branch commit-hash
```

案例 4：稀里糊涂丢了提交，如何恢复

假设你执行了以下命令丢失了更改：
```
git reset --hard HEAD~2
```
查找丢失的提交：
```
git reflog
```
恢复到丢失的提交：
```
git reset --hard commit-hash
```

命令	适用场景
`checkout`	切换分支、恢复文件、查看特定提交的文件内容。
`reset`	回退到某个提交，修改提交历史（慎用在已推送分支）。
`revert`	撤销特定提交的更改，生成新的提交（安全撤销）。
`reflog`	查看本地分支的所有操作记录，恢复被误删除或回退的提交。

`HEAD` 的作用

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

`HEAD` 的主要特性

指向当前分支的最新提交：
- 在分支上工作时，HEAD 通常指向该分支的名称，例如 main、dev 等。
- 例如：
```
HEAD -> main
```
- 这表示当前 HEAD 绑定到 main 分支，而 main 分支指向它的最新提交。
可临时指向特定提交：
- 如果使用 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

注意事项

分离状态的风险：
- 在分离状态中，如果你没有创建新分支，做的所有提交都可能丢失。
- 建议在需要继续工作的场景下，创建新分支：
```
git checkout -b temp-branch
```
与 HEAD 相关的误操作：
- 使用 git reset --hard 修改 HEAD 时，要谨慎操作，避免丢失工作区的更改。

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

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

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

为什么叫分离状态？

在分离状态下：

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

如何进入分离状态？

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

1. 检出一个具体的提交

git checkout commit-hash

这会让 HEAD 指向指定的提交，而不是当前分支的最新提交。

2. 检出一个标签（Tag）

git checkout v1.0.0

标签通常指向一个具体的提交，检出标签也会导致 HEAD 分离。

3. 检出远程分支未合并的提交

git checkout origin/feature-branch

如果本地没有该分支，直接检出远程分支的提交也会导致分离状态。

分离状态下会发生什么？

查看代码是安全的：
- 你可以安全地查看指定提交的代码，不会对其他分支造成影响。
提交的更改可能丢失：
- 如果你在分离状态下修改代码并提交：
```
git commit -m "Work in detached HEAD"
```
  这些更改不会自动关联到任何分支，可能导致提交变得“孤立”。
你需要创建新分支保存工作：
- 如果不想丢失提交，需要创建一个新分支：
```
git checkout -b new-branch
```

分离状态的工作流程

例子：检出历史提交

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

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

你运行以下命令：

git checkout B

此时：

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

结果：

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

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

git commit -m "New commit"

提交历史会变成这样：

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

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

解决孤立提交：

如果你想保留提交 E，需要创建一个新分支：
```
git checkout -b temp-branch
```
新分支 temp-branch 会指向提交 E，保留你的工作。
如果你直接切换到其他分支而没有保存，提交 E 会被垃圾回收机制清理掉。

如何离开分离状态？

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

git checkout main

分离状态的注意事项

分离状态适合以下场景：
- 检查代码在特定历史版本中的状态。
- 调试某个历史提交。
- 基于某个历史提交开始新的开发。
不适合长期工作：
- 因为分离状态的更改不被分支记录，很容易导致工作丢失。

总结

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

1. git switch 和 git restore

2. git worktree

3. git sparse-checkout

4. git range-diff

5. git maintenance

6. git log --remerge-diff

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

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

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

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

完整操作案例

案例 1：修复提交历史

案例 2：撤销错误的合并

案例 3：恢复误删的分支

案例 4：稀里糊涂丢了提交，如何恢复

HEAD 的作用

HEAD 的主要特性

HEAD 的作用和常见场景

1. 检出分支

2. 回退提交

3. 查看历史提交

4. 分离 HEAD 状态（Detached HEAD）

5. 临时恢复文件

6. 参考点操作

HEAD 的常见使用示例

场景 1：快速回到最新提交

场景 2：撤销最近一次提交，但保留工作区更改

场景 3：回退到分支的某个历史状态

场景 4：对比当前工作区和最新提交的差异

场景 5：恢复文件到上次提交的状态

场景 6：创建分支基于特定提交

注意事项

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

为什么叫分离状态？

如何进入分离状态？

1. 检出一个具体的提交

2. 检出一个标签（Tag）

3. 检出远程分支未合并的提交

分离状态下会发生什么？

分离状态的工作流程

例子：检出历史提交

解决孤立提交：

如何离开分离状态？

分离状态的注意事项

总结

相关文章：

1. `git switch` 和 `git restore`

2. `git worktree`

3. `git sparse-checkout`

4. `git range-diff`

5. `git maintenance`

6. `git log --remerge-diff`

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

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

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

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

`HEAD` 的作用

`HEAD` 的主要特性

`HEAD` 的作用和常见场景

4. 分离 `HEAD` 状态（Detached HEAD）

`HEAD` 的常见使用示例