私たちの会社にはプロジェクトがあり、システムを作成し、それを他の会社に販売します。問題が発生しました。プロジェクト管理の問題です。各クライアントには独自のシステムが必要です。私たちのシステムも開発されています。これらのプロジェクトの開発。
gitブランチ機能を使ってみましたが、お客様は自社開発プロジェクトをマスターするブランチであり、上記のブランチのお客様向けにカスタマイズされています。
各マスターの更新は、何よりもブランチのリベースで使用されます。
しかし、数日後、マスター、リベースが頻繁に変更されたため、多くの競合が発生しました。当時、私たちは多くの紛争解決に費やしました。時間コストが高すぎる。
どうすればいいですか？
これは解決が難しい問題です。ここにいくつかの考えがあります：
コーディング スタイルがきれいであればあるほど、master の上にクライアントをリベースするのが簡単になります。Bob Martin 著の「Clean Code」などの本には、単純でクリーンな再利用可能なコードの書き方に関する情報がたくさんあります。すべての重要なポイントの 1 つは、クリーンなコードは簡単に変更できるということです。これにより競合を修正する必要がなくなるわけではありませんが、修正が容易になる可能性があります。Michael Feathers による「Working Effectsly with Legacy Code」や、Fowler、Beck などによる「Refactoring: Improving the Design of Existing」などの本は、マスターをクリーンアップしてブランチでより適切に動作させる方法を理解するのに役立つかもしれません。 、しかし、私はそれを約束することはできません.
良い抽象化が役立ちます。10 人の顧客が必要とするものがある場合は、10 人の顧客ブランチに入れないようにします。他のものを壊さずにきれいにマスターに移動してから、その新しいコードをブランチで使用してください。他の支店/顧客は、安全に無視できるはずです。
顧客の詳細をコードからデータに移すようにしてください。コードに顧客固有の設定がある場合は、それらを text/JSON/YAML ファイルに移動します。各顧客ブランチには、これらのファイルの独自のバージョンがあり、マスター ブランチにはありません。これで、これらの設定を使用するコードの部分に取り組み、必要に応じて拡張することができます。そうすれば、すべての顧客がそのコードを持つことになりますが、設定は各ブランチで実際に何が起こるかを決定するのに役立ちます。このように競合はありません。
顧客固有の機能をプラグインまたはヘルパー スクリプトに移動します。これは上記の #3 のようなものです。ファイルが存在しない場合でも、マスターと競合することはありません。顧客がカスタム フォーマッタを必要とする場合は、formatter.foo をブランチに置き、そのブランチのメイン コードでそのフォーマッタを呼び出すだけです。メイン プログラムで競合が発生した場合、少なくとも 1 つのインポート行、またはインポートされたファイル内の関数を呼び出す行に競合が発生します。
また、これにはリベースを使用しません。master を他のブランチに再統合マージし続けます。リベースは契約を少し破ります。「このブランチはここから始まりました」と表示されます。それは正しくありません。また、存続期間の長いブランチを頻繁にリベースすればするほど、真実ではなくなります。Git は各コミットですべての変更を適切に行うため、コードは引き続き機能しますが、リファクタリングされた可能性のあるセクションの上を移動し続けるため、コード コメントが同期しなくなる可能性があります。コメントには「foo の問題を修正しました」と書かれているかもしれませんが、30 コミット前に「foo」の名前が「bar」に変更され、そのメッセージを読んでいる人はコードに foo を表示しなくなりました。あちらへ。マージすると、ベースがそのまま残り、物事が最初に作られたときの歴史がどこにあったのか、適切な感覚を与えてくれます。また、ブランチが長くなればなるほど、すべてのコミットを再びトップにリベースするのに時間がかかります。マージは新しいものだけをもたらします。