ソースコードのバージョン管理を行う上で現状、最も情報が多そうなのはGithubをSourceTreeで利用するやり方のようです。今回は更にアジャイル開発ということを踏まえて、Github-flowを実践してみます。
そもそもGitを用いた効率的な開発のやり方をまとめたGit-flowのGitHub版です。GitとGitHubの違いがよく分からない方はこちらの記事をご一読下さい（記事：Subversion,CVS/Git/GitHubの違い）
ざっくり言うと、Git-flowは複雑で大変なのでGithub-flowにしようという事です。
Github-flowの概要は様々なサイトで解説されています。難しくないので、幾つかサイトを巡って事前知識を得たおいた方が理解しやすいでしょう。
【Github-flow概要】
・完成したコードを保管するリポジトリは1つ（masterリポジトリ）
・開発を進める場合、各自開発用のリポジトリを作成する（topicリポジトリ）
・topicリポジトリはmasterリポジトリのブランチとして作成
・topicリポジトリの内容をmasterに反映させるにはレビュー後、pull requestを使う
つまり、完成品を置く場所をmasterリポジトリ１つに絞る事で、masterリポジトリのソースが常に安定した最新版になります。スクラム開発のデモ時等、最新版が必要な時になって慌てて各開発者から最新ソースを集めたり、合体させたりする手間がはぶけます。
更に開発時のソースはtopicリポジトリだけで取り扱うので好きに編集でき、masterへの登録時に他者の確認を挟むことで過ちを減らすことができます。
ただし実際にGithub-flowを行ってみた結果、幾つか疑問が生じました。とりあえず私なりに対処しましたが、もっと良いやり方があるのかもしれません。
【Github-flow疑問と対処法など】
①開発要員は全員Githubへのアカウント登録が必要か？
→全員がGithubアカウントを取得する必要があります。
②masterリポジトリは誰が作る？
→システムを開発するチームの中で、誰か1人だけがmasterリポジトリを作ります。
③topicリポジトリはどうやって作る？
→masterリポジトリを作った人が、他の開発メンバのGithubアカウントを全てCollaboratorsに追加します。その上で、masterリポジトリ保有者またはCollaborators参加アカウントからtopicリポジトリを作ります。
④topicブランチ（masterリポジトリからのブランチ）作成時の注意点
→以下を行わないように注意。
×）masterリポジトリからfork
→forkした人しかtopicブランチを使えません。topicリポジトリは開発単位で作るので、その開発に携わる全員が見れる環境にbrunchを作ります。
×）masterリポジトリをローカルにclone後、ローカルでブランチ作成
→権限の問題だと思いますが、ローカルブランチはmasterリポジトリ所有者以外Github上にpushできません。基本的にGithub上でできることは全てGithub上で操作した方がよいでしょう。
ひととおりの手順をまとめると、以下のようになります。
【GIthub-flow手順】
２－２－１．準備作業（masterリポジトリ作成/Collaborators追加）
２－２－２．topicリポジトリ作成
２－２－３．topicリポジトリ操作（ローカルにclone/Githubにpush/他のメンバのtopic編集取り込み）（準備中）
２－２－４．topicリポジトリをmasterリポジトリにマージ（レビュー/pull request→masterへマージ/topicブランチ削除）（準備中）
GithubとSourceTreeが必要になるので、まだ準備していない方は、こちらの記事にある手順で導入しておいてください（記事：GitHub+SourceTreeでソース管理）