[Git场景]常用工作场景演练

场景1:开发到一半的代码，还没提交，git拉下对方的代码，但是其中有一个 commit 不想要怎么做

在 Git 中，如果你想拉取远程分支的代码，但不想要某个特定的提交，可以使用以下方法来解决：

方法1：使用 `git cherry-pick` 排除不需要的提交

拉取远程分支（不合并）：
```
git fetch origin
```

创建一个新的分支来测试拉取的内容：

git checkout -b new-feature origin/remote-branch

找到你不想要的那个 commit 的哈希值（假设为 bad_commit_sha），并查看所有其他你想要的提交的哈希值。
将所有你想要的提交 cherry-pick 到你的开发分支（假设为 dev-branch）：
```
git checkout dev-branch
git cherry-pick commit_sha_1 commit_sha_2 ... commit_sha_n
```
注意：如果 bad_commit_sha 不在你想要的提交列表里，那么只要避免 cherry-pick 这个提交即可。

方法2：使用 `git rebase` 排除不需要的提交

拉取远程分支的代码：
```
git fetch origin
```
使用交互式 rebase：
```
git rebase -i origin/remote-branch
```
在编辑器中删除你不想要的提交对应的那一行。
保存并退出编辑器，完成 rebase。

这两种方法都会避免将不需要的提交合并到你的代码中。如果有冲突，Git 会提示你解决冲突，解决后继续 rebase 或 cherry-pick 的过程。

`git rebase`是什么?

git rebase 是 Git 中的一种操作，用于重新基于另一个分支（或提交）来重写提交历史。它主要用于以下几种情况：

保持提交历史整洁： 在一个分支上完成的工作可以通过 git rebase 将其移动到另一个分支的基础之上，使得提交历史更加线性。这样可以避免复杂的分支合并历史（merge commits）。
更新分支： 当你在一个分支上工作时，可能需要跟上主分支的最新变化。你可以使用 git rebase 将你的工作分支的基础移到主分支的最新提交之上，避免创建额外的合并提交。
整理提交： 在使用交互式 rebase (git rebase -i) 时，你可以修改、合并、拆分、重新排序提交，甚至删除不必要的提交。这样可以在将代码提交到共享仓库之前整理好提交历史。

基本用法

假设你有一个分支 feature，在 master 分支的基础上进行了开发。 master 分支有了新的更新，你想在 feature 分支中包含这些更新，但不希望产生合并提交（merge commit）。可以使用以下命令：

git checkout feature
git rebase master

这将会将 feature 分支中的所有提交“重新放到” master 分支的最新提交之后。这样，你的 feature 分支看起来像是基于 master 分支的最新版本进行的开发。

注意事项

冲突处理： 在 rebase 过程中，如果某个提交无法自动应用，Git 会产生冲突。这时你需要手动解决冲突，并使用 git rebase --continue 继续 rebase，或者使用 git rebase --abort 取消 rebase。
避免在公共分支上 rebase： 一般来说，不建议在已经共享到公共仓库的分支上进行 rebase，因为这会改变提交历史，可能会导致其他开发人员的仓库出现问题。

git rebase -i 是什么?

git rebase -i 是 Git 中的一个命令，用于交互式地重写提交历史。-i 代表“interactive”，即交互式操作。通过 git rebase -i，你可以选择性地编辑、删除、合并、重新排序提交，或者将提交拆分为多个小提交。这在整理提交历史、清理代码提交、改进提交信息时非常有用。

使用场景

git rebase -i 常用于以下场景：

整理提交历史： 将多个小的、凌乱的提交合并成一个逻辑完整的提交。
修改提交信息： 更正提交信息中的错误或添加详细的描述。
删除不必要的提交： 删除误操作的提交或不需要的变更。
拆分提交： 将一个大的提交拆分为多个更小的、易于理解的提交。
重新排序提交： 改变提交的顺序，使其更符合逻辑。

如何使用

基本步骤

启动交互式 rebase：

你可以指定从哪一个提交开始进行 rebase。例如，如果你想重新整理当前分支上的最后三个提交，可以使用：
```
git rebase -i HEAD~3
```
这里的 HEAD~3 表示从当前分支的最新提交开始，向上追溯三次提交。
编辑提交列表：

运行命令后，Git 会打开一个文本编辑器，显示指定范围内的提交列表。每一行表示一个提交，格式如下：
```
pick <commit_hash> <commit_message>
```
你可以将 pick 替换为其他命令来指定如何处理这些提交。常用的命令包括：
- pick：保留该提交（默认）。
- reword：保留该提交，但修改提交信息。
- edit：保留该提交，但在此处暂停以允许更改提交的内容。
- squash：将该提交与前一个提交合并，并合并提交信息。
- fixup：将该提交与前一个提交合并，但使用前一个提交的信息。
- drop：删除该提交。
保存并退出编辑器：

编辑完提交列表后，保存文件并退出编辑器。Git 会按照编辑的顺序和操作重新应用这些提交。
解决冲突：

如果 rebase 过程中出现冲突，Git 会暂停操作，让你解决冲突。解决冲突后，使用 git add 标记解决的文件，然后运行 git rebase --continue 继续 rebase。你也可以使用 git rebase --abort 来中止 rebase，恢复到 rebase 之前的状态。

例子

假设你有以下三个提交：

pick a1b2c3d 改善了文档
pick d4e5f6g 修复了 bug
pick h7i8j9k 添加了新功能

你想合并前两个提交，并修改提交信息，可以将文件编辑为：

pick a1b2c3d 改善了文档
squash d4e5f6g 修复了 bug
reword h7i8j9k 添加了新功能

保存并退出后，Git 会进行合并，并允许你修改合并后的提交信息，然后让你编辑最后一个提交的信息。

总结

git rebase -i 是一个非常强大的工具，能够让你精确地控制提交历史，创建一个干净、整洁的提交记录。需要注意的是，rebase 会重写提交历史，因此在处理已经推送到公共仓库的分支时要格外小心，以避免影响他人的工作。

该场景可以用 git stash 来实现吗?

是的，可以使用 git stash 来实现类似的效果，特别是在你有未提交的本地更改并且希望拉取远程分支的代码但不希望合并其中的某些提交时。以下是使用 git stash 的步骤：

保存当前工作状态：
首先，你需要保存你当前的本地更改到 Git 的储藏区（stash）中，以便你可以在之后恢复这些更改。
```
git stash
```
拉取远程分支的最新代码：
在保存工作状态后，你可以拉取远程分支的代码。
```
git fetch origin
git checkout remote-branch
```
找到并排除不需要的提交（可选）：
你可以通过 git log 找到不需要的提交，记下其哈希值。如果你知道不需要的提交，可以跳过这一步。
使用 git cherry-pick（如果需要排除某些提交）：
如果你需要排除某些提交，可以使用 git cherry-pick 选择性地应用你需要的提交到你的本地分支。
应用储藏的更改：
在处理完远程分支的代码后，你可以恢复你之前的本地更改。
```
git stash apply
```
如果有冲突，你需要手动解决冲突并提交更改。
清理储藏区（可选）：
如果你不再需要储藏的内容，可以清理它。
```
git stash drop
```

这种方法适用于你希望暂时存储本地未提交的更改，拉取远程代码，并在之后继续本地开发的情况。使用 git stash 可以避免在你拉取远程代码时与本地更改冲突。

git fetch 是什么?

git fetch 是 Git 中的一条命令，用于从远程仓库中获取最新的更新到本地，但不会自动将这些更新合并到当前的分支中。具体来说，git fetch 会从远程仓库中获取所有的分支、标签等信息，并将它们更新到本地的远程跟踪分支中（例如 origin/master ）。

主要作用

同步远程仓库的更新： git fetch 会将远程仓库的最新状态同步到本地仓库，但不会影响你当前的工作分支。因此，它是一个查看远程仓库更新的安全方式。
更新远程跟踪分支： git fetch 会更新本地的远程跟踪分支（如 origin/master、origin/feature-branch 等），你可以通过这些远程跟踪分支了解远程仓库的最新情况。
不改变工作目录： 与 git pull 不同，git fetch 只会获取更新，而不会修改你当前的工作目录文件或当前分支的状态。因此，它不会引入任何潜在的冲突或未预期的更改。

常见用法

git fetch <remote> <refspec>

<remote> 是远程仓库的名字，通常默认是 origin。
<refspec> 是可选参数，用于指定要获取的引用（分支、标签等）。如果省略，将获取所有引用。

例如：

git fetch origin

这将从名为 origin 的远程仓库中获取所有分支的更新。

配合其他命令使用

git merge 或 git rebase: 在获取更新后，可以使用 git merge 或 git rebase 将远程更新合并到本地分支。
git checkout: 可以切换到更新后的远程分支进行查看或操作。

总结

git fetch 是一个非常安全的命令，它不会修改你的工作目录，但可以让你了解远程仓库的最新状态，是与远程仓库保持同步的重要手段。

详细说说 git stash 的步骤

git stash 是 Git 中的一个有用工具，用于临时保存当前的工作状态（包括已修改但未提交的文件和暂存区中的文件），以便在不提交这些更改的情况下切换分支或拉取远程更新。使用 git stash 可以避免工作丢失，并且可以在稍后恢复这些更改。以下是 git stash 的详细步骤和用法：

1. 保存当前工作状态

git stash

这条命令会将当前的工作目录和暂存区的更改保存到一个临时的储藏区，并将工作目录恢复到最近一次提交的干净状态。如果你有未跟踪的文件，也可以使用 -u 选项来包含它们：

git stash -u

你还可以添加消息来描述这次 stash，以便将来更容易识别：

git stash save "Your description here"

2. 查看储藏的更改

你可以使用以下命令查看当前所有的储藏条目：

git stash list

这会列出所有的储藏条目，并带有它们的索引和描述（如果有）。

3. 恢复储藏的更改

当你准备恢复之前储藏的更改时，有两种方式可以使用：

使用 `git stash apply`

git stash apply 会应用最近的或指定的储藏条目，但不会从储藏列表中删除它。可以指定储藏条目的索引号来应用特定的条目。

# 应用最近的储藏条目
git stash apply

# 应用特定的储藏条目
git stash apply stash@{2}

使用 `git stash pop`

git stash pop 会应用最近的或指定的储藏条目，并从储藏列表中删除它。

# 恢复最近的储藏条目并删除它
git stash pop

# 恢复特定的储藏条目并删除它
git stash pop stash@{2}

4. 删除储藏的更改

如果你确定不再需要某个储藏条目，可以删除它：

# 删除最近的储藏条目
git stash drop

# 删除特定的储藏条目
git stash drop stash@{2}

# 删除所有储藏条目
git stash clear

5. 合并冲突处理

当你应用储藏的更改时，可能会遇到合并冲突。这时，Git 会提示你手动解决冲突。解决冲突后，你可以使用 git add 来标记解决的文件，然后继续你的开发工作。

总结

git stash 是在开发过程中临时保存工作状态的强大工具，它可以让你在不提交不完整或暂时性更改的情况下进行其他操作，如切换分支或拉取远程代码。通过正确地使用 git stash，你可以保持工作目录的干净，同时避免工作丢失。

场景2:当我在开发中，另一个开发人员已经提交了代码，而我此时的代码还没有git add 也没有 git commit 此时此刻我如果拉了他的代码会有什么影响？如何避免开发到一半拉代码带来的影响?

在开发过程中，如果你没有将本地的更改添加到暂存区（git add）或提交（git commit），而此时另一个开发人员已经提交了代码，你决定拉取这些更新，可能会遇到以下情况：

1. 拉取远程代码的影响

未提交的更改未被覆盖：
直接拉取远程代码（例如使用 git pull）时，本地未提交的更改不会被覆盖，Git 会尝试将远程更改合并到你当前的工作目录。
可能遇到冲突：
如果远程代码和你的本地更改在同一文件的同一部分，可能会发生冲突。你需要手动解决这些冲突。
中断工作流程：
如果你还没有保存本地更改（即未使用 git add 或 git commit），任何错误操作都有可能导致工作丢失。

2. 避免开发到一半拉代码带来的影响

为了避免拉取远程代码时出现问题，可以采取以下措施：

1. 使用 `git stash`

git stash 可以临时保存当前的工作状态，包括未暂存的更改和暂存区的内容。这样可以安全地拉取远程代码，然后再恢复未完成的工作。

# 保存当前工作状态
git stash

# 拉取远程代码
git pull origin branch_name

# 恢复保存的工作状态
git stash pop

2. 使用 `git fetch` 和 `git merge/rebase`

git fetch 只会更新远程跟踪分支，而不会修改你的工作目录。你可以在 git fetch 之后使用 git merge 或 git rebase 来处理代码合并。

# 拉取远程分支的更新
git fetch origin

# 将远程更新合并到本地分支
git merge origin/branch_name
# 或者使用 rebase
git rebase origin/branch_name

3. 提交本地更改

为了防止丢失本地更改，在拉取远程代码之前最好将所有的更改提交到本地仓库。这样，即使出现冲突，你也可以轻松地回滚到上一个已知状态。

# 添加本地更改
git add .

# 提交本地更改
git commit -m "Your commit message"

# 拉取远程代码并处理冲突
git pull origin branch_name

总结

在开发过程中，避免开发到一半拉取代码可能带来的影响的最好方法是：要么使用 git stash 临时保存工作，要么先提交本地更改。这样可以避免在合并时遇到冲突，并确保本地工作不丢失。

git stash git pull git stash pop 这是干嘛?

这三个 Git 命令的组合可以用来在开发过程中临时保存当前工作状态，拉取远程分支的最新更新，然后恢复之前的工作状态。以下是每个命令的详细解释：

git stash：
这个命令将当前的工作目录和暂存区的更改保存到一个临时的储藏区，并将工作目录恢复到最近一次提交的状态。它可以帮助你在不提交本地更改的情况下，临时保存工作并切换到其他分支或执行其他操作。

例如，如果你正在开发一个功能，但还没有完成或不想提交这些更改，可以使用 git stash 来保存这些更改。
git pull：
这个命令用于从远程仓库拉取最新的代码并将其与本地分支合并。git pull 其实是 git fetch 和 git merge 的组合，它会先获取远程分支的最新提交，然后将这些提交合并到当前分支中。

在 git stash 之后使用 git pull，可以确保你拉取并合并远程分支的最新更新，而不影响你本地未提交的更改。
git stash pop：
这个命令会恢复最近一次的储藏条目，并从储藏列表中删除它。它的作用是将之前使用 git stash 保存的本地更改重新应用到当前工作目录中。

在 git pull 之后使用 git stash pop，可以恢复你之前的工作状态，继续进行未完成的工作。

使用场景

假设你正在开发一个功能，但是突然需要拉取远程仓库的最新更新，而你不希望现在提交本地的更改。你可以按照以下步骤操作：

保存当前工作状态：
```
git stash
```
这会将所有未提交的更改保存到储藏区，并将你的工作目录恢复到最近一次提交的状态。
拉取远程更新：
```
git pull
```
这会获取并合并远程分支的最新更改到你的本地分支。
恢复之前的工作状态：
```
git stash pop
```
这会将之前保存的本地更改重新应用到当前工作目录中，并从储藏区中删除这些更改。

总结

git stash git pull git stash pop 的组合是一个常见的工作流程，用于在不提交本地更改的情况下拉取远程更新，并在拉取之后恢复之前的工作状态。这样可以确保你的本地分支保持最新，同时不会丢失任何未提交的工作。

为什么解决冲突了还要 pop 恢复到之前的状态？

在使用 git stash 和 git pull 的过程中，可能会产生一些困惑，特别是涉及到解决冲突和恢复之前的状态的问题。以下是一个详细解释：

为什么解决冲突后还要 `git stash pop` 恢复之前的状态？

git stash 保存了你所有的本地更改（包括工作目录和暂存区的未提交更改），并将你的工作目录恢复到最近一次提交的干净状态。之后，你使用 git pull 拉取了远程仓库的更新，这可能会引发与本地更改的冲突。当你解决这些冲突并完成合并后，可能会疑惑为什么还需要使用 git stash pop。

其实，这里有一个可能的误解。我们需要分清楚以下两个步骤的顺序和目的：

git pull 引发冲突并解决冲突：
当你执行 git pull 时，如果远程分支的更改与本地的更改发生冲突，Git 会提示你解决这些冲突。你需要手动解决冲突，完成后用 git add 标记已解决的文件，然后 git commit 以完成合并。
恢复 stash（git stash pop）：
在执行 git stash 后，暂存区的更改也被存储起来了。因此，如果你的更改中有暂存的内容，拉取和合并远程更新时这些内容会被保留在 stash 中。如果这些更改没有通过 git stash pop 恢复，你的工作目录就不会完全恢复到之前的状态。

正确的操作流程

执行 git stash： 保存当前工作状态。
执行 git pull： 拉取并合并远程更改。
解决冲突（如果有）：手动解决冲突并完成合并。
恢复暂存的更改（git stash pop）：
- 这是为了恢复任何被 git stash 保存的内容（包括暂存区的内容），这些内容不会自动在解决冲突和合并后恢复。
- 需要注意的是，如果 git stash pop 后仍有冲突，你需要再次解决这些冲突。

总结

git stash pop 是在 git stash 和 git pull 之后的一步，用来恢复之前存储的所有内容（包括未提交的更改和暂存区的内容）。在解决冲突并完成合并之后，git stash pop 可能仍然需要执行以确保完全恢复之前的工作状态。

在使用 git stash 时，尤其是处理复杂的代码合并和冲突时，必须清楚区分不同阶段的工作状态，并确保在正确的步骤中恢复所有必要的更改。

git merge 与 git rebase 的区别

git merge 和 git rebase 是 Git 中两种合并分支的方法，它们各自有不同的工作原理和使用场景。下面是两者的主要区别：

1. 工作原理

git merge:
- git merge 会将两个分支的历史合并在一起，创建一个新的合并提交（merge commit）。这种方法保留了原始分支的提交历史，并将它们合并到目标分支中。
- 例如，如果你在 feature 分支上开发，并想把它合并到 master 分支上，git merge 会创建一个新的提交，这个提交包含 feature 和 master 分支的最新状态。
  下图是 merge 合并分支时前后版本变化的情况。

merge
以下是使用 merge 合并后的主分支 Graph 情况，看上去是不是有点乱。
在这里插入图片描述
假设有两个分支，main 和 dev分支，在 dev 分支上开发，然后合并到 main 分支，合并的大致流程如下。

git checkout main
git pull origin main
git merge dev

**解决冲突后**
git commit -m "Merge dev into main"
git push origin main

git rebase:
- git rebase 会将当前分支的所有提交“移动”到另一个分支的最新提交之上，从而重写提交历史。它的作用是让提交历史变得线性，避免了合并提交。
- 例如，如果你在 feature 分支上开发，并想把它基于 master 分支的最新提交，git rebase master 会将 feature 分支的所有提交重新应用在 master 分支之上，生成一组新的提交。

rebase
同样地，假设当前有两个分支，main 和 dev，用 rebase 方式合并分支的大致流程如下。

git checkout dev
git pull origin dev
git rebase main
# 解决冲突后
git rebase --continue
git push origin dev --force

合并压缩
在rebase 的时候还可以使用 squash 参数来压缩提交记录，例如下图，Feature 1 分支的 A、B、C 三个提交记录，使用 rebase squash 后会在主分支变为一个提交记录 F。
在这里插入图片描述
使用方式如下，git rebase -i HEAD~3 命令准备压缩最近的3次提交，然后在编辑模式下将pick 改为 squash，最后推送到远端仓库。

适合那种

git checkout dev
git rebase -i HEAD~3
 进入编辑模式后，修改 `pick` 为 `squash`
保存并关闭编辑器后，编辑新的提交信息并保存
git push origin dev --force

2. 提交历史

git merge:
- 保留了分支的分叉和合并历史，适合需要保留完整开发历史的情况。
- 提交历史中会有一个合并提交，显示分支合并的过程。
git rebase:
- 通过重写提交历史，使提交看起来像是线性顺序进行的，适合需要简洁、清晰的提交历史的情况。
- 不会创建合并提交，而是将所有提交重新应用在新基础上。

3. 冲突处理

git merge:
- 合并时遇到冲突需要手动解决，解决冲突后会生成一个合并提交。
git rebase:
- Rebase 过程中每一个提交都会逐个应用，如果有冲突需要逐一解决。解决冲突后继续 rebase，直到所有提交都处理完毕。

4. 使用场景

git merge:
- 适合在合并长期分支时使用，如合并 feature 分支到开发或主分支时。
- 适合在需要保留分支合并历史的场合。
git rebase:
- 适合在个人开发分支和主分支保持同步时使用，例如在推送代码前将分支历史整理得更整洁。
- 避免在公共仓库上已经共享的分支上使用 rebase，因为这会重写提交历史，导致其他开发者的仓库出现问题。