• 元となるリポジトリ(RA)の作成(もしくはもうあるもうある)
• そこからForkする(RB)。これは Web UI
• RBをローカルへcloneする(RBL)
• RBLのmaster から作業用ブランチ b1hoge_spike を作成する
• 作業して b1hoge_spike を伸ばす。
• 適当なタイミングでバックアップの意味をこめて b1hoge_spike を RB へpushする
• RA の変更を RB へ取り込む。Web UI の sync
• RB を pull してRAの変更分を RBLへ取り込む
• b1hoge_spike を rebaseして変更に追従する
• b1hoge_spike を RB へ強制pushする。spikeブランチは他人から何かされる予定のブランチではないので強制的に歴史変更しても問題ないという意識
• 作業が完了したら b1hoge_spike から b1hoge ブランチを派生させる。これの意味は単なる、作業結果のコピー。
• b1hoge を master へ rebase する。その際にリビジョンを整理して適当に押しつぶす
• master から派生したことになった b1hoge を RBへpushする。
• RB の b1hoge を RAのmaster へpull request を出す。タイミングとしては最新masterの先から編集していることになっているのでマージが失敗するはずがない。
• RAに取り込む Web UI
• RAのマージ結果を RB へ取り込む。 Web UIの sync機能
• RB を RBLへpull

Bitbucket の Web UI で作る

Bitbucket の Web UI で Fork する。

ロカールのリポジトリを作りたいディレクトリ(hoge)で

$ git clone git@bitbucket.org:oreore/piyo.git

hogeにpiyoディレクトリが作られてそこに各ファイルダウンロードされる

Work を 分岐元したいrevisonへ移動する

master が多いと思うので master の tip から分岐したいなら、masterのtipへまず移動

$ git checkout master

作業用のbranchを作ってそこへ移動する

git checkout -b hoge_spike

Commit候補を指定するということ。

どのファイルにどんな変更が加わっているかを確認する

$ git diff

Stage する

$ git add index.html

変更が加えられているものを全部 Stage するには

$ git add --all

特定のファイルをStageから外す。

$ git reset HEAD index.html

$ git commit -m "hogehoge"

これでリモート側に同名のbranchができあがる

$ git push origin hoge_spike

作業をmasterから分岐したので Pull Request 用の branch を master から分岐する

master に移動

$ git checkout master