我有一个项目有两个分支，一个是master，一个是develop。
我总是在master分支上，当开发人员将他们的更改推送到开发分支时，我做git pull origin develop，然后git push origin master。这样我就可以使这些分支保持最新。
我的另一个同事建议我应该做git merge origin development，但我不知道我的方法和他的方法有什么不同，因为我们最终得到的结果是一样的。
有经验的人可以帮我解释一下吗?谢谢!
我的理解是你在扮演一种看门人的角色。有两个长寿命的分支，master和develop。发展发生在develop上;在master上什么也没有发生，除了偶尔你把develop合并到master。
既然你的服务器不做拉请求，那么你所做的是好的:
git switch master
git pull origin develop
git push origin master
你说做git merge origin develop的朋友可能不会这么说。这没有意义。
你的朋友可能实际上说或指的是git merge origin/develop。这是一个很好的说法，但它省略了一个步骤:get fetch.
你可以这样写:
git fetch
git switch master
git merge origin/develop
git push origin master
pull和fetch后面跟着命名分支的merge是一样的。然而，我同意你同事的观点:我更喜欢它，因为在fetch之后，你可以看看origin/develop，想想接下来会发生什么。
在我看来，当你从develop合并到master时，最好有一个合并提交，以澄清历史。为了确保这一点，我建议把--no-ff写成你的pull或merge。
做一个git pull实际上是一个复合操作。执行git pull origin develop意味着以下两件事之一:
git fetch origin + git merge origin/develop (merge strategy)
- or -
git fetch origin + git rebase origin/develop (rebase strategy)
如果你的pull策略已经设置为merge，这通常是默认设置，那么当你执行git pull origin develop时，你已经在做origin/develop的合并了。