機能ブランチのリベース後にGitプッシュが拒否されました

OK、これは単純なgitシナリオだと思いましたが、何が欠けていますか？

私はmaster枝と枝を持っていfeatureます。私はいくつかの作業master、いくつかの作業feature、そしていくつかの作業を行いmasterます。私はこのようなものになります（辞書式順序はコミットの順序を意味します）：

A--B--C------F--G  (master)
       \    
        D--E  (feature)

私がする何の問題もないgit push origin master遠隔保つためにmasterもして、更新をgit push origin feature（ときにfeature私のためのリモートバックアップを維持するために）feature仕事を。今まで、私たちは元気です。

しかし今、私はマスターfeatureのF--Gコミットの上にリベースしたいので、私git checkout featureとgit rebase master。まだいい。今私たちは持っています：

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

問題：バックアップに私はしたい瞬間新しいリベースfeatureで分枝状git push origin feature、プッシュが拒否されたツリーがリベースによって変化しているため。これはでのみ解決できgit push --force origin featureます。

私は--forceそれが必要かどうか確信せずに使用することを嫌います。それで、私はそれが必要ですか？リベースは必ずしも次pushがフルであることを意味し--forceますか？

この機能ブランチは他の開発者と共有されていないので、強制プッシュで事実上問題はありません。データを失うことはありません。質問はより概念的です。

問題は、git pushリモートブランチをローカルブランチに高速転送できることを前提としていることです。つまり、ローカルブランチとリモートブランチの違いはすべて、ローカルに次のような新しいコミットがいくつかあることです。

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

git rebaseコミットを実行すると、DとEが新しいベースに適用され、新しいコミットが作成されます。つまり、リベース後は次のようになります。

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

この状況では、リモートブランチをローカルに早送りすることはできません。ただし、理論的にはローカルブランチをリモートにマージすることはできますが（もちろん、その場合は必要ありません）、git push早送りマージのみを実行するため、スローとエラーが発生します。

そして、--forceオプションは、リモートブランチの状態を無視して、プッシュするコミットに設定するだけです。したがって、git push --force origin feature-branch単にorigin/feature-branchlocalでオーバーライドしますfeature-branch。

私の意見では、機能ブランチのリベースmasterとリモートリポジトリへの強制プッシュバックは、あなたがそのブランチで作業する唯一のユーザーである限り問題ありません。

-fまたは--forceを使用する代わりに、開発者は

--force-with-lease

どうして？なぜなら、リモートブランチの変更をチェックするからです。これは絶対に良い考えです。JamesとLisaが同じ機能ブランチで作業していて、Lisaがコミットをプッシュしたとしましょう。Jamesはローカルブランチをリベースし、プッシュしようとすると拒否されます。もちろん、Jamesは、これはリベースと--forceの使用によるものであり、Lisaのすべての変更を書き換えると考えています。ジェームズが--force-with-leaseを使用していた場合、他の誰かによってコミットが行われたという警告を受け取ることになります。リベース後にプッシュするときに--force-with-leaseではなく--forceを使用する理由がわかりません。

代わりに「checkout -b」を使用するので、理解しやすくなります。

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

削除すると、異なるSHA IDを含む既存のブランチをプッシュすることができなくなります。この場合、リモートブランチのみを削除しています。

これに対する1つの解決策は、msysGitのリベースのマージスクリプトが行うことを実行することです。リベースの後、古いのfeaturewithにマージし-s oursます。あなたはコミットグラフで終わります：

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

...そしてあなたのプッシュはfeature早送りになります。

つまり、次のことができます。

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

（テストされていませんが、それは正しいと思います...）

このブランチには開発者が1人しかいない場合とそうでない場合があります。つまり、現在（リベース後）はorigin / featureと一致していません。

そのため、次のシーケンスを使用することをお勧めします。

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

うん、新しいブランチ、これは--forceなしでこれを解決するはずです。これは一般的にgitの大きな欠点だと思います。

強制プッシュを回避する私の方法は、新しいブランチを作成してその新しいブランチで作業を継続し、ある程度の安定後、リベースされた古いブランチを削除することです。

• チェックアウトしたブランチをローカルでリベースする
• リベースされたブランチから新しいブランチへのブランチ
• そのブランチを新しいブランチとしてリモートにプッシュします。リモートの古いブランチを削除する

他の人があなたの質問に答えました。ブランチをリベースする場合、そのブランチを強制的にプッシュする必要があります。

リベースと共有リポジトリは一般的にうまくいきません。これが書き換え履歴です。他の人がそのブランチを使用しているか、そのブランチからブランチしている場合、リベースは非常に不愉快になります。

一般に、リベースはローカルのブランチ管理に適しています。リモートブランチ管理は、明示的なマージ（--no-ff）で最適に機能します。

また、マスターを機能ブランチにマージすることも避けます。代わりに、マスターにリベースしますが、新しいブランチ名を使用します（たとえば、バージョンサフィックスの追加）。これにより、共有リポジトリをリベースする問題が回避されます。

何が問題になっているgit merge masterのfeatureブランチは？これにより、メインラインブランチから分離したまま、作業内容が保持されます。

A--B--C------F--G
       \         \
        D--E------H

編集：ああ、申し訳ありませんが問題のステートメントを読みませんでした。を実行するときに、力が必要になりますrebase。履歴を変更するすべてのコマンドには--force引数が必要です。これは、（古い仕事を失うことからあなたを防ぐためのフェイルセーフであるDとE失われてしまいます）。

だから、行ってgit rebase（一部として隠されていないが、のような木の表情を作っているDとE、もはや名前のブランチであるが）。

A--B--C------F--G
       \         \
        D--E      D'--E'

そのため、新しいfeatureブランチを（それを含めて）プッシュしようとするとD'、およびE'が失わDれEます。

私にとって簡単な手順に従うとうまくいきます：

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

上記のすべてを行った後、次のコマンドでmyFeatureブランチも削除できます。

git push origin --delete myFeature

次は私のために働きます：

git push -f origin branch_name

そしてそれは私のコードを削除しません。

ただし、これを回避したい場合は、次の操作を実行できます。

git checkout master
git pull --rebase
git checkout -b new_branch_name

その後、すべてのコミットを新しいブランチにチェリーピックできます。 git cherry-pick COMMIT ID 次に、新しいブランチをプッシュします。

OPは問題を理解しているので、より良い解決策を探すだけです...

これは練習としてどうですか？

• 実際の機能開発ブランチを使用します（リベースや強制プッシュを決して行わないため、他の機能開発者はあなたを嫌いません）。ここでは、定期的にmainからの変更をマージで取得します。メシエの歴史、そうですが、人生は簡単で、誰も彼の仕事に邪魔されません。

• 2番目の機能開発ブランチを用意します。1つの機能チームメンバーが定期的にすべての機能コミットをプッシュし、実際にリベースし、実際に強制します。したがって、かなり最近のマスターコミットにほぼ完全に基づいています。機能が完了したら、そのブランチをマスターの上にプッシュします。

このメソッドのパターン名はすでに存在している可能性があります。