GitHubを使ったissueベースワークフロー

3行で

GutHubみんな使ってるけど何これ何が嬉しいの
ご利益はいっぱいあるけど、とりあえず使いたいなら私のワークフローを紹介するよ
issueを作ってissueに対する進捗をcommitしていき最終的に解けたらpushするよ

結論

次のようなワークフローになります。

1. 作業の準備
   1. issueの作成
   2. ブランチの作成(仮に名前はbranch_1とする)
   3. git fetch
   4. git checkout -b branch_1 (ローカルリポジトリにブランチbranch_1を作ってbranch_1に移動)
2. 実際の作業
   1. やりたい開発をする
3. 作業内容の共有
   1. git status (更新内容の確認。自明ならスキップ可)
   2. git add -A (commitする更新一覧に更新内容をすべて登録する)
   3. git commit -m "awesome comment" (ローカルリポジトリにコミット)
   4. git push origin branch_1 (リモートリポジトリのbranch_1をローカルリポジトリと同期)
4. 作業内容の反映
   1. プルリクエストの送付
   2. 更新内容をレビュアーがレビュー
   3. issueをclose
   4. masterブランチにマージ
5. お片付け
   1. git checkout master
   2. git pull

最近の自分の作業である、このリポジトリを例に説明します。
https://github.com/nagiton/tegaki_api

作業の準備

issueの作成

この部分はオプションですが、個人的には推奨です。
今、リポジトリにどのような更新が必要なのか、整理して宣言したものがissueです。
作業に取り掛かる前にこれから自分がやる作業はどういうものなのか整理する上で非常に有用です。

このNew issueのボタンからissueを作成できます。

簡単にタイトルをつけて、何をしたいのかコメントをつけておきます。
この時点で、どういう状態になったらゴールなのか、どういう手順でゴールにたどり着けるか、ある程度見通しがあることが望ましいです。
自分はなるべく、数時間の作業でで片付くぐらいの単位でissueにしています。

ブランチの作成

このボタンからブランチを作成できます。
issueごとにブランチを作ることをおすすめします。issue名とブランチ名が対応していると管理がしやすいでしょう。
（私は手を抜いてずっと"nabion_working"という名前のブランチで作業していますが・・・）

git fetch, git checkout

ここまででリモートリポジトリ上にブランチが作られたので、ローカルリポジトリに同期します。
git fetchはリモートリポジトリの更新履歴をローカルに取得するコマンドです
git checkoutはブランチを移動するためのコマンドです。
-bオプションをつけるとローカルリポジトリにブランチを作ります。
(ややわかりにくいですが、git fetchだけではローカルでは新規ブランチができません。)

これで作業用ブランチであるbranch_1をローカルリポジトリに作成して、branch_1に移動してこれました。
これで作業準備は完了です。

実際の作業

何も言うことはない。

作業内容の共有

git status

念の為更新内容を確認しましょう。
更新があったファイルが一覧になります。
特に、大きなファイルはGitHubにアップロードしないように、更新内容に含まれないか確認しましょう。

git add -A

commitする内容一覧に更新内容をすべて登録します。
git add でファイルごとに登録することもできます。

git commit -m "awesome comment"

ローカルリポジトリに更新内容をコミットします。
コミットすると、あなたの更新はローカルリポジトリに登録されます。
更新を登録しておくと、その更新によるファイル差分が確認できたり、何か将来不具合が合ったときにコミット時点に巻き戻れたりします。
こまめにコミットすることが推奨されます。

git push origin branch_1

リモートリポジトリにローカルリポジトリのコミット内容を送信します。
これを行うと、リモートリポジトリにあなたの更新内容が登録されて、他の人からも内容を見ることができるようになります。
なので、今例にとって説明している
https://github.com/nagiton/tegaki_api　
はこのコマンドを打つと内容が書き換わります。

作業内容の反映

プルリクエストの送付, 更新内容をレビュアーがレビュー, issueをclose, masterブランチにマージ

一通り更新できてissueが解決されたと思ったら、プルリクエストを出します。
プルリクエストは、masterブランチなど作業用でないブランチに更新内容を反映してもらうようリポジトリの管理者に要請する行為です。

開発者の更新内容をリポジトリの管理者がレビューします。
仕事でやるプロジェクトでは、マネージャーによるレビューなどがここで行われます。
issueがこれで解決していたら、closeします。

ここのclose issueですね。

そしてmasterなどにマージします

このタブから入って

リクエストを選んでこれです。

conflictしているとここで怒られます。管理者の人はがんばってください。
conflictを起こさない、起こしても簡単に解決できるようにも、issueは小さい単位で区切ることを勧めます。

お片付け

git checkout master, git pull

リモートリポジトリでmasterが更新されたら、ローカルリポジトリでもmasterを更新しておきます。
git checkout masterでmasterブランチに移動
git pullでリモートリポジトリのmasterブランチの更新内容をローカルリポジトリに同期できます。

一通りの作業の流れは以上になります。
無秩序に開発するより何かと手間がかかりますが、作業の整理が強制的にできることはいいことなんじゃないかと思います。