3

私は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 と呼ぶ)、変更を適用したい場合にのみ必要です。この新しいブランチに。最初にこのブランチ からリベースする必要がありますか?

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

4

3 に答える 3

1

この場合、(必然的に)マージよりもリベースを使用しないでください。リベースは基本的に履歴を書き換えることを忘れないでください。複数のブランチをクリーンアップし、より直線的な履歴を提供するのに役立ちますが、ユース ケースからは、リベースを使用しても何も得られません。あなたが説明した動作は、マージが設計された通常の git ワークフローです。

リベースで難しいのは、すでにプッシュしたコミットをリベースする (履歴を書き直す) ときです。これは、他のユーザーとの共同作業で大きな問題を引き起こす可能性がありますが、共同作業に perforce を使用しているため、この問題に遭遇する可能性はほとんどありません。

于 2011-01-07T18:19:46.923 に答える
1

私はほぼ同じワークフローを持っており、git rebase -i master を使用することを好みます。これにより、すべての perforce 再同期が変更リストの一番下に保持されます。したがって、最新バージョンをチェックアウトして、大量の変更を加えたようです。また、ブランチに関連する変更のみが再同期後に表示されます。より直感的に見えますが、正確さというよりはスタイルの問題のように聞こえます。〜ベン

于 2012-05-29T22:33:50.433 に答える