Gitの運用ルール、フローを考えてみたnajeiraメニューブログ2012年1月25日Gitの運用ルール、フローを考えてみた徐々にGitに移行しつつあるのですが、複数人数(チーム)でGitを使った場合の運用ルール、ワークフローというものを考えてみました。Git使い始めということもあり、不備は多々あると思います。アイディア等あれば是非教えて下さい!原則masterで作業しない。ブランチを作って作業する。ブランチでは1機能もしくは1バグのみ作業する。origin/mastermasterから、作業用のブランチを作成する。masterブランチ名は担当者名と作業名をスラッシュで結合したものとする。taro/bugnameコーディングコードを書く。HEAD^コーディングとコミットを繰り返す。コミットは頻繁に、どのような単位で行なっても良い。コーディング中の更新履歴は汚くなっても良い。最終テスト前):masterの更新を取得する。origin/mastermasterの更新の内容を確認する。origin/mastermasterに更新に追随するためにrebaseする。origin/master作業を中断して他のブランチに移動する前に:すべてコミットする。commitもしくは、一時保存する。"コメント"他のブランチから戻ってきたら。popコーディング、テストを終え、他のメンバーに渡せる状態になったら、次の「マージ」に進む。マージ新機能の追加など、チーム内部で機能レビューが必要な場合は、ステージング環境にマージ、デプロイ、機能レビューする。バグや小さな変更など、機能レビューが不要な場合は、プロダクション環境にマージする。ステージング(dev)devに移動する。devdevをリモートと同期する。origin/devmasterに追随するために、rebaseする。origin/master対象のブランチに移動する。branchnamedevに更新に追随するためにrebaseする。devこれにより、masterには未適用だがdevに適用されている更新がブランチに適用されるので、ローカルでテストする。バグ等あれば、ローカルで修正する。これによる変更がなかった場合は、ステージングへのマージへそのまま進んで良い。devdevにブランチをマージする。"コメント"リモートにdevをpushする。pushステージング環境にデプロイする。ステージング環境でテスト、機能レビューする。プロダクション(master)masterに移動する。mastermasterをリモートと同期する。origin/master対象のブランチに移動する。branchnamemasterに更新に追随するためにrebaseする。masterステージングで機能テストしていた場合、devのみに適用されている更新が取り除かれるので、ローカルでテストする。バグ等あれば、ローカルで修正する。これによる変更がなかった場合は、マージへそのまま進んで良い。masterに移動する。mastermasterにブランチをマージする。"コメント"リモートにmasterをpushする。pushブランチを削除する(しばらく待ったほうが良い?)。branchnameリリースプロダクションへのデプロイは、責任者が更新内容を確認してから行う。masterに移動する。mastermasterをリモートと同期する。origin/master前回のデプロイ移行の、masterの更新履歴を確認する。log必要に応じて、前回のデプロイ時との差分を確認するタグをつける。2012.01.26プロダクション環境にデプロイする。