ファイルをマージするときは、(私にとっては)各行の作成者を表示すると便利です。それをサポートする差分またはマージツールはありますか?
3 に答える
バンドルされている gitk ツールは実際にはマージ ツールではありませんが、競合する行を赤と青で表示し、先頭に「+」を付けます。それらのいずれかで右クリック->「この行の起点を表示」すると、次の場所に移動できます。行を導入したコミット:
マージツールを実行するか、diffmarks を含むテキスト エディターを並行して実行できます。
したがって、あなたが本当に必要としているのは、各行の作成者を実際に識別するのではなく、マージの競合で他の変更と比較して自分の変更を簡単に識別できるツールです (これはそれを達成するための手段になります)。
私があなたを正しく理解していれば、比較的良いニュースがあります。それは git + kdiff3 で実行できます。マージするには、単に使用git mergetool
できます (kdiff3 を使用するように構成できます)。ただし、インタラクティブなリベースを実行しているときにマージの競合が発生した場合、ネイティブではサポートされていないため、手動でスクリプトを作成する必要があります。
私自身の単純なマージ競合の例を作成する代わりに、
http://www.gitguys.com/topics/merging-with-a-conflict-conflicts-and-resolutions/
をベースとして使用します。そのページに従ってgit merge test
. マージ コマンドの後から、別のコマンドを実行することで、その例とは少し異なります (ただし、基本的には同じ仕事をしています)。最初に手動ですべての手順を実行します。
そのため、マージの競合が発生し、git は両方のソースからのコンテンツをこの<<<<<<<...>>>>>>>
形式でファイルに挿入しました。代わりに、お気に入りのマージ ツールである kdiff3 を使用します。
まず、関連するバージョンを見つける必要があります。
$ git ls-files -u
100644 b0ed415d15862ac5582b51e4de65528e86934cd2 1 README
100644 56300e3ac4e4521c3500618a301bb2ab2d6a52f5 2 README
100644 9585db7d9c2d9ca05075f67a878f2554886d7b1a 3 README
$
その情報に基づいて、3 方向のマージを実行できます。
$ git cat-file blob b0ed415d15862ac5582b51e4de65528e86934cd2 > v1
$ git cat-file blob 56300e3ac4e4521c3500618a301bb2ab2d6a52f5 > v2
$ git cat-file blob 9585db7d9c2d9ca05075f67a878f2554886d7b1a > v3
$ kdiff3 -o merge_result v1 v2 v3 &
[2] 18394
$
これにより、マージ元の先祖から選択できる次のビューが表示されます。
あとがき (マージ結果に満足している場合) は、
$ rm v1 v2 v3
$ mv merge_result README
$ git add README
上記のすべての手動手順は、 で自動的に行われますgit mergetool
。では、なぜそれをすべて表示するのでしょうか。で対応する競合が発生した場合は、git rebase -i
(を実行する前に) そのように実行する必要があるためgit rebase --continue
です。
この小さな例では、競合する行が 1 つしかないため、多くの行が自動的に解決される典型的なケースを示しておらず、自動的に解決されなかった行を手動で解決する必要があります。より現実的な例は、次のようになります。
C
マージ結果に、自動的に解決された線の起点がはっきりと表示されていることに注意してください。これは、各行の著者を取得するように求めたときに、あなたが求めていたようなものだと思いますよね? その情報はテキストにはまったくありません<<<<<<<...>>>>>>>
(そして、hello 関数で出力された文字列を更新する必要があることを見つけるのは困難/不可能です)。
kdiff3 はあまりお勧めできません。このようなグラフィカル マージ ツールを使用することは、両方のソースからのいくつかの行がファイル内にインラインで混在しているのと比較して、掘削機とスペードを使用するようなものです。
いいえ。そして、決してそうなるとは思いません。合併するときは、著者ではなくコンテンツについて考えます。