`git restore` 和 `git checkout` 用于丢弃工作区的改动， `git switch` 和 `git checkout` 用来切换分支

git_restore__git_checkout__0">`git restore` 和 `git checkout` 都可以用于丢弃工作区的改动

但它们有一些区别，尤其是在 Git 2.23 引入了新的命令后。

主要区别

git checkout 是一个多用途命令：
- 它用于切换分支。
- 它还可以用于恢复工作区中特定文件的更改。
- 由于功能过于复杂，Git 社区决定简化和分离其功能。
git restore 是一个更专门的命令：
- 它专门用于恢复文件或丢弃工作区的改动，让操作更具可读性和直观性。
- 它不会影响分支切换，只处理工作区和暂存区的文件恢复相关操作。

两者的用途对比

命令	功能描述
`git checkout <文件>`	丢弃文件的本地改动，并恢复到最近的提交状态（同时也用于分支切换，功能混合）。
`git restore <文件>`	丢弃文件的本地改动，仅用于恢复文件，不涉及分支切换。
`git checkout <分支>`	切换到某个分支，并更新工作区内容为该分支的最新提交。
`git restore --source <提交> <文件>`	从指定的提交中恢复文件，恢复到工作区。
`git restore --staged <文件>`	丢弃暂存区的改动（类似于 `git reset HEAD <文件>`），将暂存区改动恢复到工作区。

典型使用场景

git checkout 的典型场景：
- 切换分支：git checkout main
- 丢弃某个文件的改动：git checkout <文件>
git restore 的典型场景：
- 丢弃工作区改动，恢复文件：git restore <文件>
- 丢弃暂存区改动（取消 git add）：git restore --staged <文件>
- 从某个提交恢复文件：git restore --source=<提交哈希> <文件>

git_restore_34">为什么引入 `git restore`？

在 Git 2.23 之前，git checkout 的用途广泛，但这也导致命令功能复杂，不直观。为了解决这一问题，Git 开发者引入了两个新的命令来更明确地分离功能：

git restore：用于恢复或丢弃文件的改动（工作区和暂存区）。
git switch：用于切换分支。

通过这两个更明确的命令，Git 操作变得更清晰、易于理解。

总结

git checkout：可以切换分支或丢弃文件的改动，但功能较为复杂。
git restore：专门用于恢复文件的内容，操作更直观，推荐在恢复文件时使用。

因此，建议使用 git restore 来丢弃工作区的改动，因为它的功能更明确，语义更加清晰。

git_switch__git_checkoutGit49">`git switch` 和 `git checkout` 都是 Git 中用来切换分支的命令

Git 在 2.23 版本中引入了 git switch 命令，以简化和明确分支切换的操作。下面是它们的主要区别：

1. 目的更明确

git checkout 是一个多用途命令，它不仅用于切换分支，还可以用于切换到某个特定的提交（commit），或者将工作区文件恢复到某个特定的状态。
git switch 专门设计用于切换分支，它简化了 git checkout 切换分支的操作，避免了误用和歧义。

git_switch__56">2. `git switch` 更专注于分支操作

git checkout：
- 可以切换到一个分支，也可以切换到某个提交（没有分支）。
- 还可以用于恢复工作区文件。
- 由于 git checkout 有多个功能，容易导致误用。例如，当用户想切换分支时，如果输入了错误的分支名，它可能导致切换到一个孤立的 commit（非分支）。
git switch：
- 只用于分支切换，不会涉及其他功能（例如恢复文件）。
- 更加直观和简单，防止用户误操作。

3. 具体的使用场景

git_checkout__67">`git checkout` 的常见使用方式：

git checkout <branch-name>  # 切换到分支
git checkout <commit-hash>  # 切换到某个提交的状态（"分离 HEAD" 状态）
git checkout -- <file>      # 恢复工作区文件到暂存区或特定版本的状态

git_switch__74">`git switch` 的常见使用方式：

git switch <branch-name>    # 切换到分支
git switch -c <new-branch>  # 创建并切换到一个新的分支

4. 创建新分支的方式

git checkout 创建并切换到新分支的命令：
```
git checkout -b <new-branch>
```
git switch 创建并切换到新分支的命令：
```
git switch -c <new-branch>
```

5. 分离 `HEAD` 状态

git checkout 可以切换到某个特定的提交，这样会进入“分离 HEAD”状态：
```
git checkout <commit-hash>
```
git switch 默认情况下不会让你进入分离 HEAD 状态。如果需要进入分离 HEAD，你需要显式使用 --detach 选项：
```
git switch --detach <commit-hash>
```

6. 避免误操作

由于 git checkout 的多功能性，新手在切换分支时有时可能会误切换到某个提交或者使用错误的操作方式。git switch 通过限制其功能，只专注于分支切换，减少了这种混淆。

总结

git checkout：多功能的命令，既可以切换分支，又可以切换到某个提交，还可以用于恢复文件。
git switch：专注于分支切换，更加直观和明确，减少误操作。

推荐在处理分支时使用 git switch，而使用 git checkout 处理文件恢复或其他复杂的操作。

git_checkout__113">检出特定的提交快照，可以使用 `git checkout` 命令。

在这里插入图片描述

检出指定的提交快照：
```
git checkout 9b69c9a
```
这将使你的工作目录处于提交 9b69c9a 的状态。注意，检出提交的方式会将你置于一个“分离头指针”（detached HEAD）状态，这意味着你并不在某个分支上，而是直接检出了一个历史提交。
如果你需要继续在该快照的基础上进行开发，可以创建一个新的分支：
```
git checkout -b <新分支名>
```

例如：

git checkout -b old_snapshot

这将会在 9b69c9a 提交的基础上创建一个新的分支，允许你在该分支上继续开发。如果你只是想临时查看某个提交，git checkout 是一个合适的选择，但要小心在“分离头指针”状态下进行开发。

总结

使用 git checkout <提交ID> 检出历史提交。
如果要继续开发，建议创建新分支。

git_switch__git_restore__git_checkout__140">在 Git 的较新版本中，`git switch` 和 `git restore` 被引入作为替代命令，以提供更清晰的操作方式，替代一些 `git checkout` 的功能。

git_switch_142">1. git switch

git switch 主要用于在分支之间切换，替代了 git checkout <分支名> 的功能。

切换到一个已有的分支：
```
git switch <分支名>
```
创建并切换到一个新分支：
```
git switch -c <新分支名>
```

但需要注意的是，git switch 不能直接用来检出特定的提交。如果你想检出一个历史提交，还是需要使用 git checkout 或 git restore。

git_restore_156">2. git restore

git restore 是 Git 新版本中的另一个替代命令，用于恢复工作目录中的文件或者工作区的某些状态。

恢复单个文件到某个提交时的状态：
```
git restore --source=<提交ID> <文件名>
```
如果你想检出整个工作目录的特定快照，可以使用：
```
git restore --source=<提交ID> .
```

检出特定提交的推荐做法

虽然 git switch 不能用于检出特定的提交，但是你可以使用 git restore 来实现类似功能，或者继续使用 git checkout：

使用 git restore：
```
git restore --source=<提交ID> .
```
继续使用 git checkout 检出特定提交：
```
git checkout <提交ID>
```

在新版本的 Git 中，虽然 git checkout 仍然有效，但 git switch 和 git restore 提供了更明确的分工，减少了 git checkout 的多重用法带来的混淆。

git_restore__184">`git restore` 需要你指定要恢复的路径或文件。

在使用 git restore --source=<提交ID> 时，必须明确告诉 Git 你要恢复哪些文件或整个工作目录。

如果你想恢复整个工作目录到特定提交的状态，可以使用 . 代表当前目录的所有文件，完整的命令应该是：

git restore --source=9b69c9a2b1130e0b408ba9a8caaf62fbd9dab03f .

此命令会将当前工作目录恢复到 9b69c9a2b1130e0b408ba9a8caaf62fbd9dab03f 这个提交的状态。

注意事项：

该命令不会移动当前分支的指针，也不会修改 HEAD 的位置。如果你想回到这个提交并进行进一步开发，你可能还需要创建一个新分支。

如果你需要检出整个提交（不仅仅是文件的状态），可以考虑继续使用 git checkout <提交ID> 进行操作，然后根据需要创建分支：

git checkout 9b69c9a2b1130e0b408ba9a8caaf62fbd9dab03f

这会把你的工作目录恢复到该提交，并进入“分离头指针”（detached HEAD）状态。如果你想在这个提交的基础上继续开发，建议立即创建新分支：

git checkout -b <新分支名>

“分离头指针”（detached HEAD）状态

“分离头指针”（detached HEAD）状态是指当你在 Git 中检出一个特定的提交而不是一个分支时，Git 会进入这一特殊状态。它意味着你的工作目录已经指向了某个具体的提交，而不是分支的最新提交。这种状态下，你的 HEAD 不再指向某个分支，而是指向某个提交的哈希值。

举个例子：

当你使用 git checkout <提交ID> 检出一个特定的提交时，例如：

git checkout 9b69c9a2b1130e0b408ba9a8caaf62fbd9dab03f

此时，Git 不会让 HEAD 指向一个分支（如 main 或 develop），而是直接指向这个提交 9b69c9a2b1130e0b408ba9a8caaf62fbd9dab03f。这就是“分离头指针”状态。

在“分离头指针”状态下做什么？

你可以查看代码、运行代码、测试代码等。
你可以进行更改并创建提交，但这些提交不会关联到任何分支。
如果你继续提交，除非你创建了一个新的分支保存这些提交，否则你将很难找到这些提交，因为它们不属于任何分支。

如何在“分离头指针”状态下工作？

检出特定提交：
你可以检出历史中的任何提交，如：
```
git checkout <提交ID>
```
现在你处于“分离头指针”状态。
继续工作并保存进度：
如果你希望基于这个状态继续开发，你应该立即创建一个新分支，将你的工作保存到一个分支上：
```
git checkout -b <新分支名>
```
这会创建一个新的分支并将你的 HEAD 指向该分支，避免丢失你未来的工作。
丢弃临时工作：
如果你在“分离头指针”状态下进行了一些实验性工作，但并不想保存，可以通过切换回其他分支来丢弃这些更改：
```
git switch <分支名>
```
或者使用 git checkout <分支名> 切换回某个分支。

“分离头指针”状态的常见用途：

查看历史提交：你可以临时检出某个历史提交来查看旧的代码状态或进行调试。
调试或实验：在临时状态下做一些实验性的更改，之后可以决定是否保留这些更改。
基于特定提交创建新分支：当你发现一个历史提交很重要或你想基于它继续开发时，可以检出该提交并创建一个新的分支。

注意事项：

如果你在“分离头指针”状态下进行了提交，而没有创建新分支，那么这些提交将变得不容易找到，因为它们不会在任何分支的历史记录中。如果你切换到另一个分支，分离头指针下的提交可能会被垃圾回收（GC）删除。

总结：

“分离头指针”状态意味着 HEAD 指向某个特定提交，而不是分支。
可以在此状态下进行查看、测试、修改代码，但如果想保存进度，应尽快创建新分支。
未保存的工作在离开此状态时可能会丢失。