方法1是错误的，方法2是正确的。
方法1没有任何意义。您通常会推和拉到具有相同名称的分支。您在本地存储库上的任何分支与您为该存储库定义的任何远程分支之间应该有1：1的对应关系。否则，无法跟踪什么代码在哪里。
实际上有两种方法可以做到这一点，其中一种是首选的方法，并得到Github，Gitlab，Bitbucket等的支持，另一种则不是。

首选方式：

正如你所描述的：

• checkout 包含要合并到主分支中的新工作的分支（dev）
• 或者在master之上重定其基，或者将master合并到其中
• 解决任何冲突
• 然后设置一个pull request将dev合并到master中，或者只是手动将dev合并到master中（取决于你是使用Gitlab等GUI还是使用CLI）

你是选择rebase方法还是merge方法通常取决于什么是最实用的。当你在分支上有一系列的提交时，rebase方法是很有意义的，其中所有的内容都与最近进入master的内容无关。如果你有一系列的提交与最近在master上所做的更改相耦合，merge方法更有意义。
作为一个经验法则，合并 * 通常 * 比变基更少的工作。

替代方式：

如果您使用的是强制执行特定工作流的GUI（如Github等），或者您定义了防止直接提交到master的规则，则可能不支持这种方式。

• 检验主程序
• 在开发中合并
• 解决冲突并添加冲突解决提交
• 已在主分支上，完成

它和上面的一样，但是对称地颠倒了。显然不是在所有情况下都有效，原因如上所述。

它们在大多数情况下是相同的。可能的差异：
1.设置了一些配置变量，如pull.rebase，pull.ff。它们会影响git pull的行为。没有这些变量，git pull origin main大约是git fetch origin main && git merge origin/main。有了pull.rebase=true，git pull origin main大约是git fetch origin main && git rebase origin/main。它们会导致不同的日志图。

1. main的头可以不同。git pull总是从远程存储库获取main的最新头，而git merge main使用本地主。本地主可以与远程主相同，落后，领先或偏离。