上游合并提交请求 [英] Upstream merge commits in pull request

问题描述

在进行开源开发时，在主题分支上进行任何更改时，跟踪上游一段时间是正常的。我注意到在将上游带回时注意到的一件事是创建了合并提交。如果我然后创建一个拉请求，这个合并提交最终作为PR的一部分。

我的问题是，这有什么害处吗？我读过一些人觉得他们没用，但我喜欢这样一个事实，即当他们与上游同步时，他们就是一个时间戳。是否有一种公认的做法，用于跟踪上游并引入合并提交。 当将上游

这就是为什么它最好：
$ b $ b

• git rebase master （在更新的远程跟踪分支之上重新绑定您的分支）
  
• git push -f （强制将分支推送到您的GitHub分支：现有的PR将相应更新）
  

在以下情况下运行良好：

• 您的PR在其自己的分支中完成


• 没有人正在积极使用您的分行

When doing open source development it's normal to track against the upstream for a period of time while doing any changes on a topic branch. One of the things I have noticed when bringing the upstream back is that a merge commit is created. If I then create a pull request this merge commit ends up as part of the PR.

My question is, is there any harm in this? I have read that some people feel they are useless but I like the fact that they act as a timestamp against when I last synced with the upstream. Is there an accepted practice for tracking the upstream and introducing merge commits.

解决方案

when bringing the upstream back is that a merge commit is created.

That is why it is preferable to:

• git rebase master (rebase your branch on top of the updated remote tracking branch)
• git push -f (force pushing your branch to your GitHub fork: the existing PR will be updated accordingly)

That works well if:

• your PR is done in its own branch
• nobody else is actively using your branch

这篇关于上游合并提交请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！