問題タブ [git-rebase]

私がよく遭遇する一般的なワークフローのハードルは次のとおりです。

masterは「安定した」ブランチです

ブランチにモジュールを作成する

マスターまたは他のブランチで作業する

次の数週間で、より多くのコードが直接、または他のブランチによってマスターされる予定です。このfoo期間、ブランチは変更されません。

作業を再開し、fooブランチを更新します

大野！fooは大幅に時代遅れです! 理由は理解できますが、同期を戻す必要があります。

質問

masterブランチから最新のコンテンツを取得するにはどうすればよいですか?

リベースについて学んだばかりで、リモートにプッシュされた後はコミットをリベースしないように強く警告されました。リポジトリを爆発させないようにしたい

コミット履歴の例

• ここでは、master ブランチのすべてのコミットが origin/master にプッシュされている可能性があります。

• Z完了した foo ブランチ (Y) を現在のマスター (E) とマージすることにより、git-merge によって行われる自動コミットです。

• foo モジュールの完成以来、master はいくつかの更新 (F および G) を行いました。

リベースの使用方法は次のとおりです。

foo ブランチを更新する時が来ましたが、マスター ブランチと同期していません。

1. git rebase masterF と G のコミットを最新の foo ブランチに含めるだけでいいですか?

2. 私のコミット履歴が後でどのように見えるかを示すために、私の図を修正してもらえますか?

公開された作品を決してリベースしてはならない、危険だ、などと聞いたことはありますが、リベースが公開された場合の状況に対処する方法について投稿されたレシピを見たことがありません。

これは、リポジトリが既知の (できれば少数の) グループによってのみクローンされている場合にのみ実現可能であることに注意してください。フェッチ（！）。

私が見た明らかな解決策の 1 つは、ローカル コミットがなく、fooリベースされた場合に機能します。

これにより、ローカルの状態がfoo破棄され、リモート リポジトリの履歴が優先されます。

しかし、そのブランチで大幅なローカル変更をコミットした場合、どのように状況に対処すればよいでしょうか?

そのようなコミット履歴を持つgitリポジトリがあるとします：ABCDE

今、突然、コミット B と C は完全に欠陥があり、不要であることに気付きました。また、私はプロジェクトの履歴を完全に自由に書き換えることができるとします (おそらく私は一人でプロジェクトに取り組んでいます)。

コミット B と C を指す別のブランチがあるので、それらを失っても問題ありません。これらの変更が実際に必要になった場合は、そのブランチをチェックアウトして確認できます。

しかし、マスター ブランチの場合、履歴を強制的に AD'-E' にしたいと考えています。ここで、D と E には変更された親リストがあるだけでなく、コミット B と C によって導入された変更も含まれていません。

これは可能ですか？もしそうなら、どのように？

私は一連のコミットを行ってきましたが、2 つのコミットをマージしたいと思っていることがわかりました。最後の2つではありませんが、少し離れています

私のログ:

4 つのコミットはすべて個別のファイルを変更しているため、マージの競合は発生しません。

652b4 (追加された longtable) を 94126 (追加された略語) コミットに追加したいと思います。これどうやってするの？

私はしばらくの間実行されていた git プロジェクトを持っていますが、今は古い歴史を捨てたいと思っています。たとえば、最初から 2 年前までです。捨てるとは、この時間内の多くのコミットを、同じことを行う 1 つのコミットに置き換えることを意味します。

チェックgit rebase -iしましたが、git からのすべてのコミットを含む他の (完全な) 履歴は削除されません。

ここにグラフィカルな表現があります (d は変更セットです):

私が欲しいのは：

これはどのように行うことができますか？ありがとう。

編集

私はそれで動作しました

cd1e8c9 がスカッシュの開始リビジョン (ベース) です。次に、fixup を使用してリビジョンを融合させました。ありがとう。

この形のgitに2つのブランチがあります。

rebase --interactiveの場合と同じように、コミットをリベースして並べ替えたいと思います。ただし、いくつかのコミットをインターリーブして、このような形に仕上げたいと思います。

このリベースを1つのステップで行う方法はありますか？コミットeの上にコミットbをリベースし、次に2番目のインタラクティブなリベースを実行してすべてのコミットをソートすることにより、2つのステップでそれを実行しようとしました。問題は、他の方法では見られない（たとえば、commitbとcommiteの間の）マージ競合が発生し（commitaの後にcommitbを配置することによって）、競合を解決する価値がないことです。

私はgit merge操作とgit rebase操作の両方がどのように機能するかについていくつか読んでおり、違いについて非常に基本的な理解があると思います。ダイアグラムを見てきました :-) それにもかかわらず、現在のワークフローに使用する 2 つの中で何が最適かはまだわかりません。

私の仕事では、SCM システムとしてperforceを使用していますが、 gitをローカルで使用して、ローカルの変更を追跡したり、リファクタリングを行ったり、git がテーブルにもたらすことができる他の多くのクールなものを使用しています。git と perforce (例: p4-git) を操作する機能を支援するツールが既に存在することは知っていますが、必ずしもそのオーバーヘッドが必要なわけではないので、可能な限りシンプルにしようとしています。以下は、ローカルの git ブランチを作成し、最終的にメインの perforce デポに統合するための現在のワークフローの簡単な説明です。

1. コードベースに対して毎晩 p4 同期を行うmaster git ブランチがあります。perforce 同期の後、すべての変更をマスター ブランチにコミットします。実際、私のマスターgit ブランチは基本的に、perforce メインラインにコミットされた最新のコードのスナップショットです。

2. 私が取り組んでいるローカルの変更については、常に最初にgit ブランチを作成し、変更の作業中にこのブランチを チェックアウトします。

3. 時々、ブランチをmasterから最新のものに更新したいと思います。今まで、私はそれを行うためにgit merge masterコマンドを発行してきましたが、うまくいきました。

4. 実際の perforce デポにコミットする準備ができたら、マスターをチェックアウトしてgit merge BRANCHを発行し、通常の perforce コマンドを使用して送信することで、ブランチをマスターブランチにマージし直します。

私のワークフローを考えると、ステップ 3 でgit merge masterの代わりにgit rebase masterコマンドを本当に使用する必要がありますか? rebaseコマンドに関する私の理解から、これは、 perforce メインライン(リモート デポ) が分岐され、この分岐に基づいて新しいマスターを作成し(master-newbranch と呼ぶ)、変更を適用したい場合にのみ必要です。この新しいブランチに。最初にこのブランチ からリベースする必要がありますか?

一般的に、現在のワークフローは理にかなっていますか?それとも、既にいくつかの悪い習慣を身につけていますか?

2つのコミット（AとB）を1つの新しいコミット（C）に押しつぶしました。前の2つのコミット（AとB）は削除されました。これらのコミットを開発リポジトリから中央（ベア）リポジトリにプッシュしました。両方のgit-logリポジトリで、コミットAとBが削除されたことを確認します。問題は、すでに（AとB）があった3番目のリポジトリをプルすると、3つすべてのコミット（A、B、C）が含まれるようになることです。

プルによってこれらの変更が同期されると思いました。A〜1をチェックアウトしてから、新しい変更をマージする必要がありますか？これは、特に本番環境では面倒なようです。

中間マージを削除し (スカッシュではなく削除)、最後の 2 つのコミットを新しいブランチに移動したいと考えています。

これは私の現在git log --graphです：

私はこれで終わりたい：

git rebase -iブランチ tade とのマージを削除してgit branch newoneからgit reset --hard HEAD^2、最後の 2 つのコミットを新しいブランチに移動するために使用することを考えました。ただし、リベースを実行すると、マスターにマージされた tade ブランチからのすべてのコミットが表示され、| それらを削除することに消極的でした。

より良い方法はありますか、それとも先に進むべきですか?

編集:意図した状態グラフを更新して、より明確にしました。2 つの新しいコミット (aaaaaaaとbbbbbbb) は、状態をもう少しよく説明するためだけのものです (願っています)。