はじめに
gitを使ったアジャイルチームによる開発について少し書いておきます。用語はなるべくアジャイルサムライに準じますが、一部スクラムの用語が混じるかもしれません。
共同所有
アジャイル開発はまず共同所有が必要なので、最低限共有用のbareレポジトリはたてましょう。githubでやってもいいし、その辺に転がっているマシンをレポジトリサーバーにしてもいいでしょう。
bareレポジトリマシンに必要なのは、常にネットワークに繋がっていることと、ディスク容量が小さくないことです。早くなくても大丈夫ですが、gitのバージョン違いが起きるとあとで面倒なのでなるべく最新のgitを追いかけることのできるバージョンのOSを使いましょう。
イテレーションとストーリー
小さいチームの場合
決まったタイムボックス（イテレーション）で、それぞれのストーリーを開発するのですが、チームが少人数で同時に一つのストーリーしか取り組めない（これが理想的）状態のときは、メインのブランチでそれぞれ開発するといいかもしれません。ただし、毎日作業が終わったら、一通りテストをして、共有レポジトリにpushしておきましょう。もちろん、毎日の開発はpullから始まります。
$ git push
$ git pull
githubやbitbacketなどの環境の場合は、pull request機能を使うのがいいでしょう。forkをしない方法（github flowとしてよく知られています）を使い、pull requestを使うことで確実にコードレビューが終わったコードをマージするというプロセスを作ることができます。
いきなりメインのブランチを変更するのが怖い場合、たとえば、ちょっとスパイク的に試行してみる等といった場合は、個人レベルでブランチを切って開発し、ある程度見えたところで、マージするという方法をとるといいでしょう。
$ git branch my_spike # ブランチを作成
$ git checkout my_spike # ブランチ my_spike を変更開始
$ git commit # ブランチにコミット
$ git branch master # メインのブランチに変更
$ git merge my_spike # ブランチ my_spike をマージ
$ git branch -d my_spike # ブランチ my_spike を削除
これもgithub flowにより代用できます。一気にマージしようとすると、マージに失敗することが多くなり、またその解決も時間がかかることになります。できる限り頻繁なマージを心がけましょう。
大事なのは、いつもメインのブランチが完全に動く（テストがパスする）状態の最新のコードがおいてあるということ。これはCIの原則です。メインのブランチが壊れてないことを確認するために、jenkinsなどのツールを使うことがあります。もし壊れていたら、ストーリーの開発をいったん中止して直しましょう（ラインストップ）。
大きいチームの場合
CIの原則やイテレーションの進め方の原則から言えば、優先順位順にストーリーをひとつずつ完了させていくことが理想なのですが、そのような理想の進め方ができるのは、十分に熟練したチームであることが多いです。（でも目指さなければ実現できないこともあわせて憶えておきましょう）
現実に対応するために、複数のストーリーの開発が進行する場合もあるでしょう。その場合は、ストーリーごとにブランチを切って、ストーリーが完了した後にメインのブランチをマージするといいでしょう。
ストーリーとして完了した方を最後に一気にマージするのは、競合が発生する可能性もありあまりおすすめしません。ですので、本来は着手したストーリーをすべてメインのブランチにマージしていった方がいいのだけれども、様々な理由でストーリーの開発が続行できなかったときに取り除くのが難しいことが多くなります。
十分に小さくないストーリーが多いと、競合が発生することが多くなり、最後のマージ作業がとても大変な作業になってしまうので、ストーリーを十分に小さくして置くことが大事です。ここは別のプラクティスになりますね。
イテレーションが終わったら
イテレーションの後作業
イテレーションが終わったら、是非タグをつけましょう。次回のイテレーションで困ったときに立ち戻る場所が今回のイテレーションの成果物です。
$ git tag itereation_xx
もし中途半端になってしまったストーリーがあったら、ストーリーをいつやるのか顧客と相談しましょう。
中途半端になってしまったストーリーのブランチを一度破棄してもう一度はじめからというのも選択肢としてありかもしれません。経験は得られたわけですから、次回は今回よりも作業しやすいでしょう。