我正在寻找简单的方法来确定在通过github web界面合并之前,pull request branch是否已经在当前master上重新定位。到目前为止,我必须检查父提交哈希并将其与最新的主提交哈希进行比较。我想在合并按钮或其他东西旁边看到一些真/假图标,以避免合并非重新分支的分支。任何建议或可能的插件/浏览器扩展等?
答案 0 :(得分:0)
我不知道任何这样的插件可以检测拉动请求分支是否已经在主分支之上重新定位。在任何情况下,您应该养成在合并GitHub上的pull请求之前始终查看本地和主分支的习惯。但我发现您的工作流程存在更大的根本问题。您似乎正在尝试通过GitHub将重新定义的功能分支合并到主服务器中。这违背了变基的主要目的。
在主人身上重新定位一个本地特色分支的重点是“提前”#34; master的主要内容,以便您可以使用功能中的所有提交快进主分支。图表有助于更好地解释这一点:
master: A <- B
feature*: A <- B <- C <- D
(* after rebasing feature branch on master)
现在,如果您要发出git push origin feature:master
,您将快进主分支,并在整个提交过程中构成您的功能。现在master看起来像功能分支:
master: A <- B <- C <- D
请注意,此处不涉及合并。您实际上将每个提交从您的功能直接推送到主分支。另一方面,如果您通过GitHub拉取请求合并功能分支,那么这就是主人的样子:
master: A <- C <- M
这里,M是包含整个功能分支的合并提交,现在已被压缩。显然,这是两个非常不同的结果,你应该仔细考虑你的组织在他们的Git工作流程中真正想要的东西。
最后,请注意GitHub喜欢强制执行基于合并的工作流程。如果你发现自己正在审查一个拉取请求,你应该意识到你很可能会撤消某人为了在主人身上重新定义他的功能所做的细致工作。可以在GitHub中使用rebase,但是你必须解决pull请求。