機能ブランチで作業しているときは、作業がレビューされてメインブランチに統合される前に、インタラクティブなリベースを使用してブランチのコミットをクリーンアップする傾向があります。

機能の開発中に、バックアップ手段として中間作業をリモートリポジトリにプッシュしたいと思います。つまり、ハードドライブがクラッシュしたとき、機能ブランチ全体が失われることは望ましくありません。

ただし、これによりgit push --force、リベースの後にリモートリポジトリにアクセスしなければならないことがよくあるという事実につながります。このアクションは、一般的に眉をひそめています。または、リンクされたgithubページにあるように：

コミット履歴を変更すると、リポジトリを使用する他のすべての人にとって物事が難しくなる可能性があるため、すでにリポジトリにプッシュしたときにコミットをリベースすることは悪い習慣と見なされます。

この矛盾を解決する（一般に受け入れられている）ポリシーはありますか？

なぜこれがの複製ではないのかgit "リベースのゴールデンルール"はそれほど重要なのですか？

ここでの私の質問は、リモートリポジトリに作業をバックアップすることと作業をリベースすることの間の競合を解決するためのポリシーを求めています。したがって、なぜリベースを強制しないことが「不可欠」であるのかを尋ねます。

自問すべき重要な質問：

• マスターにマージした後、リモートブランチを保持しますか？

マスターにマージした後にリモート機能ブランチを削除すると、すでに履歴が失われています。マージ/ PRを行う前にブランチをスカッシュ/リベースすると、この履歴は失われます。この場合、強制プッシュはすべて、githubをバックアップとして使用できるようにします。

強制プッシュではなく履歴を保持したい状況は、一時的な期間だけ存在するのではなく、リモートブランチがマージ後も存続している場合です。

リベースされていないブランチを保持するかどうか尋ねていると思いますか？いいえ、AFAIC。それでも、それをプッシュ強制すると、理論的には同じブランチにプッシュした他のユーザーからのコミットが失われる可能性があります

複数の人が同時にそのブランチにプッシュしているようです。あなたがこの手段を行うには、ブランチの履歴を気に。

中間作業のために代わりにできることは、そのブランチの分岐を作成することです。これにプッシュしてから、マージする前にすべてのコミットを単一のコミットにリベースすることができます。したがって、機能ブランチにコミットすると、コミットは1つだけです（ブランチ全体のリベースされた履歴を使用）。

ここに私の心を横切るいくつかの可能性をリストしています。

常に新しいブランチにリベースする

乱雑なブランチsome-featureがある場合は、新しいブランチにリベースします。例えば

$ git checkout -b some-feature-rebase
$ git rebase -i master # etc..

その後、some-feature-rebaseレビューして統合しました。

問題：ここでの大きな欠点は、厳密に言えば、リベースごとに新しいブランチが必要になることです。（たとえば、コードレビュー後に変更を加えた場合、複数のリベースを使用できます）

使用する git push --force-with-lease

のgit push --force-with-lease代替git push --forceについて学びました。

予想される状態でない限り、ブランチの更新を拒否します。すなわち、誰も上流のブランチを更新していません。

問題：これは、justを使用する状況で直接改善するようです--forceが、まだいくつかの警告があります。最も顕著なのは、のgit fetch代わりにgit pullを行い、ローカルのアップストリームブランチを更新--force-with-leaseし、リモートでマージされていない変更が行われなかったと思い込むブランチ。