Git merge和Git rebase是两种不同的合并策略，它们在处理分支合并时有各自的优点和缺点。
Git fetch
git fetch 命令用于从远程仓库获取最新的更改，但不会自动合并这些更改到你的本地分支。它会下载远程仓库的所有分支和标签，并更新你的本地仓库中的远程跟踪分支。这样，你可以查看远程仓库的最新状态，而不必实际合并这些更改。
命令：
git fetch origin
Git Merge
命令：
git merge <branch-name>
作用：
将指定分支的更改合并到当前分支。
好处：
简单直观：合并过程直观明了，易于理解。
保留历史记录：合并后的历史记录会保留两个分支的历史，容易追踪。
易于冲突解决：在合并过程中，如果出现冲突，Git会标记出冲突部分，用户可以手动解决。
坏处：
快照合并：Git merge使用的是快照合并，会创建一个新的“合并提交”来表示合并，这可能导致历史复杂。
三方合并：在某些情况下，可能需要手动解决冲突，尤其是在多个分支合并的过程中。
Git Rebase
命令：
git rebase <branch-name>
作用：
将指定分支的更改重新应用到当前分支的顶部。
好处：
线性历史：Rebase会将分支上的更改重新应用到主分支上，保持提交历史的线性和干净。
更好的补丁：Rebase创建的补丁文件更稳定，因为它不包含合并的“合并提交”。
易于维护：在团队协作中，rebase可以使历史更清晰，易于维护。
坏处：
复杂性：Rebase会改变提交历史，可能会导致已推送到远程仓库的更改被拒绝（尤其是如果团队成员依赖这些提交）。
手动操作：Rebase在处理冲突时，需要手动解决，并且每次解决冲突后都需要重新应用更改。
学习曲线：Rebase的使用和理解需要一定的学习和实践。
总结
Git Merge 适用于团队协作和需要保留完整历史记录的情况。
Git Rebase 适用于个人开发或需要保持提交历史线性的情况，但需要谨慎使用，特别是在已推送到远程仓库的分支上。
选择哪种方法取决于具体的工作流程和团队的习惯。
git pull
作用：等同于git fetch + git merge两个命令，会合并两个分支产生一个新的merge分支，让git分支历史多出很多merge分支，不再线性。
git pull --rebase
作用：会把你的提交暂时放到一边，拉取远端的提交，再把你的提交挂到后面。保持了提交历史的线性干净。
设置git pull默认为rebase方式，即使不加rebase也默认为rebase方式：
git config pull.rebase true
idea设置
update project（即git pull）时建议选择：Rebase the current brach on top of incoming changes选项，不会产生merge分支