問題タブ [git-rebase]

くだらない！約 1 週間前、リポジトリをクリーンアップしようとしていくつかのコミットをリベースしていましたが、実際には完了していないようです。今日、1 週間といくつかのコミットの後で、今日からいくつかのコミットを並べ替えるためにリベースに行きました。

念のため、それは私のレポをコピーするための合図だったはずです。しかし、私はそうしませんでした...代わりにgit rebase --abort、その時にぴったりの音で走りました。まあ、それは正しくありませんでした。1 週間前からのリベースを中止し、マスターの HEAD を古いものにリセットしました。ダミー！

かなり最近の他のいくつかのブランチがあり、リモートに数回プッシュしましたが、最新の変更は永遠に失われているようです. 変更を回復する方法があるかどうかを知るための適切なレベルの git-fu を持っていません。

私はめちゃくちゃですか？

編集- うわー！みんなありがとう！git reflogすごい！私は完全に回復しました...教訓が得られました。Tchalvak の回答が最初に投稿されたとして承認されたことを示します。

ほとんど変更されないブランチを持つ Git リポジトリがあります (他の誰もそれに貢献していません)。これは基本的に、一部のコードとファイルが削除されたマスター ブランチです。このブランチがあると、コードとファイルを毎回手動で削除する必要がなく、プロジェクトのスリムなバージョンを簡単にパッケージ化できます。

git rebaseこのブランチをマスターで最新の状態に保つために使用していますが、リベース後にブランチをプッシュしようとすると、常に次の警告が表示されます。

私はそれを使用git push --forceして動作しますが、これはおそらく悪い習慣だと思います。このブランチをマスターと「同期」させておきたいと思っています。このタスクを処理するより良い方法はありますか?

アップデート

完全な説明と解決策については、このトピックを参照してください。

git rebase と git push: 非早送り、なぜ使うのか?

統合テストとして、マスターとマージする前にいくつかのブランチに参加したいと思います。

それらはすべてマスターから分岐し、独自の方法を作成します。直接的な関係（親/子など）のない異なるブランチをマージするのは正しいですか??

ブランチに再参加するための良い習慣はありますか??

前もってありがとう、ラウル。

私は、ソースコード管理にgitを使用する小さなチームと協力しています。最近、トピックブランチを実行して機能を追跡し、それらをローカルでマスターにマージしてから、リモートサーバー上の中央のgitリポジトリにプッシュしています。これは、マスターに変更が加えられていない場合にうまく機能します。トピックブランチを作成し、コミットし、マスターにマージしてから、プッシュします。やったー。

ただし、誰かが私より前にオリジンにプッシュした場合、私のコミットは早送りされません。したがって、マージコミットが発生します。これは、トピックブランチをローカルでマスターとマージして、現在のコードで変更が機能するようにする必要がある場合にも発生します。そのため、どこでもマージコミットが行われ、フレンドシップブレスレットに匹敵するgitログが作成されます。

したがって、リベースは当然の選択です。私がしたいのは：

• 複数のコミットを保持するトピックブランチを作成する
• マスターとプルをチェックアウトします（マスターにコミットしていないため、早送りします）
• トピックブランチをマスターの新しいヘッドにリベースします
• マスターに対してトピックをリベースし（トピックはマスターヘッドから開始します）、マスターをトピックヘッドに移動します

現在これを行う私の方法は以下のとおりです。

これを行うためのより速い方法はありますか？

git-rebaseman ページの言及-X<option>は に渡すことができますgit-merge。いつ/どのように正確に？

再帰戦略とそのオプションを使用してパッチを適用してリベースしたいと思います（競合するコミット全体をスキップするのではなく、スティックを適用します）。マージはしたくありません。履歴を線形にしたいのです。

私はもう試した：

と

-Xしかし、どちらの場合もgit は拒否します。

git rebase -Xtheirsツリーの競合を手動で解決する必要があることを除いて、最近のバージョンで動作します。git rebase -Xtheirs --continueこれらの競合を解決した後、 (-X繰り返し実行して) 実行する必要があります。

git rebaseコミットのタイムスタンプを保持しながら実行するのは理にかなっていますか?

その結果、新しいブランチのコミット日が必ずしも時系列であるとは限らないと思います。それは理論的にまったく可能ですか？(例えば、配管コマンドを使用します。ここでちょっと興味があります)

理論的に可能であれば、タイムスタンプを変更せずにリベースを実際に使用することは可能ですか?

たとえば、次のツリーがあるとします。

今、リベースoldbranchするmasterと、コミットの日付が 1984 年 2 月から 2010 年 6 月に変更されます。コミットのタイムスタンプが変更されないように、その動作を変更することは可能ですか? 結局、私はこうして得ます：

それはまったく意味がありますか？古いコミットがより最近のコミットを親として持つ履歴を持つことさえ、git で許可されていますか?

以下は、私がよく直面するシナリオです。

masterまたはに一連のコミットがあり、ブランチdesignの上に置きたいと思います。production

productionこれらのコミットをチェリーピックしてマージするため、ベースを持つ新しいブランチを作成する傾向がありますproduction

次に、master本番環境にマージすると、変更が同じであっても、チェリーピックのために別のコミットとして登録されるため、マージの競合に直面します。

これに対処するためのいくつかの回避策を見つけましたが、それらはすべて面倒であり、「ハック」と呼ぶことができます。

私はあまりリベースを行っていませんが、それによっても新しいコミット ハッシュが作成されると思います。

チェリーピッキングしている場所でリベースを使用する必要があります。これよりも他にどのような利点がありますか。

私たちの Git リポジトリには 400 件以上のコミットがあり、最初の数十件は試行錯誤の連続でした。多くのコミットを 1 つのコミットにまとめることで、これらのコミットをクリーンアップしたいと考えています。当然、git-rebase が適しているようです。私の問題は、マージの競合が発生し、これらの競合を解決するのが容易ではないことです。コミットを押しつぶすだけなので（削除や再配置ではなく）、なぜ競合が発生するのかまったくわかりません。おそらく、これは git-rebase がどのようにスカッシュを行うかを完全には理解していないことを示しています。

私が使用しているスクリプトの修正版は次のとおりです。

repo_squash.sh (これは実際に実行されるスクリプトです):

repo_squash_helper.sh (このスクリプトは repo_squash.sh でのみ使用されます):

repo_squash_list.txt: (このファイルは repo_squash_helper.sh でのみ使用されます)

「新着メッセージ」の内容はご想像にお任せします。最初は、「--strategy theirs」オプションなしでこれを行いました (つまり、デフォルトの戦略を使用します。ドキュメントを正しく理解している場合は再帰的ですが、どの再帰戦略が使用されているかわかりません)。動作しません。また、repo_squash_helper.sh のコメントアウトされたコードを使用して、sed スクリプトが動作する元のファイルを保存し、それに対して sed スクリプトを実行して、それが意図したとおりに動作していることを確認しました (そうだった）。繰り返しますが、なぜ競合が発生するのかさえわからないため、どの戦略が使用されるかはそれほど重要ではないようです。アドバイスや洞察は役に立ちますが、ほとんどの場合、この押しつぶしを機能させたいだけです。

Jefromi との議論からの追加情報で更新:

大規模な「実際の」リポジトリに取り組む前に、テスト リポジトリで同様のスクリプトを使用しました。これは非常に単純なリポジトリであり、テストは問題なく動作しました。

失敗したときに表示されるメッセージは次のとおりです。

これは、最初のスカッシュ コミット後の最初の選択です。実行git statusすると、クリーンな作業ディレクトリが生成されます。次に を実行するgit rebase --continueと、さらに数回コミットした後、非常によく似たメッセージが表示されます。その後、もう一度実行すると、数十回コミットした後に、非常によく似た別のメッセージが表示されます。もう一度実行すると、今度は約 100 回のコミットが行われ、次のメッセージが表示されます。

次に を実行するgit statusと、次のようになります。

これは単なる選択の結果であるため、「両方が変更されました」というビットは私には奇妙に聞こえます。また、「競合」を見ると、[タブ] 文字で始まるバージョンと 4 つのスペースで始まるバージョンの 1 つの行に要約されることも注目に値します。これは、構成ファイルの設定方法に問題があるように聞こえましたが、そのようなものは何もありません。(core.ignorecase が true に設定されていることに注意しましたが、明らかに git-clone が自動的にそれを行ったようです。元のソースが Windows マシン上にあったことを考えると、まったく驚かないでしょう。)

file_X.cpp を手動で修正すると、その後すぐに別の競合が発生して失敗します。今回は、あるバージョンが存在すると見なすファイル (CMakeLists.txt) と、あるバージョンが存在しないと見なすファイル (CMakeLists.txt) の間です。このファイルが必要だと言ってこの競合を修正すると (私はそうします)、いくつかのコミットの後で (この同じファイルで) 別の競合が発生し、かなり重要な変更が加えられます。紛争の解決までの道のりは、まだ約 25% にすぎません。

これは非常に重要なことかもしれないので、このプロジェクトは svn リポジトリで始まったことも指摘しておく必要があります。その最初の履歴は、その svn リポジトリからインポートされた可能性が非常に高いです。

更新 #2:

ひばりで (Jefromi のコメントの影響を受けて)、repo_squash.sh を次のように変更することにしました。

そして、元のエントリをそのまま受け入れました。つまり、「リベース」は何かを変えるべきではありませんでした。先ほど説明したのと同じ結果になりました。

更新 #3:

または、戦略を省略して最後のコマンドを次のように置き換えると:

「コミットするものが何もない」リベースの問題はもうありませんが、他の競合はまだ残っています。

問題を再現するおもちゃのリポジトリで更新します。

test_squash.sh (これは実際に実行するファイルです):

test_squash_helper.sh (test_sqash.sh で使用):

PS: はい、私が emacs をフォールバック エディターとして使用しているのを見て、うんざりする方もいらっしゃると思います。

PPS: リベース後に既存のリポジトリのすべてのクローンを吹き飛ばさなければならないことはわかっています。(「公開後にリポジトリをリベースしてはならない」という行に沿って。)

PPPS: これに報奨金を追加する方法を誰か教えてもらえますか? 編集モードでも表示モードでも、この画面のどこにもオプションが表示されません。

編集質問は「git rebaseタグもリベースするように指示できますか?」に要約されます。しかし、元の質問への回答も役立ちます。

過去をgitリポジトリに追加する方法を尋ねていますか? 私はこれらの指示に従いました。< edit >その後、スナップショットのみにあったファイルを含めるようにリベースしました。こちらを参照してください。それらを新しいものに移動したい。タグを使用するスクリプトを作成できるように、タグ付きのすべてのコミット メッセージを一意に作成したと思いますが、より一般的な方がよいでしょう。git filter-branchgit rebasegit move-tags <from> <to>

それで、「古いタイムラインの後のN番目のコミットがタグ付けされるように、新しいタイムラインのNコミット後のコミット」に対処する方法はありますか? 明らかな手動の再タグ付け以外の他のソリューションも素晴らしいでしょう。

(その恐ろしく長い文を平易な英語に直してください...)

*)ちょっと、git は祖父のパラドックスを解決しました!

私は今、ダイエットをしたいと思っている GitHub の大量のディスク容量を消費する、巨大で肥大化した Git リポジトリを持っています。プロジェクトの歴史の早い段階で行われた古いコミットを破棄する必要があります。これは、プロジェクトが進行している現在の方向性とは本質的に無関係です。

私は、そして今後もこのプライベート リポジトリの唯一のユーザーです。

理想的には、次のようなことができます。

git rebase from-birth-of-repo-until-1-month- ago

ありがとう、
ダグ