他の人がすぐにコミットする一方で、コードベースをリファクタリングするにはどうすればよいですか？
私は最終的にオープンソースになるプライベートプロジェクトに参加しています。アプリを構築するためのテクノロジーには十分な才能があるチームメンバーが何人かいますが、クリーンで美しい、最も重要なのは長期的に保守可能なコードを作成できる専任の開発者ではありません。
私はコードベースのリファクタリングに着手しましたが、私が定期的に連絡していない別の国にいるチームの誰かがこのまったく別のものを更新している可能性があるため、少し扱いにくいです。
PMプラクティスを迅速に伝達または採用することの1つの解決策は知っていますが、まだそれほど大きくはありません。コードをクリーンアップして、彼が更新したものにうまくマージしたいだけです。ブランチの使用は適切なプランでしょうか？ベストエフォートのマージ？他の何か？
よく考えがちなことの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人が同時に犯さない限り、経験するべきではありません。 Origin /リモートマスターへのコミットアクセスは数人の開発者のみに制限されるべきで、リモート追跡ブランチを介して他の開発者から変更をプルするべきです。
コードの問題
行った変更がコードを壊さないことをどのようにして知っていますか？
簡単な答え...テストを書いて、そうでないことを証明します。 TDD（テスト駆動設計）の考え方を無視する場合、テストの全体のポイントは、コードを壊すことなくコードを変更できるようにする検証レベルを追加することです。
Rule 2: Don't make assumptions, write proofs (ie tests).
これに加えて、Origin /リモートマスターにプッシュする前に、テストの全範囲を実行する必要があります。
コミットはできるだけ小さく簡潔にしてください。そうすれば、後で何かを壊した変更を取り消す必要がある場合、コードを壊さなかった部分を再実装する必要がなくなります。
最初に組織の再構築が必要になる場合があります
上記のソリューションを簡単に適用できない場合は、開発構造にいくつかの問題があり、最初に対処する必要があります。
プロジェクトの所有者はゲートキーパーである必要があります。コミット同期の問題がある場合は、おそらくコミットアクセス権を持つ人が多すぎます。 Linuxカーネルのような大規模なプロジェクトであっても、Origin /リモートマスターリポジトリにコミットアクセスできる開発者はごくわずかです。実際には、コミットを管理するための複数レベルのリポジトリがあります。誰もがOriginに変更をプッシュする単一レイヤーコミットモデルの代わりに、階層モデルには、プロジェクトに含める前に変更をプルして品質を検証するゲートキーパーがあります。階層コミットモデルは、品質を犠牲にすることなく、単一レイヤーモデルよりもはるかに大きく、より効果的にスケーリングできます。
コミットアクセスを取得しない開発者は、独自のリモートトラッキングブランチを作成する方法を学ぶ必要があります（gitとgitoriousがこれに適しています）。開発者はdocommitアクセスがあると、ブランチを簡単にOriginにプル/統合できます。変更が小さい場合、パッチも同様に機能します。
マージ/リベースを行う前に変更をプルする機能は、ローカルマスターブランチで開発していないことを前提としています。これを処理する簡単な方法は、コードを書き始める前に最初のプルを行い、そのブランチですべての作業を行うことです。難しい方法は、マージする直前に分岐してマスターをロールバックすることです。
プロジェクト全体のコーディングスタイルを定義し、開発者がそれに従うようにします。貢献する開発者は、クリーンアップを最小限に抑えるために、プロジェクトの標準/規範に準拠するコードを作成する必要があります。コーディングスタイルは、オープンプロジェクトの大きな自我の壁になる可能性があります。標準が設定されていない場合、誰もが独自の好みのスタイルでコーディングし、コードベースは非常に醜く非常に速くなります。
「The Mythical Man Month」の神話
信じられないかもしれませんが、より大規模で成功したオープンソースプロジェクトは、民主主義のようには運営されていません。それらは階層として実行されます。プロジェクトが8〜10人の開発者を超えて効果的に成長できないと述べることは、単純です。もしそれが本当なら、Linuxカーネルのようなメガプロジェクトは存在しなかったでしょう。より深い問題は、全員にコミットアクセスを与えると、効率的なコミュニケーションが扱いにくくなることです。
神話の男月の問題は実際に克服することができます。あなたは軍のようにあなたのプロジェクトを実行する必要があるだけです。個々の人々は実際にはほんの一握りの人々とのコミュニケーションを管理することにおいてのみ効果的であるというのは常識であるため、階層内には多くのレベルがあります。 1人の個人が5〜7人以上の作業を管理する責任を負わない限り、システムは無制限に拡張できます。
それは、最高の/経験豊富な開発者がより多くの統合とより高レベルの設計/計画を行うことを制限するかもしれませんが、それは悪いことではありません。スケールアップの一環として、プロジェクトには長期計画が必要であると判断する動きがあります。将来のプロジェクトに最大の投資（時間もリソース）を持つ最高レベルの人々は、大きな決断を下す責任を負うべきです。
オープンソースプロジェクトがますます困難になっていることを聞いてうれしいです。おめでとうと幸運。