3開発環境で機能モジュールを使用する方法
Features を多用するプロジェクトに取り組んでいますが、このアプリケーションには3つの開発者がいる場合があります。
いくつかのアプローチを試しましたが、gitブランチをマージすると、お互いの機能の変更が「上書き」されることがよくあります。競合がたくさんあり、機能モジュールが壊れて使いづらくなっているようです。
機能は、プロジェクトの構成に非常に便利で、これに取り組む方法があると確信しています。
競合や上書きのリスクを軽減するワークフローまたは手順はありますか？
機能に関する手がかりは大歓迎です。
マージの競合は、複数の開発者が構成をフィーチャーに統合しているときにおそらく発生するでしょう。機能コードを確認するためのいくつかのガイドラインを書きましたが、最も重要なのはこれです。
意図したコード変更のみをコミットします。
これは何を意味するのでしょうか？つまり、各開発者はコミットする前にコードをレビューする必要があります。開発者が注意せずに意図しないコード変更を防ぐ「魔法」はありません。
git diffでコードの変更を確認してください。git diff > blah.patchを使用して簡単な差分パッチを作成し、目的の構成変更のみが含まれるように手動でパッチを変更します。- 「mtime」などの情報、infoファイルのビューエクスポート内のコメントは、コミットに含める必要はありません。
- 時間の経過とともに構成コードの差分のブロックを確認することにかなり熟達しました。これで、ビューやパネルでの不要な変更を見つけるのが簡単になり、vimですばやく
10ddを使用すると、パッチの変更（たとえば）を取り除くことができます。 - 「ああ、ねえ、フィールドに関しては何も変更しなかったので、
featurename.features.field_base.incはコミットしません。」
git commit -aを使用しないでください。これはひどい慣習であり、使用しないようにする必要があります。常に明示的に追加してコミットしてください！- localgitブランチで
git rebaseを使用して、機能が最新であることを確認します。 - Gitマージ戦略は、実際にマージを行う場合にも役立ちます。
git merge -s recursive -X patience（git 1.7+ iircが必要）。
最後に、開発者にソーシャル制限を追加して、パッチレビューまたはプルリクエストのいずれかでトランク/ステーブルにマージする前に、コードをレビューしてもらう必要があることを検討してください。人々は社会的制限に腹を立てるでしょうが、彼らは自分のコードをレビューしないことに対して自分自身に腹を立てるべきです。