web-dev-qa-db-ja.com

3開発環境で機能モジュールを使用する方法

Features を多用するプロジェクトに取り組んでいますが、このアプリケーションには3つの開発者がいる場合があります。

いくつかのアプローチを試しましたが、gitブランチをマージすると、お互いの機能の変更が「上書き」されることがよくあります。競合がたくさんあり、機能モジュールが壊れて使いづらくなっているようです。

機能は、プロジェクトの構成に非常に便利で、これに取り組む方法があると確信しています。

競合や上書きのリスクを軽減するワークフローまたは手順はありますか?

機能に関する手がかりは大歓迎です。

19
stefgosselin

マージの競合は、複数の開発者が構成をフィーチャーに統合しているときにおそらく発生するでしょう。機能コードを確認するためのいくつかのガイドラインを書きましたが、最も重要なのはこれです。

意図したコード変更のみをコミットします。

これは何を意味するのでしょうか?つまり、各開発者はコミットする前にコードをレビューする必要があります。開発者が注意せずに意図しないコード変更を防ぐ「魔法」はありません。

  • 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が必要)。

最後に、開発者にソーシャル制限を追加して、パッチレビューまたはプルリクエストのいずれかでトランク/ステーブルにマージする前に、コードをレビューしてもらう必要があることを検討してください。人々は社会的制限に腹を立てるでしょうが、彼らは自分のコードをレビューしないことに対して自分自身に腹を立てるべきです。

7
mradcliffe