Git常见操作

一、速查表格

命令	作用
git add <文件名>	将文件添加到暂存区，可以使用 `.` 将所有修改的文件添加
git commit -m “提交信息”	将暂存区的文件提交到本地仓库
git branch -d <分支名>	删除本地分支，使用 `-D` 强制删除
git switch -c <新分支名	基于当前分支创建新分支并切换
git stash	临时保存当前未提交的更改
git stash pop	将暂存的更改恢复到工作目录
git fetch	从远程仓库获取最新的提交、分支和标签信息
git rm -r --cached <文件夹路径>	将指定文件夹从 Git 跟踪中删除，但保留本地文件夹
git push origin <分支名>	推送代码到远程仓库
git push origin --delete <分支名>	删除远程仓库指定分支

二、常见操作

以下是一些常见的 Git 操作及其用途：

1. 配置 Git 用户信息

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

2. 初始化仓库

git init

在当前目录下初始化一个新的 Git 仓库。

3. 克隆仓库

git clone <仓库地址>

从远程仓库克隆一个项目到本地。

4. 查看当前状态

git status

显示工作目录和暂存区的状态，查看哪些文件被修改或准备提交。

5. 添加文件到暂存区

git add <文件名>

将文件添加到暂存区，可以使用 . 将所有修改的文件添加。

6. 提交更改

git commit -m "提交信息"

将暂存区的文件提交到本地仓库。

7. 查看提交记录

git log

显示提交历史，git log --oneline 简化输出。

8. 创建分支

git branch <分支名>

创建一个新的分支。

9. 切换分支

git checkout <分支名>

切换到指定分支。

10. 合并分支

git merge <分支名>

将指定分支的更改合并到当前分支。

11. 删除分支

git branch -d <分支名>

删除本地分支，使用 -D 强制删除。

12. 推送代码到远程仓库

git push origin <分支名>

将本地分支的更改推送到远程仓库。

13. 拉取远程仓库的更改

git pull

获取并合并远程仓库的更改。

14. 克隆特定分支

git clone -b <分支名> <仓库地址>

克隆远程仓库中特定的分支。

15. 创建并切换到新分支

git checkout -b <分支名>

创建并直接切换到新的分支。

16. 暂存更改（stash）

git stash

临时保存当前未提交的更改。

17. 恢复暂存的更改

git stash pop

将暂存的更改恢复到工作目录。

18. 重置本地修改

git reset --hard

将所有本地修改的文件恢复到上次提交时的状态。

19. 查看远程仓库

git remote -v

显示当前配置的远程仓库地址。

20. 添加远程仓库

git remote add origin <仓库地址>

将远程仓库地址添加到本地仓库。

三、进阶用法

1. 合并最近两次提交

方式一 `rebase`

Step1 启动交互式 rebase
运行以下命令进入交互式 rebase 界面：

git rebase -i HEAD~2git rebase -i 要保留的前一个CommitIDgit rebase -i 要保留的CommitID^

HEAD~2 表示要操作最近的两次提交。

Step2 修改 pick 为 squash（或 fixup）
在文本编辑器中，会显示类似如下的两行：

pick <commit-hash-1> First commit message
pick <commit-hash-2> Second commit message

fixup 或 squash（两者都用于合并提交，但 squash 会保留合并提交的日志消息，而 fixup 会丢弃它，只保留第一个提交的日志消息）

将第二行的 pick 改为 squash（或简写 s），如下所示：

pick <commit-hash-1> First commit message
squash <commit-hash-2> Second commit message

这会将第二次提交合并到第一次提交。

Step3 编辑提交信息
保存并退出编辑器后，Git 会要求你编辑合并后的提交信息。你可以保留或修改提交信息，然后保存并退出。

Step4 推送更改
如果你已经将这些提交推送到远程仓库，并且想要同步这些更改，需要使用 --force（或简写 -f）推送：

git push origin <分支名> --force

方式二 `reset`

提交历史如下：

提交5 CommitHash5提交5信息提交4 CommitHash4提交4信息提交3 CommitHash3提交3信息提交2 CommitHash2提交2信息提交1 CommitHash1提交1信息

需求是将提交3、提交4、提交5合并为一个提交
Step1 执行回退
先将版本回退到提交且在回退时保留工作区的变动

git reset CommitHash2

Step2 提交代码

git add 需要提交的文件
git commit "新的提交信息"

四、指令详解

1. git reset

1.1 基本作用

git reset 是 Git 中非常强大的命令，用于将当前分支的提交历史、暂存区（staging area）或工作目录（working directory）重置为指定的状态。它主要有以下几种作用：

①重置提交历史（改变分支指向）
git reset 可以改变当前分支的 HEAD 指向到某个特定的提交。这意味着它可以取消某些提交，将分支指向之前的某个提交。

②修改暂存区
通过 git reset，你可以将某些文件从暂存区（staging area）中移除，但这些文件的内容不会被修改。这在你已经 git add 了文件，但想撤销这个操作时非常有用。

③修改工作目录
git reset 也可以更改工作目录中的文件状态，将文件恢复到之前的状态（即删除未提交的修改）。

1.2 操作模式

git reset 有三种常用模式，主要区别在于它们对 提交历史、暂存区 和 工作目录 的影响：

git reset --soft <commit>
- 提交历史: 重置到指定提交，保留所有修改（提交记录指向更早的一个提交）。
- 暂存区: 保留所有文件的变化，文件仍保持在暂存区中。
- 工作目录: 工作目录不变，所有文件修改依然保留。
用途：撤销最近的提交，但保留代码和暂存的文件。

   git reset --soft HEAD~1  # 撤销最近的一次提交

git reset --mixed <commit>（默认模式）
- 提交历史: 重置到指定提交。
- 暂存区: 暂存区会重置为指定提交的状态，取消 git add 的文件。
- 工作目录: 保留工作目录中的修改，代码仍然存在。
用途：撤销最近的提交，并将文件从暂存区中移除，但保留修改。

git reset --mixed HEAD~1

git reset --hard <commit>
- 提交历史: 重置到指定提交。
- 暂存区: 暂存区会重置为指定提交的状态。
- 工作目录: 工作目录也会重置到指定提交的状态（所有未提交的修改都会丢失）。
用途：彻底重置分支，丢弃所有本地的修改和提交。

   git reset --hard HEAD~1

1.3 用法场景

撤销最近的提交：如果你刚提交了某些更改，但意识到有问题，可以使用 git reset --soft 或 --mixed 来撤销提交，保留代码。
修改暂存区：如果你用 git add 暂存了一些文件，但后来不想提交它们，可以使用 git reset <file> 将文件从暂存区移出。
完全重置到某个提交：如果你想丢弃所有未提交的更改并回到之前的某个状态，可以使用 git reset --hard。

1.4 注意事项

--hard 模式会丢失所有未提交的更改，所以在使用前一定要谨慎，确保这些改动不是你想保留的。
git reset 会修改提交历史，特别是当你已经将提交推送到远程仓库时，使用 reset 可能会造成团队协作问题。

2. git rebase

git rebase 是 Git 中用于重写提交历史的强大工具，主要用来将一个分支的更改“移动”到另一个分支的基础之上。它通常用于保持线性的提交历史，避免频繁出现分支合并时的 “merge commit”。

2.1 基本原理

git rebase 的基本思想是：

将一系列提交从一个基底上“复制”下来。
再将这些提交“应用”到另一个基底上。

假设有两个分支，feature 和 main，你想将 feature 的工作“重新定位”到 main 的最新提交之上，这时就可以使用 git rebase。

2.2 应用场景

将分支变基到另一分支上
交互式 rebase 用于修改历史
处理冲突与 rebase 的作用

2.3 基本的rebase

将分支变基到另一分支上
最常见的用法是将一个分支的更改移动到另一个分支的最新状态之上。例如，你正在 feature 分支开发，而 main 分支有了新的更新，你希望将 feature 分支的工作基于最新的 main 分支。

git checkout feature       # 切换到 feature 分支
git rebase main            # 将 feature 分支变基到 main 分支

发生的过程：

Git 会“摘下” feature 分支的所有提交，将它们暂存起来。
然后，Git 会将 feature 分支“移动”到 main 分支的最新提交。
最后，Git 会把 feature 分支之前的那些提交一个一个地重新应用在新的基底之上。

这种操作相当于“更新”了 feature 分支，基于 main 最新的代码，且不产生额外的合并提交。

2.4 交互式rebase

git rebase -i（交互式 rebase）允许你对一系列提交进行更复杂的操作，如修改、删除、合并提交等。这对整理提交历史非常有用。

git rebase -i <commit>

交互式 Rebase 操作的常见步骤：

选择要操作的提交：git rebase -i 会打开一个编辑器，显示一系列提交。每行代表一个提交，并带有一个操作命令。

示例：
```
pick 3a1c5d7 Fix bug A
pick 4b6f7d8 Add feature X
pick 9b4f3e2 Improve documentation
```
修改提交历史：你可以将 pick 替换为其他命令来改变提交历史。例如：
- pick：保持该提交不变。
- reword：修改提交信息。
- edit：暂停并允许你修改该提交的内容。
- squash：将该提交与前一个提交合并。
- drop：删除该提交。
示例（将两次提交合并为一个提交）：
```
pick 3a1c5d7 Fix bug A
squash 4b6f7d8 Add feature X
pick 9b4f3e2 Improve documentation
```
保存退出：保存并退出编辑器后，Git 会按照指定的操作重新组织这些提交。

交互式 rebase 常用于清理历史，比如将多次小提交合并成一次，或者修正提交信息，确保历史整洁。

2.4 冲突处理

冲突发生
当 rebase 的过程中，Git 可能会遇到合并冲突。此时 Git 会暂停并提示你解决冲突。

例如：

Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt

解决冲突
当冲突发生时，你需要手动编辑冲突文件并解决冲突。然后使用以下命令继续 rebase：

git add <conflicted-file>  # 标记冲突文件已解决
git rebase --continue      # 继续 rebase

如果你希望放弃此次 rebase，可以使用：

git rebase --abort         # 取消 rebase 并回到操作前的状态

跳过冲突
如果你不想解决冲突，并且想跳过有冲突的提交，可以使用：

git rebase --skip

2.5 区别

git rebase 通过将分支的提交“移动”到另一分支之上来更新分支历史，不会产生额外的合并提交。它保持提交历史的“线性”。
git merge 将两个分支的历史合并在一起，并生成一个新的合并提交（merge commit），记录合并操作。

选择场景：

如果你想保持历史清晰、线性，可以使用 rebase。
如果你不介意生成合并提交，且希望保留所有历史信息（包括分支的分叉），可以使用 merge。

2.6 总结

git rebase 的主要用途：重写历史，保持线性提交记录，避免不必要的合并提交。
交互式 rebase：提供了强大的工具来编辑提交历史，常用于清理和整理提交。
冲突处理：rebase 过程中可能会遇到冲突，手动解决冲突并继续 rebase。
与 git merge 的区别：rebase 保持历史线性，而 merge 保留所有历史信息并创建合并提交。