問題タブ [git-rebase]

私は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) は、状態をもう少しよく説明するためだけのものです (願っています)。

私は、開発の変更をマスターにコミットしてアップストリームにプッシュしました。これらの変更をリモートリポジトリからバックアウトし、後でマスターにマージするためにブランチをローカルに保持する最良の方法は何ですか?

次のケースを取り上げます。

トピックブランチでいくつかの作業があり、マスターにマージする準備ができました:

マスターからマージを実行し、競合を解決すると、次のようになります。

ここで、マージに時間がかかったので、別のフェッチを行って、リモート マスター ブランチに新しい変更があることに気付きました。

マスターから試すとgit rebase origin/master、すべての競合を再度解決する必要があり、マージ コミットも失われます。

以下に示すような履歴になるように、マージ コミットをリベースするクリーンな方法はありますか?

コマンドラインから git rebase を実行する方法は知っていますが、公式のgit-guiでどのように実行しますか?

私はしようとしています

私のリモートリポジトリから最新の21のコミットを追加します。

gitが私に言っているのは、競合があるということですが、それはどのようにして可能でしょうか？

私の理解では、21のコミットを取得し、それらをマスターの上に適用するだけです。どうすれば競合が発生する可能性がありますか？

手伝ってくれてありがとう！

どういうわけかgit-svnリポジトリ（リモート）を台無しにしたので、私はそれをやっています、そして私がSubversionにコミットすることができない21のコミットがあります。そこで、21個のコミットを追加する新しいgit-svnクローンを試してみました。

数週間触れていなかった機能ブランチをリベースする前は、マスターより25コミット進んでいました。リベース後、18コミットになりました。途中で解決しなければならなかったいくつかの対立がありました。おそらく正確に7。

この番号が変わる原因は何ですか？途中で発見され、NOOPコミットに変わったチェリーピック？上記の紛争解決？

これは、バグ修正ブランチをマスターブランチにマージして、アップストリームにプッシュする準備をしたときのトランスクリプトです。バグ修正ブランチが作成されてから、いくつかのアップストリームの変更がマスターにプルされ、リベースを拒否するようになりました。

エラーをスローするファイルは、開いたときに差分されません。追加、削除、または名前変更されたファイルはありません。無視されるものはなく、追跡されていないもの、ステージングされているもの、ステージングされていないものはありません。リベースが失敗する理由について私は完全に困惑しています。

私はOSX10.6.6とgit1.7.4を使用しています

マスターの上に適用したい小さなトピックブランチ（寄稿者のリモートリポジトリ上）があります。これを行うための標準的な方法は次のとおりです。

ただし、マージコミットを生成するのではなく、コミットを1つずつ適用したいと思います。

トピックブランチが私のアップストリームであるかのように、マスターをトピックブランチに適用するため、単純に実行してgit rebase contributor/topic-branchも明らかに機能しません。だから私はこれを試しました：

そして、これは私が望むことを行いますが、今は分離されたHEADがあり、マスターブランチを修正してHEADを指すようにする必要があります（を使用してbranch -f）。もちろん、これを自動的に行うBash関数を作成することもできますが、使用せずにトピックブランチをプルする「適切な」方法はありmergeますか？