跟上其他分支的主人答案

【问题标题】：keeping up with master from other branch跟上其他分支的主人
【发布时间】：2016-07-01 05:56:13
【问题描述】：

在一个积极开发的项目中，master 有一个名为FollowingModel 的模型。

我从 master 分支出来，在我的分支上工作了几天 - 创建使用 FollowingModel 的方法。当我进行 PR 时，另一个分支被合并到 master 中，将 FollowingModel 更改为 Following。我可以在没有合并冲突的情况下合并到 master 中，但如果我这样做，应用程序会中断 - 因为我的方法将调用一个名称已更改的模型。

在这种情况下，正确的处理方法是什么？在一个大型项目中，有很多活动部件，如何处理？

【问题讨论】：

标签： git

【解决方案1】：

在提交 PR 之前，您需要在新的 master 之上重新定位您的本地分支。

您从“upstream”（远程引用原始存储库）获取，
将upstream/master 合并到master 以更新您自己的master，
在master 之上重新设置您的分支并强制推送（并将您的方法名称调整为master 正在使用的名称）

维护者的目标仍然是在收到您的 PR 时能够在他/她的 master 分支之上快进您的分支。

如果你直接推送到原始仓库，那么：

这不是“经典”公关。
但“GitHub Secrets”确实提到：

您知道您可以在同一存储库上的分支之间使用拉取请求吗？
您无需分叉存储库即可使用拉取请求。
在 GitHub 内部，我们几乎总是在分支之间使用 Pull Request。

序列变为：

git checkout master
git pull origin master
git checkout featureBranch
git rebase master
# fix bugs
git push --force origin newBranch

但这假设你是唯一一个在 newBranch 工作的人（或者这是 newBranch 的第一次推送）。如果您多次这样做，newBranch 的历史记录会在每次强制推送时更改。

【讨论】：

所以，git pull origin origin/master; git checkout featureBranch; git merge origin/master;，修复错误，git push origin featureBranch?
@DarshanChaudhary 否：origin 是你的分叉，它不反映原始仓库的最新版本。添加一个远程“上游”，其 url 指向该原始存储库。 git remote add upstream /url/to/original/repo
（我的origin 是我的upstream，我正在推送到原始存储库，位于另一个分支上，在代码审查后合并到master）。我了解您的建议是 - git checkout master; git pull origin master; git checkout featureBranch; git rebase master;，修复错误，git push origin newBranch?
@DarshanChaudhary 在这种情况下，是的，但它不是“公关”。
@DarshanChaudhary 是的，我忘记了。我已经编辑了答案，指出您可以从同一个 repo 中进行 PR（不需要分叉）

【解决方案2】：

在合并回来之前你通常会做的事情是重新基于 master。这就是在这种情况下你应该做的，要么重新设置基础，要么将 master 合并回你的分支。之后，您的分支中有新的主更改，并且可以解决出现的所有问题。修复所有Bug后，就可以合并到master了。

【讨论】：

所以，i) 在 master 上 rebase 功能分支，修复错误和git merge，将 master 分支推送到远程仓库？我应该在哪里将它推送到远程仓库的新分支？ ii) 将主分支合并到特性分支，修复错误，将特性分支推送到远程仓库。这不会导致 git 提交重复并导致我在我的分支中进行与我的功能无关的提交吗？
两种方式都可以。无论是变基还是合并，都无关紧要，重要的是，您的分支中的 master 有更改。不确定最后一句话是什么意思，但是是的，合并时您将有一个合并提交，当您重新设置基准时您将没有合并提交，但是重新设置会在您的功能上重写您的整个分支历史 -分支。
在特性分支上重新定位主节点不是比其他方式更好吗？这样，我将获得来自 master 分支的提交，我可以通过变基重写他们的历史并将它们推送到远程 repo 上的同一分支
是的，这就是我真正的意思，但我称之为“rebase feature branch on master”而你称之为“rebase master on feature”，不确定哪个是正确的。最后，你应该有一个 feature-branch，它看起来好像是直接从 master-branch 分支出来的，而不是 master 历史中的提交。