BitbucketでFork/PullRequestを用いてチーム開発をすれば、
機能追加・修正の承認フローを簡単にできそうかなと思ったので。
人（チームのメンバ）に説明できるよう整理する意味も兼ねて、
PullRequestを用いた開発の流れを整理してみました。
※もちろんGitHubでも同じ流れで開発できます。

# fork/pull requestの仕組みは、本来はオープンソースなどで、
# ユーザが作成したパッチを元ソースに取り込んで欲しい場合に、
# メールでやりとりしているとややこしくなるので、
# それをシステム化して効率化するためのものだと思いますが、
# このエントリではチーム開発に利用するイメージで書いています。

PullRequestを用いたチーム開発の全体像

今回実施する開発の流れを整理すると、以下のような図になります。
bitbucket_pullrequest01

「1.fork」〜「4.pull request」が開発者側の作業。
「5.merge」が管理者側の作業になります。

  1. fork
    　マスターリポジトリから派生させ、開発者用リポジトリを作る。

  2. clone/pull
    　開発者用リポジトリを、開発作業用のPCに取り込む。

  3. push
    　開発で行った機能追加・修正を開発者用リポジトリに送る。

  4. pull request
    　開発者用リポジトリで行った派生開発を、
    　マスターリポジトリに取り込んでもらうよう依頼を行う。

  5. merge
    　派生開発の内容を承認してマスターに取り込む。

マスターリポジトリの構築

Bitbucketのメニューから「リポジトリの作成」を選びます。
bitbucket_pullrequest02

リポジトリの名称を指定してリポジトリを作成します。
ここでは「study」という名称で作成しています。
bitbucket_pullrequest03

作成したリポジトリの概要に手順の説明が書かれているので、
その説明にしたがって、README.mdをPushします。
bitbucket_pullrequest04

ここで作成したリポジトリの場合は、次のようになります。

プロジェクト作成

mkdir /path/to/your/project
cd /path/to/your/project
git init
git remote add origin git@bitbucket.org:takemikami/study.git

変更してPush

echo "# This is my README" >> README.md
git add README.md
git commit -m "First commit. Adding a README."
git push -u origin master

ここまで実施すると、ソースが次のようになります。
bitbucket_pullrequest05

開発者用リポジトリの構築とPullRequest

ここまででマスターリポジトリを作成できたので、
次は、マスターリポジトリをforkして、開発者用リポジトリを作成します。
# 全体像の「1.fork」〜「4.pull request」の部分です。

マスターリポジトリのプロジェクトで「フォーク」を選びます。
bitbucket_pullrequest06

リポジトリの名称を指定してリポジトリを作成します。
ここでは「study-dev」という名称で作成しています。
bitbucket_pullrequest07

これで開発者用リポジトリが作成できました。

以下のコマンドで、このリポジトリをローカルPCにcloneします。

git clone git@bitbucket.org:takemikami/study-dev.git

以下のように、このリポジトリに変更を加えてpushします。

echo "// hogehoge.c" >> hogehoge.c
git add hogehoge.c
git commit -m "commit from dev. add hogehoge.c"
git push

push後のソースは次のようになります。
bitbucket_pullrequest08

開発者リポジトリのプロジェクトで「プル リクエスト」を選びます。
bitbucket_pullrequest09

PullRequestのタイトルと説明を記載します。
bitbucket_pullrequest10

PullRequestのページ下側では、ソース差分の確認もできます。
bitbucket_pullrequest11

「プルリクエストを作成」を押下してPullRequestを送ります。

マスターリポジトリにPullRequstをマージ

次は、PullRequestの変更内容をマスターリポジトリにマージします。
# 全体像の「5. merge」の部分です。

マスターリポジトリを表示すると、
以下のように「プルリクエスト①」という表示になっています。
bitbucket_pullrequest12

プルリクエストを選んで詳細を表示すると、
先ほど作成したPullRequestの内容が確認できます。
bitbucket_pullrequest13

詳細でマージを押下後、
コミットメッセージを設定してマージを押下すると、
マスターにPullRequestの変更内容がマージされます。
bitbucket_pullrequest14

マスター側ソースで、hogehoge.cが追加されていることが確認できます。
bitbucket_pullrequest15

ここまでが、最初の全体像で示した開発の流れになります。

その他の流れ①：却下した場合

PullRequestの詳細に「却下」というボタンがあります。
これを押下した場合は、
PullRequestの変更はマスターに反映されないので、
問題点を修正した上で、再度PullRequestを送ることになります。

その他の流れ②：他の開発者が行った変更がマスターにマージされた場合

自分以外の開発者が行った変更がマスターリポジトリにマージされた場合、
開発者リポジトリに以下のような通知が表示されるので、
この通知から、自分のリポジトリにその変更を取り込むことができます。
bitbucket_pullrequest16
bitbucket_pullrequest17

最初の全体像の図を見つつ、
どの部分の操作をしているかを意識して操作してみれば、
どのような流れかは把握できるのではないかと思います。

このように承認フローのある開発プロセスにすると、
一人の開発者のミスで、
マスターリポジトリに動作しないコードが入ることなどを防げるので、
リポジトリ管理がやりやすいのではないかなと考えています。