基本的に、私は Github revert button を使用して、機能ブランチの以前のPRをmaster
に戻し、それをマージすることにしました機能ブランチを以前に戻しましたが、できませんでした。次の手順:
master
にマージするPRmaster
)からのPRマージを元に戻しますmaster
に再度マージするための新しいPRを作成しようとしました。比較するものは何もありません。
マスターは機能ブランチからのすべてのコミットで最新です。比較のためにベースを切り替えてみてください。
feature branchをmaster
に再びマージする方法に関する提案
元に戻すだけです。元に戻すボタンをクリックすると、新しいPR(ステップ2)が作成されます。これがマージされると、これを元に戻すことができます。これにより、すべての変更が反映された新しいブランチが作成されます。これをプルし、必要に応じて変更を加え、新しいPRを作成できます。 Githubのコミットメッセージはすべて失われますが、ファイルの変更はすべてそのまま残ります。元のブランチを参照し、新しいPRで元に戻すのに適しています。
複雑なリベースを回避したり、マスターへのプッシュを強制するもの。
私はこれが古いことを知っていますが、誰かが良い答えを必要とする場合はここにあります:
PRをマージして分岐を削除し、後でこのマージを元に戻すと、新しいブランチを作成して元に戻すことができます。これをリモートリポジトリにプッシュし、新しいPRを作成します。
これにより、diffに対するすべての変更を含む「revert "revert#123 blabla"」という名前の1つのコミットで新しいPRが作成されます。
https://www.tildedave.com/2012/11/24/reverting-a-github-pull-request.html
私はこの問題に直面したので、この回答を書いています。ここでの回答は、実際的ではなく理論的であることがわかりました。私はもう少しサーフィンして、この問題に取り組む方法を見つけました。詳細な回答については、記事 here を参照してください。
この問題を解決するには、マスターを追跡する新しいブランチを作成し、コミットを元に戻す必要があります。次に、機能ブランチにチェックアウトし、新しいブランチをマージします。これで、競合があれば解決し、コミットして新しいPRを作成できます。
ここにコマンドがあります:
# do the needed changes in the feature branch
$ git commit -m "fixed issues in feature-branch'
# create new branch tracking master branch
$ git checkout -b revert-the-revert-branch -t master
# revert the reversion commit
# find it from your git log
# in linux try: 'git log | grep revert -A 5 -B 5'
$ git revert <revert-commit-hash>
# checkout the original feature branch
$ git checkout feature-branch
# merge the revert branch
$ git merge revert-the-revert-branch
# handle merge conflicts and commit and PR
自動マージできないのは、ブランチのベースがマスターブランチのHEAD)と同期していないためです。
元に戻すと、面倒な作業になり、透明性が失われる場合があります。
さらに、復帰を元に戻すと、このコードを含む他のブランチが正しくマージされなくなります。
マスターにフィーチャーxがあり、ブランチyにマージされたとしましょう。次に、ブランチyに依存しているため、マスターxに機能xがまだマージされていないはずであると判断します。したがって、マスターに戻ります。ブランチxをマージしようとすると、git-mergeコマンドは元のマージを確認し、すべてが正常でブランチがすでにマージされていることを喜んでアナウンスします。ブランチyとマージしたかったとしても、機能xに対するこれらのコミットは省略されます。
最新のマスターをプルし、ブランチをマスターにリベースすると、別のプルリクエストを実行できるようになります。