Git / GitHubの適切な使用方法-PHP Dev / Testing / Productionサーバーを備えたシステム
これが明白または簡単である場合はお詫び申し上げます。多くのgit/githubチュートリアルを確認し、他の記事を読みましたが、私がやっていることが正しいことを確認したいと思います。
VC（明らかな理由により））を開発チームとプロセスに組み込みたいです。
現在の開発プロセス（Dreamweaverを使用）：
*チケット（または作業指示書）を受け取ります
*開発サーバーにファイルをダウンロード
*ファイルに変更を加えます
*ファイルを開発サーバーにアップロードします
*テスト/検証された変更
*本番サーバーに送信
Gitを使用して新しい開発プロセスを作成する方法を理解しようとしています。
私はPHPStormに切り替えています（これは実際のPHP IDE with Gitとの直接統合））。
それは次のようなものでしょうか
- チケット（または作業指示書）を受け取る
- ファイルのチェックアウト/更新/ダウンロード
- ファイルを変更する
- ファイルをアップロードする（これは現在の作業ディレクトリでもあると思います...？）
- 1日の終わりに、コミットを行います
- ビルドスクリプトにデータをテストサーバーに送信させる（夜間ビルド）
または、次のようなことをする方がいいでしょう
- チケット（または作業指示書）を受け取る
- ファイルのチェックアウト/更新/ダウンロード
- ファイルを変更する
- ファイルのアップロード/コミット
- ビルドスクリプトにデータをテストサーバーに送信させる（夜間ビルド）
それとも別の方法がありますか？最適なフローは何かを理解するのに少し問題がありますか？
どんな助けでも大歓迎です。
編集
サーバーのバージョンをローカル（すべての開発者）にするのが最善であるかどうかを確認しようとしています。その場合、7つほどのブランチがある場合、どのように機能しますか？
そうでない場合、どのようにしてWeb上の7かそこらのブランチに対処しますか？ FTPファイルをアップするか、Gitフックを使用してファイルを自動更新しますか？
更新07/26/2012
かなり長い間Gitでの作業に成功した後、私はこのブランチモデルに従って大成功を収めてきました。 成功したGitブランチモデル
上記に対する答えはイエスでした-間違いなくローカルバージョンのサーバーが必要です。
あなたがライブサーバーと開発サーバーを持っていると仮定すると、私はこれらの線に沿って何かをします。
開発サイクルから始める前でも、少なくとも2つのブランチがあります：
- マスター-開発サーバーはこのブランチで実行されます
- 安定-ライブサーバーはこのブランチで実行されます。
開発者がチケットまたは作業指示書を取得した場合、彼/彼女は次のアクションを実行します：
- git pull Originマスター
- git branch featureBranch（チケットIDまたは作業指示のわかりやすい説明として名前が付けられています）
- git checkout featureBranch
- 必要な変更を行う変更を行います。必要なだけコミットしてください。あなたが貴重な歴史を作るのでこれをしてください。たとえば、問題へのアプローチを試すことができ、それが機能しない場合は、それを放棄します。 1日後、ライトが表示され、ソリューションを再適用したい場合、それはあなたの歴史の中にあります！
- 機能が完全にローカルで開発およびテストされたら、チェックアウトマスター。
- git merge featureBranch
- git push originマスター
- 開発サーバーでプッシュされた変更をテストします。これは、考えられるすべてのテストを実行する瞬間です。
- すべてが正常に機能している場合は、機能をマージするか、安定版ブランチに修正します。これで、変更はお客様に公開されました。
サーバーでコードを取得する
サーバーの更新は問題になりません。基本的には、開発者と同じようにユーザーとして設定します。私の会社では、サーバーを読み取り専用ユーザーとしてセットアップしました。基本的に、サーバーは何もプッシュできず、常にプルできることを意味します。ただし、これを設定するのは簡単なことではないため、単純にgitプルのみを許可する単純なWebインターフェースを作成することもできます。開発者がライブ実装で何かをするのを防ぐことができれば、安全です:)
[編集]
この反応のコメントで尋ねられた最後の質問に応じて：
私があなたの質問を正しく理解しているかどうかはわかりませんが、基本的に（少し簡略化して）これは私がこれを行う方法です。 
テストマシン（またはテスト実装として機能するwebroot）は、マスターブランチがチェックアウトされたgitリポジトリに基づいたソースコードを持っています。このリポジトリを作成している間、他のすべてのブランチへの他のすべての参照を削除することもできるので、このリポジトリの間違ったブランチをチェックアウトできないことが確実になります。したがって、基本的にテストマシンには、チェックアウトされたマスターブランチのみを持つGitリポジトリがあります。
ライブサーバーの場合もまったく同じですが、今回は安定版ブランチをチェックアウトしました。開発者は、すべてのブランチが存在するローカルリポジトリのクローンを作成する必要があります。そして、皆さんが作成したソフトウェアのローカル実装。このソフトウェアは、ローカルのgitリポジトリからソースを取得します。つまり、このリポジトリで現在チェックアウトされているブランチから。
実際のコーディング
新しい機能が必要な場合は、現在のマスターに基づいてローカル機能ブランチを作成できます。ブランチがチェックアウトされると、変更がローカルで行われ、開発者がチェックできます（ソフトウェアが機能ブランチのソースで実行されているため）。
すべてが正しいように見える場合、変更は機能ブランチからマスターにマージされ、「git machine」にプッシュされます。いわば「あなたのgithub」。テストで変更を取り込むことができるため、必要なすべてのテストをQAで実行できます。すべてが大丈夫であると彼らが判断した場合、開発者はマスターから安定への変更をマージし、再度プッシュできます。
今残っているのは、あなたのライブマシンから引っ張っているだけです。