問題タブ [git-merge]

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

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

meld またはその他の diff ツールを使用してすべてのファイルを手動でマージしたいのですが、Git でこれを行うにはどうすればよいですか?
実行git mergetool すると、と表示されますno files need merging。だから、私は衝突がある場合にのみそれを行うことができると思います.

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

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

私はこれで終わりたい：

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

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

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

Web アプリケーション プロジェクトで Maven の使用を開始したため、ディレクトリ階層が変更されました。Maven 統合用の新しいブランチを作成しました。現在、古いディレクトリ階層を持つブランチと、maven ディレクトリ階層を持つブランチの 2 つがあります。両方のブランチに新しいコミット (バグ修正と新機能) があります。

古いブランチを取り除き、その変更を Maven ブランチにマージしたいと思います。Git マージは、解決できないと思われる無数の競合を引き起こします。これは、ファイルパスが変更されたためだと思います。

このマージにアプローチする最良の方法は何ですか?

ときどき、git で奇妙な動作が発生することがあります。あるブランチのファイルに加えた変更は、同じファイルに無関係な変更が加えられた別のブランチにマージすると削除されます。

私が支店長から始めたとしましょう。何が起こるかの大まかな概要は次のとおりです。

この時点で、master ブランチの foo.txt に加えた変更が削除されていることがわかります。

私は他にも多くの変更を加えており、これらすべての途中で他の git 操作を実行しています。このようなマージは git の全体的なポイントであるため、ある時点でおそらく何か間違ったことをしているように感じます。

誰にも何のアイデアがありますか？

私にはたくさんの枝があり、それぞれが異なる機能を持っています。通常、次のようなマスターと機能Aを含む追加のブランチ「not_master」があります。

機能Aのマージを解除したいが、コミットx,y,zは「not_master」のままにしておくことがあります。

言い換えれば、私はこれが欲しいです：

変更を元に戻すコミットを最後に追加することができるようgit revert -m 1 Mですが、これらのコミットはまだ公開されていないため、実際にはそうしたくありません。コミットを追加すると、履歴がさらに読みにくくなります。 。

他の人は、を実行することを提案しますgit reset --hard Mが、それはの変更をダンプしますx,y,z。私はこれを完全に間違った方法で考えているだけですか？git reset --hard Mx、y、zをチェリーピックする必要がありますか？

私は 2 つの「ブランチ」を持っています。どちらも同じコード ベースから始まりましたが、どちらも分岐後に git にインポートされました。以前の履歴は失われ、さらに、両方のブランチの git 履歴に大幅な変更が記録されています。

これら 2 つのブランチ間で機能のマージとバグ修正を管理しやすい方法で行うための適切な戦略は何ですか?

元のインポートの違いを意味のあるコミットに分離するのに役立つツールはありますか?

そこで、.gitignore ファイルにフォルダーを追加しました。

私がやると、git statusそれは私に教えてくれます

ただし、ブランチを変更しようとすると、次のようになります。

これは私の .gitignore ファイルがどのように見えるかです:

これらのファイルを削除せずにブランチを切り替えることができるようにするにはどうすればよいですか?

変更を加えた場合、それらのファイルに影響しますか? つまり、後でこのブランチに戻ってきた場合、最新のコミットまではすべて完璧でしょうか?

私はそれらのファイルを失いたくありません。追跡したくないだけです。

私は git を初めて使用します (そして、とても楽しんでいます!)。新しいブランチで開発している間、私は自分のアプリケーションのさまざまな開発「状態」をコミットし続けました。レビューのためにチェックインする必要がありますが、すべてを別のコミット (別のコメントと ID) に入れたくありませんでした。

初めてのようにすべての変更をプッシュするにはどうすればよいですか?

数年間、私は自分が取り組んでいる複数のプロジェクトを管理する方法を探していました。ひとつひとつが何らかの形で異なりますが、アプリケーションのコアはすべてに共通しています。現在のプロジェクトでいくつかの新機能を実装したとき、後で別のプロジェクトでそれらを使用するのは困難でした。実際にその機能を見つけるには、多くのプロジェクトを検索する必要がありました。

その後、git が登場し、プロジェクトの管理を改善するのに大いに役立ちました。アプリケーション構造全体とコア ライブラリ、ツール、およびモジュールが実装されている 1 つのスケルトン プロジェクトを作成しました。これは、私が開始する新しいプロジェクトごとのベースです。次のようになります。

スケルトンがマージする時間:

ここでは、プロジェクトの調整、ini ファイルの変更、カスタム テンプレート、モジュール、プレゼンターなどの追加を行います。今、プロジェクトはそれ自身の人生を生きています。しばらくすると、更新されたスケルトンとマージされます。

スケルトンからプロジェクトへのすべての変更を確認したいので、 --no-commit オプションを使用します。

そして今、私の質問が来ます。骨格を維持する最良の方法は何ですか? スケルトンをベースとして各プロジェクトに新しい機能を追加する場合、現在のプロジェクトにのみ関連する機能があります。しかし、アプリケーションのコアには機能があり、次のプロジェクトでもそれらが必要になるため、それらをマージしてスケルトンに戻す必要があります。

git/merge またはその他の git コマンドで、スケルトンを維持する方法が見つかりませんでした。そのため、プロジェクトとスケルトンを手動で比較し (ただし、me​​ld という優れたツールを使用)、スケルトン用の変更を適用してから、スケルトンにコミットしています。

プロジェクトをリモートとして追加し、プロジェクトをフェッチしてからスケルトンにマージするためにスケルトンを維持しようとしましたが、この方法では、プロジェクトのみのプロジェクトへのすべての変更がスケルトンに戻ってきて、無効です。