追記型のファイルでマージ時のコンフリクトを避ける工夫どうしてますか

Question

プロジェクトディレクトリ内で、開発のたびに追記されていくファイル、もしくはファイル上の追記されていくリストというのがあります。

• パッケージ管理ファイル
• URLルーティング定義ファイル
• ソース上部のimport, include, require宣言的なリスト
• ユーティリティ関数を集めたファイル。関数を追加するときは大体最後に追加する。
• テストコード。新しいテストを（以下略

これらのファイルもしくはパート、複数のフィーチャーブランチを切って並行開発していると大抵マージのときにコンフリクトします。
解決も簡単なのですがコンフリクトというのは自動マージやチェリーピックの妨げになって発生すること自体が邪魔です。

ファイルの種類によってもノウハウが異なってくることとは思いますが、コンフリクトを避けるための工夫でやっていることがあったら教えてください。

Answer 1

こんにちは。

機械的な解決手段として、.gitattributesを使うことで管理対象ファイルの取り扱いをカスタマイズすることができた気がしたのでちょっと調べてみました。

.gitattributesファイルを管理対象ディレクトリの直下に配置し、.gitignoreと同様の記法で対象ファイル/ディレクトリを指定し、merge属性にdriverを指定することで、既定のマージ方法をファイル単位で変更することができました。

パッケージ管理ファイル等の追記ファイルであるなら、gitのbuild-in merge driverであるunionを指定することで競合を回避してマージできます。これは、お互いの変更が競合したとき、両方の変更後を並べて取り込んでしまうというシンプルなマージドライバです。なかなか使える場面は限られそうですが、追記専用ファイルには最適だと思います。
厳密な話は公式ドキュメントを読んでみてください。
docs/gitattributes

もっと細かくマージ手法をカスタマイズしたい場合、.git/configに自作のマージドライバを定義することができます。シェルスクリプト等でマージ処理を記述し、成功あるいは失敗を返します。githookのような感じですね。
ちなみに、自作driverが何もせずにtrueを返すと、マージ処理開始時のインデックスツリーの状態をマージ成功状態として扱うため、「自分の持つファイルで相手を上書き」する動作になるようです。いわゆる--ours指定ですね。
詳しい情報は以下にあります。
book/Customizing-Git-Git-Attributes

Comments

[yuba]

マージ方法は選べる的なことをちらっと聞いたことがあったのですが、まさにこのような使い方をするのですね。詳細な解説、ありがとうございました。

Answer 2

このサイトがお役に立ちそうです。→ココ

Answer 3

ずーっとこのトピックに興味があって、回答ではないですが、調べてみた結果、2通りくらいのアプローチがあるらしいです。

https://about.gitlab.com/2015/02/10/gitlab-reduced-merge-conflicts-by-90-percent-with-changelog-placeholders/

A. ハイフンプレイスホルダー方式

多分、次のリリースに向けてChangelogの先頭を以下の様にして、変更内容をランダムに追記、リリース前に空いたハイフンプレイスホルダー行を整理するという方式だと思います。

Release version x.y.z (2017-MM-DD)
-
-
-
... (ずーっとハイフンだけの行が続く)
-
-

B. ユニオンマージ方式

よく調べてませんがgitのマージストラテジを変更して対応する様です。

Comments

[yuba]

ランダムな位置に追記する方式、まず同僚と思いついて「でも結局確率的出しなあ」とシステマティックな方法を探していたところでした。

ユニオンマージ方式、これが本命になりますね。
調べてからお礼を変えそうと思っていたら時間が経ってしまいました。失礼しました。

[YouheiSakurai]

いえいえ、全然失礼ではなかったです。有益な質問をありがとうございます。