git --- rebase and merge

rebase and merge

• 大家在工作中团队开发的时候对于拉取分支和合并代码时就会涉及到两种选择，git rebase与git merge：

• rebase：变基，会有一个干净的分支，但是对于记录来源不够清晰
• merge：合并，git分支看起来比较混乱，但是清楚各个记录的来源与时间节点

rebase

git rebase origin/master

• 您的分支曾经基于更改 B，现在基于更改 D。现在，您应该可以毫无问题地将代码从分支合并到“origin/master”。

• 优点：更清晰/线性的 git 历史记录，可帮助人们更快、更轻松地找到导致回归的原因（如果有的话）。
• 缺点：如果操作错误，合并冲突可能会变得更加频繁，并且可能会丢失提交历史记录。

merge

git merge origin/master

• 如您所见，尽管您的分支和“origin/master”已经分开，但最终还是合并在一起了。

• 优点：解决冲突更简单、更快捷。
• 缺点：非线性 git 历史记录。

如何选择？

• 用 merge 的情况：
  合并公共分支（如 main、develop）。
  团队协作时，避免历史冲突。
• 用 rebase 的情况：
  整理本地分支，保持提交历史线性。
  个人开发时，避免多余的合并提交

推荐：全部使用merge

• 因为大多数使用场景包括公共分支，所以推荐统一使用merge

merge和rebase解决Branch Diverged

• 尝试提交并将更改推送到 master 分支时，是否看到这条烦人的消息
  

原因是：

• 直到更改 B 之前，我的分支和“origin/master”完全相同。从更改 B 开始，我的分支和“origin/master”开始出现分歧。我的分支从更改 E、F 和 G 开始，而“origin/master”则遵循更改 C 和 D，这完全解释了消息“您的分支和“origin/master”已出现分歧，分别有 3 个和 2 个不同的提交。”这里，3 代表 E、F 和 G，而 2 代表 C 和 D
• 注意：这种情况通常会在您尝试将更改合并到“origin/master”时发生，而您团队中的其他人在您与“origin/master”同步之后、合并更改之前推送了一些其他更改

如何解决

• 我个人更喜欢 rebase，因为它提供了更线性的 git 历史记录，这在将来需要查看 git 历史记录时非常有用。但是，在 rebase 时解决冲突可能会很麻烦。