今回は、gitを使うチーム作業の流れを紹介したいと思います。

git flow

gitを使ってブランチを分けて作業する運用手法です。
feature(機能追加、このブランチは複数ある)、develop、master、release（複数）、hotfix（緊急の修正、masterにマージしたら削除される）という全部５つ種類のブランチを使います。
フローの概要をつかむため、ここをまず見るのをお勧めします。
sourceTreeの機能を利用すると、簡単に実現できるのようです。

基本的な流れ

1. developをベースに開発用ブランチを作成して（これがfeatureにあたる）開発者それぞれが開発をスタート
2. 他の人が開発したコードを自分の開発用ブランチにマージ
3. 開発が終われば編集内容をdevelopにマージして、開発者用ブランチを削除
4. developブランチをremoteブランチにpush
5. 4を繰り返して開発を進める
6. 開発が終了したらリリースのための作業を始める(developをベースにreleaseブランチを利用、 軽微なバグフィックス、リリース向けのコードや設定の編集)
7. releaseの編集を終えたら、developとmasterに内容をマージして、releaseブランチを削除
8. リリースを行う(masterブランチのデプロイ)
9. リリース後に、緊急バグが発生したらmasterをベースにhotfixブランチを作成し、対応
10. 対応できたらmasterにマージし、hotfixブランチを削除
11. 10を繰り返してバージョン管理を運用する

参考リンク

git flow cheatsheet（英語）
git flow cheatsheet（日本語訳）
運用事例

github flow

githubを使う運用手法、ではなく、
github開発チーム内部で使っているgit flowをカスタマイズしたものです。
開発の一時ブランチ（複数）と、masterブランチの2種類のブランチのみ使います。

git flowの短所

• ブランチの切替えはやや複雑
• 短時間に繰り返すデプロイには不向き

github flowの特徴

• masterブランチは常にデプロイ可能な状態にしておく
• 新しい開発などは、masterからブランチを作成して名前をつけ、そこで行う（一時ブランチ）
• 作成したブランチにローカルでコミットし、サーバー上の同じ名前のブランチにも定期的に作業内容をpushする
• フィードバックや助言が欲しい時、ブランチをマージしてもよいと思ったときは、 pull request を作成する
• 他の誰かがレビューをして機能にOKを出してくれたら、あなたはコードをmasterへマージすることができる（プレビュー前のマージが発生しない→ルールとして強制）
• マージをしてmasterへpushしたら、直ちにデプロイをする

参考リンク

github flow（英語）
github flow（日本語訳）