中央開発サーバー（LAMP）でバージョン管理を管理する

私は最大5人の（ウェブ）開発者がいる小さなチームで働いています。私たちのチームは頻繁に成長しており、複数の人が同じコードで作業しているときに問題が発生したため、VCSをセットアップすることにしました。

現在の状況

現在、中央開発サーバー（LAMP）を使用しています。したがって、すべての開発者が同じコードベースで作業し、コードがテストされてライブサーバーの準備ができている場合は、ftp経由でコードをコピーするだけです。私はこれがanno 1600ワークフローの一種であることを知っていますが、そうです。それが何であるか、そしてこの質問の理由でもあります。

開発サーバーでは、ディレクトリ構造は次のようになります。

/var/www 
      /Project1 
      /Project2 
      /Project3 
      ...

さらに、いくつかの小さな非Webアプリケーション-Android / iPhone / Windows 8などのアプリといくつかのC＃ツールもあり、これらもVCSに含める必要があります。

目標と問題

私たちの目標は、VCSのクリーンセットアップを取得することです。VCSは、問題追跡ソフトウェアと連携し、コードを上書きせずに同じプロジェクトで同時に作業できるようにし、バージョン管理の利点を提供します。

私たちにとっての最初の質問は、どのテクノロジーを使うべきかということだと思います。私たちの一部は、すでに転覆を経験しています。しかし、gitはある種の「標準」になり、多くの「プロgit」の議論がWebユーザーの間で存在するため、私たちはgitを使用する傾向があります。

不確実性が始まります。git-分散型VCS-を使用する場合、各開発者のコ​​ンピューターで別個の開発サーバーの使用を開始する必要があるようです。それに関する問題は次のとおりです。

• ときどき別のコンピューターで作業するため、コードのプッシュを忘れると問題が発生します。
• 開発サーバーはライブサーバーと同じである必要があるため、仮想マシンで作業する必要があります（これは私たちの環境では強制できないため、不可能だと信じています）。
• 開発サーバーは通常、「トライアウト」または「プレゼンテーション」サーバーとしても機能し、開発者以外の人が何が起こっているのかを確認できました。

単一の（！）開発サーバーを使用しながらシステムから利益を得ることができるように、gitで別の可能なセットアップはありますか？たぶん、開発者ごとに異なるディレクトリがあります。または、作業中のファイルをロックし、リポジトリにコミットして、同じコードベースで作業することはできますか？それが私たちにとっての要因になった一方で、複数の開発者がアプリケーションの同じ部分で同時に作業することはまだ珍しいと言うことが重要かもしれません。

あなたはここで正しい軌道に乗っています。

多分、開発者ごとに異なるディレクトリがあります。

はい、開発者ごとに間違いなく異なるディレクトリです。

あなたが使っているマシンはかなり面白くないです。各開発者が自分自身としてログインし、自分のホームディレクトリにあるgit repoのコピーをチェックアウトすることを確認してください。ファイルシステムにいくつかのコードのコピーが存在することになりますが、ディスクは無料です。

git が分散操作をサポートしていることは事実です。ただし、通常のワークフローではこの方法を使用しません。便利なサーバー上でベアリポジトリが利用可能であることを確認し、そこから全員をプルしてください。必要に応じて、http、ssh、またはファイルシステムを介してアクセスします。

ワークフローの一部として「トライアウト」領域について言及しました。自分でお願いします。Jenkinsという別の開発者を雇ってください。この開発者もgitを使用してコードをチェックアウトしています。彼はここに実装されています：http : //jenkins-ci.org/ （そしてhttp://tomcat.apache.org/download-70.cgiで実行されます）。そうすれば、セントラルリポジトリにプッシュするたびに、Jenkinsのホームディレクトリの下でWebサイトの更新されたバージョンがすぐに利用できるようになります。これを継続的統合と呼び、ワークフローを確実に改善します。

 It's maybe important to say that while it became a factor for us it is still uncommon that multiple developers work on the same part of an application at the same time.

同じマシンと同じコードベースで作業する人がほとんどいない場合は、問題が発生します。上書きのため、また何かが壊れた場合、他の人は修正するまで待たなければならないためです。

いくつかの環境を区別する必要があります。あなたは3つ（非常に一般的）を必要とするようです：

• Production-プロジェクトが実際にエンドユーザーによって使用される場所。
• ステージング -開発者が自分の作業を他の開発者とマージしてテストし、場合によってはクライアントがこの領域を覗くことができる場所。
• 開発 -各開発者が他の人とマージする前に一人で作業します。

通常の開発環境とは、マシン開発者が作業することを意味します。共有マシンに保存したい場合は、それも可能です。環境とマシンは切り離されたものです。プロジェクトごと、開発者ごと、環境ごとに異なるコードベースが必要です。

したがって、Gitと社内の5人の開発者の場合、開発環境用に5つのリポジトリがあります。以下のために、ステージング、それは非裸のリポジトリにプッシュするのは良い考えではないので（コードをマージ）環境あなたはそこにコードをテストし、クライアントの現在の状態を示すためにマージし、別のもののレポが必要になります。場合は、生産サーバーがGitリポジトリに別のものを持っています。そうでない場合は、ステージング環境からFTP経由で本番環境にファイルを転送するだけです。したがって、各プロジェクトのリポジトリはほとんどありません。

ワークフローは次のようになります。開発環境で作業し、機能を追加したり、バグを修正したりすると、ステージング環境のベアリポジトリに変更をプッシュし、これをベアではないリポジトリにプルします（Gitフックで一度に実行できます）。 、そしてプロジェクトが新しいバージョンをリリースする準備ができたら、それをプロダクションにプッシュ（またはFTP経由で転送）します。

ときどき別のコンピューターで作業するため、コードのプッシュを忘れると問題が発生します。

あなたがしなければならない場合はまあ開発あなたはrsyncのようなものを介してサーバにローカルマシンからファイルを同期する、またはネットワークドライブまたは何をマッピングすることができる非常に同じ共有サーバー上の環境をしかし、これは常に少し遅くなります、ローカルマシン上で作業します。しかし、地元で働くことはあなたが言及する問題を抱えています。VCSがなくても。FTPを使用するときのように-マシンで何かを変更し、それを転送するのを忘れた場合-同じことが起こります。しかし、逆アセンブルされたコードをステージング環境にマージしたくはないでしょう。それは共鳴する状態に達するまで開発を続けなければなりません。

We would have to work with virtual machines because the dev servers should be the same as our live server (This would simply not be enforceable in our environment, believe me it's not possible).

GUIを使用しないwevサーバーは多くのリソースを使用しません。私はあなたたちがコードに取り組み、それを自分のマシンでみんなでテストできると思います。したがって、開発環境はローカルで、ステージングは共有サーバー上でのみ行われます。仮想マシンイメージの管理に役立つVagrantなどをチェックアウトできます。したがって、すべてのプロジェクトが正しい設定を取得することを確認します。これにより、同じ方法でテストして、安全に（共有サーバーが壊れて誰も作業を続行できなくなり、そこで適切なバックアップをとる必要がある場合）、より速く（マージするまで転送は必要ありません）ことが保証されます。Gitの方がこの問題では10 SVNの方が優れています。これは、各マシンで履歴とすべてを含む完全なリポジトリを保持するため、1台のPCが壊れた場合でも別の場所に適切なコピーが残っているためです。

また、Gitosisなどは、ステージング環境のリポジトリ設定の管理に役立ちます。Redmine または他のプロジェクト管理ソフトウェアには、VCSと統合する方法がよくあります。

なぜなら、gitはある種の「標準」になるものであり、私たちがgitを使用する傾向があるWebユーザーの間には、多くの「プロgit」の人々がいるからです。

これは、SCMの世界で選択を行うための不十分な基盤です。Gitは「標準」ではなく、周囲に多くのノイズがある「ファッション」です。「プロGit」は、多くの場合、賢明で合理的な決定よりもファンボイズムです。

コードを上書きせずに同じプロジェクトで同時に作業し、バージョン管理の利点を提供する

どのSCMのブランチでも、Git（キーワード： "Git-flow"）でも取得できます。