チェックアウトthisあなたが達成しようとしているものに非常に似た何かをしたい別の質問にお答えください。
それはこのように自分の状況を説明します。
newcommit -> the new pull request commit
oldcommit -> the old pull request commit
upstream -> the base branch commit the new pull request is based on
は今、この操作を行います。
git commit-tree newcommit^{tree} -p oldcommit -p upstream -m "message"
git show <commit id returned by previous command>
をアイデアは、そのコミットツリーがoldcommit
とupstream
の間に偽のマージをnewcommit
ツリーを生成するため、含まれますです正確にnewcommit
のコード。 現在のブランチはまったく変更されません。新しいヘッドレスコミットが作成され、そのIDが与えられます。 つまり、git show
はすべての変更を競合解決としてリストします。これは、新しいPRと古い競合の正確な違いです。
これを可能にするには、gitリポジトリの前のPRをどこかに置く必要があります(強制的にプッシュが実行された場合、gitの履歴は書き換えられ、PCやあなたはサーバーreflogにアクセスできます)。これについての詳細は、VonCの回答を参照してください。
と仮定:
- ベース支店:あなたはローカルで古いPRの分岐を有していて
master
- :
$BRANCH_NAME
- リモートブランチでの新しいPR:
origin/$BRANCH_NAME
あなたが好き行うことができます
これは:
# fetch locally upstream changes (origin/$BRANCH_NAME)
git fetch
# produce the fake merge commit
git commit-tree origin/$BRANCH_NAME^{tree} \
-p $BRANCH_NAME \
-p `git merge-base master origin/$BRANCH_NAME` \
-m "message"
# see "fake" conflict resolution = difference between the two PR
git show <commit id returned by previous command>
git merge-base
は、2つのブランチ間の共通の祖先を見つけるために使用されます。この場合は、コミットIDを直接書くことができる場合は、新しいブランチがベースブランチに基づいています。
実際、TopGitブランチを使用してTopGitブランチをプッシュしても、この問題は発生しません。つまり、TopGitブランチを見て、何が変更されたのかを知ることができます。なぜなら、TopGitはリベースの代わりにマージを行い、その後、PRを公開するときに、エクスポート(ヒストリを変更しない不安定なリベースのようなものです)のためです。それは私の同僚が彼らのgitのワークフローを変更する必要があります。 –
2番目の考えでは、問題のあるマージの解像度がマージコミット内に隠れてしまう可能性があるため、常に問題を解決するとは限りません。 –
サイドノート:GitHubは "rebase on merge"マージ戦略をサポートしていますので、実際にプルリクエストをリベースする必要はありません。 –