2 人の開発者が作業コピーを共有することは本当に望ましくありません。この場合、安全を確保する方法はありません。2 人が同時に同じファイルを編集しようとするとどうなるでしょうか。
gitにはマージ競合管理用のツールがたくさんありますが、進行中の作業のために 2 つの開発者が 1 つのリポジトリを共有している場合、それらはどれも役に立ちません。
代わりに、各開発者が独自のテスト環境を持ち、ローカル コピーに加えられた変更が機能するかどうかを評価できるように設定します。変更を「リリース」する準備ができたら、中央の共有リポジトリにプッシュします。その中央レポジトリのコードは、最終的に本番環境に移行します。
開発者が変更をテストするために使用する Web サーバーは、おそらく特別なものである必要はありません。たとえば、Python には組み込みの小さな Web サーバーがあり、python -m SimpleHTTPServer. HTML および Javascript プロジェクトのテストには、このサーバーまたは同様の小さなサーバーで十分です。セットアップがより複雑な場合でも、開発者ごとに「ステージング」コピーを作成できます。データベース、Web サーバーなどを複製します。全力を尽くしたい場合は、ライブ環境の完全な複製を使用して、クローン化された仮想マシンで各開発者が作業するようにします。
メイン リポジトリに入るコードが適切であるという本当に強力な保証が必要な場合は、Gerritのようなゲートキーパー システムやJenkinsのような自動ビルダーを使用してください。3 人のチームの場合、各開発者が自分の変更をプッシュする前に再確認するだけで十分でしょう。
作業コピーを共有する必要がある場合は、古いシステム (CVS スタイルのロック) にフォールバックする必要があります。開発者がファイルに変更を加える前に、「チェックアウト」する必要があります。「チェックアウト」されている間は、他の開発者はそれに触れることができません (読み取り専用にします)。誰かがコミットする前に、あなたは同僚に「やあ、私がコミットしている! 誰も何もしない!」と大声で言います。次に、git add -iまたは同様のことを行い、コミットしてから、すべてが明確であり、続行できることを他の全員に伝えます。これは悪い方法です。やらないでください。
ライブ Web アプリケーションの更新に使用するベア リポジトリを作成し、開発者ごとにテスト環境 (個別の Tomcat インストールまたは仮想ドメイン) をセットアップするか、開発者に Web アプリケーションの非ライブ インストールを編集させることをお勧めします。
どちらの場合でも、ワークフローは開発者の観点からは次のようになります。
$ cd ~/webapp
$ git add file.html
$ git commit -m "Updating file to perform task."
$ git push origin
$ cd /path/to/production/webapp
$ git fetch origin
$ git merge origin/testbranch
フローは、Web アプリの 1 つの作業コピーを使用するよりも少し長くなりますが、これにより、各開発者は Git を最大限に活用できます。すべての開発者が同じ作業コピーを共有している場合は、RCS のようなファイルごとのリビジョン管理システムを使用することもできます。