リリースカレンダーによると、次のgitリリースの機能のリストが凍結されるまで数週間しか残っていません（1.7.10）。これには、下位互換性に違反し、スクリプトでマージを使用するユーザーを危険にさらすgit mergeの作業の改善が含まれます。
Jake Edgeのアドバイスに従うことにしました。「ほとんどの無料プロジェクトでは、実装前に計画された変更について話し合い、リリースのかなり前にユーザーに新機能をテストする機会を与えます。 この段階でのプロジェクトへの最善の支援は、既存の問題、欠落している機能などの明確な実証された具体的な説明であり、メーリングリストまたはコメントのメッセージ「Project XYZ AUGUST !!! 11」の終わりのないストリームではありません
したがって、私たちの決定、それが行われた理由、および今後のリリースのユーザーが自分の仕事でそれを使用する方法について説明します。
git mergeが2つ以上のブランチをマージしようとすると、説明が生成されます-どのブランチがマージに関与し、自動マージが成功した場合、このスタブはユーザーの介入なしにコミットの説明として書き込まれます。 自動マージが失敗した場合、ユーザーがすべてを自分で修正し、git commitを使用して結果を記録する機会をユーザーに与えます。
ほとんどの合併は問題なく行われ、この行動の理由を説明する必要がある状況でも、ためらうことなく人々を合併させたのはこの振る舞いです。 マージが成功した後、マージの理由の説明を記入するためにgit commit --amendを呼び出す必要はありません。
最近、Gitメーリングリストで、Linusは、この動作がGitのvery明期に行われたシステム設計エラーであることに気づきました（そして、私は彼に同意します）。 そして今、1.7.10から、コンソールでgit mergeを開始すると（標準入力と出力が端末に接続されます）、エディターが開き、コミットの説明を作成して、ユーザーに行動の理由を説明する機会を与えます。
ユーザーがこの変更に慣れるのに役立ついくつかの推奨事項を示します。
（1）git mergeがコマンドラインから起動されると、2つのオプションが可能です：
-更新されたアップストリームを、新しい機能に取り組んでいるブランチ（トピックブランチ）に注ぎます。 本当の理由がないこのような合併は悪い習慣です。 このような「間違った」方向への統合は、たとえばアップストリームで最近採用された改善に新しい機能が依存している場合など、どうしても必要な場合にのみ行う必要があります。 それ以外の場合、ブランチは機能の1つのユニットに関連するコミットを含むことをやめ、代わりに、異なるソースからのコミットのダンプになります。 この場合、次のように、新しいgit merge動作が好まれます。 理由を見つけるために修正を呼び出す必要はありません。
-新しい機能を備えたブランチを統合ブランチ（またはテストブランチ）に注入する場合、通常、合併の理由はコンテキストから明らかです。完成した機能をプロジェクトに注ぎます。 この場合、--no-editパラメーターをgit-merge呼び出しに渡し、編集せずに準備されたメッセージを受け入れることができます
（2）git mergeを実行するスクリプトがあり、標準入力および出力ストリームをターミナルに関連付けたままにしておくと、スクリプトはユーザーにマージの理由を尋ねます。 これは望ましくない場合があります。 たとえば、このようなスクリプトは、多くの場合、多数のブランチをテストブランチに大量にマージするために使用され、このような自動マージが可能な限り非対話型のままにする必要があります。 この場合、明らかに、チームの古い動作を維持することをお勧めします。 すべてのgit merge呼び出しに--no-editを追加する必要はありません。 代わりに、スクリプトの先頭で環境変数MERGE_AUTOEDIT = noを定義すると、git mergeは最初の競合が発生するまで静かにコミットします
リリース前に1.7.10を試して、スクリプトと習慣を調整してください:)
以下に関するご要望がある場合：
-ドキュメント
-エラー、推奨事項、その他のメッセージ
-インタラクティブな起動を決定するためのロジック
git@vger.kernel.orgメーリングリストでお客様からのご連絡をお待ちしています
インタラクティブなマージ中にエディターを起動するという事実は議論されていません。 Linusが言ったように-デフォルトが重要-そして以前のマージの振る舞いは本当に悪い「デフォルト」だった
環境のGitユーザーにこのニュースを知らせて、習慣を変え始めることができるようにします。