2016-08-17 50 views
0

我通过Github PR意外地将分支合并到master。立即我恢复了它(也通过github)。几天之后,当代码被测试并准备好合并时,合并和PR实际上并不会将代码放到master中,因为提交已经存在于github中(但代码不存在,因为它已被还原。重新应用通过Github合并和撤销的更改

所以现在我试图让这些更改回主,身价无关提交的两周后这大致就是git log --oneline输出与相关穴位一些意见:

54c73ee (HEAD, origin/master, origin/HEAD, staging) Merge pull request #637 from leonsas/last-night-view-metric-ceiling 
... 
More unrelated changes that should stay in. 
... 
af602f0 Merge pull request #639 from leonsas/staging 
67ded36 (origin/staging) Merge <-- Here's where I tried merging the changes again, but it doesn't make it into the codebase. 
... 
Bunch of unrelated commits that should stay. 
... 
a603d0b Merge pull request #633 from leonsas/revert-628-hr-hrv-audit 
c3da670 (origin/revert-628-hr-hrv-audit) Revert "Hr hrv audit" 
01f2fab Merge pull request #632 from leonsas/revert-629-always-get-hrvz 
5824fc8 (origin/revert-629-always-get-hrvz) Revert "Always get hrvz" <-- I reverted changes, because code wasn't tested 
b75a537 First iteration at setting the max value on the chart 
6939035 Merge pull request #631 from leonsas/is-valid-fix 
87b53d5 Merge pull request #629 from leonsas/always-get-hrvz <-- These changes I want in 
5b9a848 Merge pull request #628 from leonsas/hr-hrv-audit 

会是什么将这些更改重新应用回主的最佳方式?

- 更新1

按托马斯的建议,我又试了一次底垫的解决方案:

> git checkout -b hrv-almost-latest-changes e1d0d7b 
> git rebase master-clone 
First, rewinding head to replay your work on top of it... 
Fast-forwarded hrv-almost-latest-changes to master-clone. 
> git push --set-upstream origin hrv-almost-latest-changes 

但随后master完全了解最新的hrv-almost-latest-changes,所以没有什么在github上PR合并。

- 更新2

一般来说,采摘樱桃的罚款。具体的解决办法是:

git checkout master 
git checkout -b hrv-merge-fix 
git cherry-pick -m 1 87b53d5 
(solve conflicts) 
git add <files from solved conflicts> 
git cherry-pick --continue 
git cherry-pick -m 1 5b9a848 
git push origin hrv-merge-fix 

回答

0

我不太熟悉github在“幕后”做些什么,所以我会在命令行的本地存储库中继续执行此操作。你可以使用git checkout master ; git cherry-pick -m X 87b53d5。请参阅git help cherry-pickX值:

-m parent-number, --mainline parent-number 
     Usually you cannot cherry-pick a merge because you do not know which side of the merge should be considered the 
     mainline. This option specifies the parent number (starting from 1) of the mainline and allows cherry-pick to 
     replay the change relative to the specified parent. 
+0

看起来像这样做的伎俩,与一些解决冲突后的'-m 1'。现在手动查看代码,以确保一切都如预期。 – leonsas

0

的问题是,在PR包括提交它们已经当前主的祖先:

A- ... -F--G--H- ... -I 
\  / |   
    B--C--D--E revert PR | 
      |    current master 
|   merge PR 
old master | 
      original PR 

由于BE是我的祖先,合并È到我的尝试是不会改变任何事情。

但是,你可以变基公关分支到当前主,创造提交不属于我的祖先的一个新的字符串,并仍持有这些变化:

A- ... -F--G--H- ... -I 
\  /    \ 
    B--C--D--E     B'--C'--D'--E' 
          |    | 
          master   new PR branch 

现在,合并E”成我将要应用这些更改。

基本上,这样做:

$ git fetch 
$ git checkout E 
$ git checkout -b new-pr-branch 
$ git rebase master 
$ git push --set-upstream origin new-pr-branch 

,然后从new-pr-branch提交新的PR。

+0

其实我已经试过了,只是一次又一次,都没有成功。有关详细信息,请参阅问题更新 – leonsas

+0

@leonsas:我没有在您的历史中的任何地方看到e1d0d7b。你可以粘贴'git log --oneline --graph --all --decorate'的相关输出,也许作为[gist](https://gist.github.com/)? –

+0

啊对,e1d0d7b是合并提交前的最新提交。我会再次尝试合并提交(87b53d5)。 – leonsas