問題タブ [git-rebase]

ここ数日、Git を使ったリベースを検討してきました。リベースの議論のほとんどは、リベースによって履歴がクリーンアップされ、より直線的になると言われています。単純なマージを行うと (たとえば)、履歴がいつ分岐し、いつ元に戻されたかを示す履歴が得られます。私の知る限り、リベースするとその履歴がすべて削除されます。質問は次のとおりです。コードがどこでどのように分岐したかなど、コードが開発されたすべての方法をレポ履歴に反映させたくないのはなぜですか?

競合でリベースが失敗した後、GitGUIクライアントを使用してリベースを続行できませんでした。演奏するとき

コマンドライン（msysgit 1.7.4）で、テキストエディタを開きました。それを閉じた後、Gitは続行しました。エディターを開かないようにするにはどうすればよいですか？

私が使用しているビルド システムでは、通常、フル ビルドを実行する前に、プロジェクト データをローカル リポジトリにコミットする必要があります。これは、頻繁にコミットし、パブリック リポジトリにプッシュする前にリベースするという私の通常の習慣に加えて、通常、リモート ヘッドの上にコミットのスタックがあることを意味します。それらのほとんどは、「s」のようなコミット メッセージを持っています。

ここでの状況は、コミットのリストをリベースするステップの 1 つを自動化することです。特定のファイルに加えたすべての変更をパブリックリポジトリにプッシュするべきではないことを知っています。各コミットを編集して、そのファイルへの変更を個別のコミットに分割する方法を探していました。リベース。

たとえば、オリジンの HEAD の場合、私が一番上に持っているコミットは次のとおりです。

master..master-dave からのすべてのコミットを反復処理し、./file.txt への変更を抽出して、次のようにします。

そして最後に、git rebase -i origin/master を実行し、すべての「DD」コミットをまとめて押しつぶし、すべての「s」コミットを「master ブランチで更新された pkg」に入れ、並べ替え、master を更新します。 、原点にプッシュし、最終的には次のようになります。

答えは git filter-branch にあると確信していますが、その方法がわかりません。

編集：

• --autosquash は「s」コミットの煩わしさを修正しますが、それは主な問題ではありません。変更を特定のファイルに分割する方法はまだわかりません。これは、それらをつぶす前に行う必要があります。
• smudge/clean フィルターは気の利いたものですが、私はキーワードの置換を行っていません。また、個人のブランチで維持したい変更が、スクリプトを作成するのに十分なほど予測可能になるとは思いません。私は常に公開マスターよりも少なくとも 1 コミット先にいる必要があると思います。

リポジトリA：リビジョンでプロジェクトのSVNからgitに移行されましたr：SVNの履歴、タグなどのすべてを含むすべてのクローンを作成しました。その後、gitで少し開発しました。

リポジトリB：同じプロジェクトですが、リビジョンでSVNから独立して移行されましたr+small_number。最新のスナップショットのみがgitに取り込まれました。その後、多くの独立した開発が行われました。

ここで、AをBにマージしました。SVNは破棄さdevelopれ、GitHub上のプロジェクトのリポジトリのブランチで開発が続行されるという考えです。私は単純なマージを使用して仕事をしました。ありがたいことに、実際の競合はほとんどありませんでした。開発は主にさまざまな分野で行われましたが、マージ後はgitとは関係なく、多くのクリーンアップが行われました。

しかし、今、たとえばマージgit rebase -i HEAD~2された結果を実行すると、最後の2つのコミットをリベースできるはずですが、300以上のコミットのページが表示されます。これは、SVNのリビジョン1以降のプロジェクトの完全な履歴です。私はさらに混乱することを恐れてリベースを中止しました（明らかに私は完全なGit初心者です）。

その結果は期待されていますか？それは望ましいですか？そうでない場合、それを修正する方法は？

すべての単体テストなどに合格し、ファイル自体は問題ないことに注意してください。gitメタデータ/履歴に何が起こったのか理解できません。

編集：これは私が*思う*リポジトリが今のように見えるものです：

機能ブランチを完了した後、途中でgit rebase -i誤ってすべてのコミットを削除してしまいました。完全にはわかりませんが、コミットを押しつぶす代わりに、エントリ全体をコミット メッセージに置き換えたのではないかと思います。

http://shafiulazam.com/gitbook/4_interactive_rebasing.html言います:

インタラクティブなリベースができる最後の便利なことは、コミットを削除することです。コミット行に 'pick'、'squash'、または 'edit' を選択する代わりに、単に行を削除すると、履歴からコミットが削除されます。

私の質問は: これを元に戻す/元に戻す方法はありますか?

チームに提案することを視野に入れて、ローカル ワークフロー管理用に git を試しています。ということで、しっかりと頭を整理したいのですが、わからないことに突き当たります。

私が git-land に入ったのは、私ともう 1 人の開発者が作業している SVN リポジトリがあったときです。私たちの PM はプロジェクトのタイムラインを変更し、彼のサブプロジェクトはほぼすぐに本番環境に移行する必要があり、その後、約 1 か月後に私のサブプロジェクトを開始する必要がありました。私たちは両方とも同じ SVN リポジトリで開発を行っており、私のものはすでにユーザーに表示され始めているため、今後の本番環境への移行のために取り消す必要があります。

SVN 作業ディレクトリを更新しました。同じディレクトリで git リポジトリを開始しました (.svn などは無視します)。git branch map-dev(マップ関連の) サブプロジェクト用に開発ブランチを作成しました。私はgit checkout masterSVN 同期ブランチに戻り、それらのファイルを編集して自分の作業を取り出しました。プロジェクトの初期の部分が表示されなくなったら、git にコミットし (「地図の検索内容が非表示になりました」というコメントを付けて)、SVN にコミットし、SVN コンテンツをステージングにプッシュしました。これで、ステージング/テスト サーバー上にあるものには、私のものは何もなく、彼のすべてのものはありませんが、それで問題ありません。

数日後、私は自分のmap-devブランチで開発を進め、同僚が SVN にいくつかのものをチェックインしましたが、それは私がやっていることにはあまり影響しませんが、同期を取りたいと思っています。

私はgit checkout master。私はsvn up。git commit -a「SVNから更新」というコメントが付いています。

map-devさて、マスターのこれらの変更でリベースしますよね？それで私はそれを行い、1つか2つの競合を解決します。すべてがおかしなように見えます。master次に、 「非表示にレンダリングされたマップ検索」と呼ばれるコミットした変更が最新のものであることに気付きました。私の開発ブランチに最近のコミットはありません。それは、レポが最初にコミットされたときの様子でした。

そう。git revert --hard ORIG_HEADリベース前の状態に戻っていました。私が欲しいのは、私が入れたCSVの変更ですが、master私の作業を非表示にしたコミットではありません。どうすればいいですか？

マスターをステージ ブランチにリベースしている最中です。

ある時点で、2 つのファイルを削除し、GIT に従って 2 つのファイルを変更しました。

「ええgit、どうぞそれらのファイルを削除してください」と言いたいので....

ギットは次のように述べています。

私は「私を「ばか」と呼ぶな。

私たちは今、膠着状態にあります。誰が正しいのか、どうすればこれを修正できますか?

次の Git リポジトリ トポロジがあります。

ブランチをリベースfeatureすることで、サブツリー全体 (子ブランチを含む) をリベースすることを期待していました。

ただし、これは実際の結果です。

次を実行することで、手動で簡単に修正できることはわかっています。

しかし、すべての子/子孫を含むブランチを自動的にリベースする方法はありますか?

次のリビジョン グラフがあるとします。

A は B と C の両方に先行します。さらに、上流から A をリベースし、新しいコミット A* を作成してから、B と C の両方を A* にリベースするとします。結果のリビジョン グラフは次のとおりです。

共有履歴は共有されなくなったことに注意してください。たとえば、B をリベースしてから C を明示的に Z' にリベースする以外に、これを修正する簡単な方法はありますか。つまり、共有履歴を保持するために、複数のブランチを同時に自動的にリベースするより良い方法はありますか? スプリットポイントに人為的にタグを配置するか、グラフを手動で調べて、共有履歴を保持するためにCをリベースするコミットのsha1を見つけなければならないのは、少し厄介に思えます。可能性を開くことは言うまでもありません特に、変更を上流ブランチにチェックインするまで、リベースするたびにこれを行う必要があるためです。

⁺ SCMが使用されていないコードを使用しており、一部のプロジェクトファイルの一部のみが少し変更されていますが、すべてのプロジェクトファイルの形式で更新を受け取ることがあります。今までは、自分の変更をgitリポジトリに入れて、手動セッションでこれらの「更新」を解決しました。手動git add -pセッションでは、自分の変更（まだ公開されていないもの）の量が増え、ますます煩わしくなります。幸運なことにgit commit --author "the others"、前述の「パッチ」に対して行ったので、知りたいのは次のとおりです。

1人の作成者によって行われたすべてのコミットを新しいブランチに分割するにはどうすればよいですか？

（この場合、履歴を書き換えてもかまいません。リポジトリは私だけが使用します）

理想的な解決策には、すべての「パッチ」の後に他のブランチを私のブランチにマージすることが含まれますが、今のところ、最後に最後のマージで十分な場合があります。

⁺はい、ジェダイはあなたがそこに忍び寄るのを感じました