オフィスに Git を実装しようとしています。各開発者マシンで apache サーバーを実行することはできないため、自分のマシンでクローンを使用することはできません。NFS共有を備えた開発サーバーがあります。この NFS 共有に git リポジトリとワーキング ツリーを作成する予定です。Git は 1 人のユーザーによって管理されるため、同時プッシュはありません。
私の質問は
- それは良い習慣ですか?
- ユーザー アクセスを管理するにはどうすればよいですか?
私が理解していることを確認するためにここでもう一度言います: 全員が NFS 経由でマウントし、リモート apache インスタンスを指すブラウザーを使用して開発する共有開発「作業領域」、彼らは同じファイル セットで作業し、同じファイルに対して git コマンドを実行します。 git 作業コピー。これまでの私の理解が正しければ、それは良い考えではないように思えます。
各開発者には、apache サーバー上の独自の作業領域と、独自の VirtualHost を提供して、独立したファイルを表示できるようにすることをお勧めします。現在、彼らは他の開発者から独立して作業することができます。これらのファイルの各セットは、同じリポジトリ (おそらくどこかの裸のリポジトリ) の git クローンになります。これにより、各開発者にとってより健全な開発ワークフローが可能になり、開発者が互いに踏みにじったり、他のコードをコミットしたりするリスクがなくなります。
ユーザー アクセス。これは、NFS 共有のマウントを誰に許可するかによって制御できます。
git は NFS 上で動作しますが、ローカル ディスクに比べて非常に遅いです。
複数の開発者が同じチェックアウト リポジトリで作業していると、問題が発生します。
開発者がプッシュおよびプルするサーバー上に「アップストリーム」マスター リポジトリをセットアップし、各開発者は自分のワークステーションでローカルにマスター リポジトリを複製し、それに対して作業します。
あなたはまさにgitの目的、すなわち分散開発を無効にしています。「公式」リポジトリを保持する中央サーバーにGitoliteのようなものをセットアップすることをお勧めします。開発者は、このリポジトリのクローンを作成して、ローカル エリアで作業できます。その後、(十分にテストされた) 変更を公式リポジトリにプッシュできます。gitolite を使用すると、きめの細かいアクセス制御とその他のいくつかの管理ツールを使用できます。公式リポジトリからの変更のみを本番環境にプッシュできるように、ビルドおよびデプロイ プロセスを設定する必要があります。