私は最終的にはオープンソースになるプライベートプロジェクトに参加しています。私たちには、アプリを構築するための技術に十分な才能がある少数のチームメンバーがいますが、クリーンで美しい、最も重要な長期保守可能なコードを書くことができる専任の開発者はいません。
コードベースのリファクタリングを開始しましたが、定期的に連絡を取り合っていない別の国にいるチームの誰かがこのまったく別のものを更新する可能性があるため、少し扱いにくいです。
解決策の1つは、迅速に通信するか、より良いPMプラクティスを採用することですが、まだそれほど大きくはありません。コードをクリーンアップして、彼が更新したものにうまくマージしたいだけです。ブランチを使用することは適切な計画でしょうか？ベストエフォートマージですか？他に何か？
回答:
よく考えられないことの1つは、クリーンアーキテクチャは長期的なメンテナンスを高速化するだけでなく、現在の開発も高速化することです。変更が完了するまで、変更を同僚から隔離しようとしないでください。変更により、生産性が向上し、バグが発生しにくくなります。
大規模なリファクタリングを行うときに人々が犯す最も頻繁な間違いは、十分な頻度でマージしないことであり、代わりに1つの「ビッグバン」でそれを行おうとすることです。それを行う正しい方法は、可能な限り最小のリファクタリングを行い、それをテストし、それを同僚のブランチにマージし、変更を教えて、今後それを組み込むことができるようにすることです。理想的には、1日に1回、または少なくとも1週間に1回のマージを実行します。
あなたは決して「コミュニケーションするのに十分な大きさ」ではありません。指で入力できる場合は、唇で話すこともできます。結局のところ、技術の向上は、85％のコミュニケーションと15％の技術です。誰かと難しい会話をするよりもコーディングするほうが好きだからといって...良いアイデアだとは限りません。コミュニケーションは実際にあなたがしようとしているものの難しい部分ですが、それを避けるだけではありません。
はい、ブランチはこれに適したソリューションです。
ブランチでこの作業を開始し、それが現在の現在の上にきれいに適用されることを確認することをお勧めしますHEAD（つまり、定期的にテストのリベースとマージを行い、変更を簡単に適用してテストが合格することを確認します- -また、これに関するヘルプを探しますgit rereregit）。その後、リベースが完了したら、変更をにマージしますHEAD。
アーキテクチャの変更はますます多くの作業を行うようになるため、コードの作業は冷たくなるので、この作業を開始するのは早ければ早いほどよいです。また、コードベース全体にハンドコードされたコードの多くのインスタンスが散在している可能性があります。たとえば、新しいヘルパー関数を使用すると、物事がずっと簡単になります。
「まだやらない」というオプションを検討しましたか？
別のブランチでこの作業を行うのがおそらく最善の方法ですが、将来的には非常に痛みを伴うマージのために自分自身をセットアップしています。
他の人は、おそらく多くの新しい機能を追加し、既存の機能を変更し、場合によっては一部の機能を削除するでしょう。
主流の開発者が働いた後、将来のある時点で少し遅くなると、リファクタリングするのがはるかに簡単になるでしょう。
tl; dr-大リーグにステップアップする時が来たようですね。豚に口紅をつけても、そのようなことに興味がない限り、きれいになりません...
人々の問題
最初の問題は、同期のコミットです。複数の人が同じコードで同時に作業している場合、問題を防ぐために必要なルールは1つだけです。
Rule 1: Always pull before you merge/rebase
DVCSに関しては、リモートブランチ（メインリポジトリ）に変更を加えることは難しく、ローカルに変更することは非常に簡単です。すべての人は、問題なくコード全体をより大きな全体に適合させる責任があります。2人がまったく同時にコミットしない限り、経験するべきではありません。オリジン/リモートマスターへのコミットアクセスは少数の開発者のみに限定し、リモートトラッキングブランチを介して他の開発者から変更をプルする必要があります。
コードの問題
あなたが行った変更がコードを壊さないことをどのように知っていますか？
簡単な答え...テストを書いて、そうでないことを証明してください。TDD（Test Driven Design）の考え方を無視する場合、テストのポイントは、コードを壊すことなくコードを変更できる検証レベルを追加することです。
Rule 2: Don't make assumptions, write proofs (ie tests).
これに加えて、オリジン/リモートマスターにプッシュする前に、テストの全範囲を実行する必要があります。
コミットはできるだけ小さく、簡潔にしてください。そうすれば、後で何かを壊した変更を取り消す必要がある場合、コードを壊さなかった部分を再実装する必要がなくなります。
最初に組織の再構築が必要になる場合があります
上記のソリューションを簡単に適用できない場合、おそらく最初に対処する必要がある開発構造にいくつかの問題があります。
プロジェクトの所有者はゲートキーパーでなければなりません。コミット同期の問題がある場合、おそらくコミットアクセス権を持つ人が多すぎます。Linuxカーネルのような大規模なプロジェクトでも、少数の開発者のみがオリジン/リモートマスターリポジトリへのアクセスをコミットしています。実際には、コミットを管理するための複数レベルのリポジトリがあります。すべてのユーザーが変更をオリジンにプッシュする単一レイヤーコミットモデルの代わりに、階層モデルには、プロジェクトに含める前に変更を取得して品質を検証するゲートキーパーがあります。階層コミットモデルは、品質を犠牲にすることなく、単層モデルよりもはるかに大きく効果的にスケーリングできます。
開発者ので、アクセスをコミットされません。開発者のために、彼らは（gitのとgitoriousは、このために良いです）、独自のリモート追跡ブランチを作成することを学ぶ必要がありますコミット権を持っているが、簡単に、原点に支店を統合/引っ張ることができます。変更が小さい場合、パッチも同様に機能します。
マージ/リベースを行う前に変更をプルする機能は、ローカルマスターブランチで開発していないことを前提としています。これを処理する簡単な方法は、コーディングを開始する前に最初のプルを行い、そのブランチですべての作業を行うことです。難しい方法は、マージする直前に分岐してマスターをロールバックすることです。
プロジェクト全体のコーディングスタイルを定義し、開発者がそれに従うようにします。貢献する開発者は、クリーンアップを最小限に抑えるために、プロジェクトの標準/規範に準拠するコードを記述する必要があります。コーディングスタイルは、オープンプロジェクトの大きな自我の障壁になります。標準が設定されていない場合、誰もが自分の好みのスタイルでコーディングし、コードベースは非常にく非常に高速になります。
「The Mythical Man Month」の神話
信じられないかもしれませんが、大規模/成功したオープンソースプロジェクトは、民主主義のようには運営されていません。それらは階層として実行されます。プロジェクトが8〜10を超える開発者を効果的に成長させることはできないと述べるのは単純です。もしそうなら、Linux Kernelのようなメガプロジェクトは存在しません。より深い問題は、すべての人にコミットアクセスを許可すると、効果的なコミュニケーションが扱いにくくなることです。
神話上の人月の問題は実際に克服することができます。軍事のようにプロジェクトを実行するだけです。階層には多くのレベルがあります。なぜなら、個々の人は実際にはほんの一握りの人とのコミュニケーションを管理するのに効果があるだけだというのが一般的な知識だからです。1人の個人が5〜7人以上の作業を管理する責任を負わない限り、システムは無制限に拡張できます。
最良の開発者や経験のある開発者がより多くの統合とより高いレベルの設計/計画を行うことに制限されるかもしれませんが、それは悪いことではありません。スケールアップの一環として、プロジェクトに長期計画が必要であると判断する動きがあります。プロジェクトの将来に最大の投資（時間もリソース）を持っている最高レベルの人々は、大きな決定を下す責任があります。
オープンソースプロジェクトの成長の痛みについて聞いてうれしいです。おめでとうございます。
クリーンで美しい、そして最も重要なことは、長期にわたって保守可能なコードです。
私の経験では、クリーン/ビューティフルは保守可能の敵です。しばしば美しいコード：
一方、保守可能なコード：