GitHub Flow 概要

はじめに

gitは独特の作法があるために初心者には敬遠されがちですが、慣れてしまえば効率的な開発が可能です。
ここでは、GitHub Flowについて解説します。

手順

概要

GitHub Flowの流れは単純です。

• 最新のmasterブランチから説明的な名前を付けたtopicブランチをローカルで切る（checkout -b）
• topicブランチ上で開発
  • masterブランチを直接編集することは原則禁止
• コミット対象のファイルをステージングし（add）、コミット（commit）する
• 提出できるコミットができたら、リモートの同名ブランチにアップロード（push）する
• マージするよう申請を行う（pull request / merge request）
  • レビュアーはGitHub / GitLabのページ上で指摘を入れる
  • 必要があればコードを修正して再度commitとpush
    • この時、新しく修正用のブランチを切る必要はない
• レビューが通ったならば、masterブランチにマージする

フローから分かる通り、masterブランチは「全てのスクリプトが問題なく動作するブランチである」という暗黙の了解があります。

開発開始（checkout）

開発を開始するときは、最新のmasterブランチから任意の名前を付けたtopicブランチを切り、作成したブランチに移動します。
ここでは、リモート上のoriginリポジトリのmasterブランチが最新であるものとして、以下のコマンドを叩きます。

console

# 最新版のremoteリポジトリを取得
git fetch origin master 

# origin/masterからブランチを切って移動
git checkout -b <ブランチ名> origin/master
# git checkout -b mytopic origin/master

経過の保存（add/commit）

作業ブランチでの開発が進み一段落したら、作業の保存のために変更内容をインデックスに登録（ステージング）し、コミットをします。

直接コミットを行わずにステージングという段階を経るのは、コミットに関連するファイルを選別する意味があります。
詳しくはhttp://daretoku-unix.blogspot.jp/2009/08/git.html などを参考にしてください。

ステージング（add）

ステージングするためには以下のコマンドを叩きます。

console

# カレントディレクトリ配下のファイル（サブディレクトリ含む）すべてをステージングする場合
git add .

# 特定のファイルを登録する場合
git add <対象ファイル、またはディレクトリ>
# git add hoge.py

# 特定のファイルを複数登録する場合
git add <対象ファイル、またはディレクトリ> <対象ファイル、またはディレクトリ> ...
# git add hoge.py fuga.R

ステージングの状況がどうなっているかは$ git statusで確認できます。
ステージングされたファイルは緑、ステージングされていないファイルは赤で表示されます。

また、ステージングを行うとgit内部にステージング対象ファイルの編集内容が保存されます。
つまり、ステージングを行った後に対象ファイルを編集し、その状態でコミットを行うと、ステージング時点での状態でコミットが行われます。

コミット（commit）

ステージングが完了したらコミットしましょう。

git commit -m "コメント：作業内容を書く"

リモートへアップロード（push）

レビューが行えるコミットができたら、リモートへアップロードします。
以下のコマンドを叩きます。

git push origin <ブランチ名>
# git push origin mytopic

以上で、リモートにアップロードされました。
githubやgitlabのページを確認してみましょう。

masterブランチにマージ

GitHub/GitLabのページ上からmasterにマージするように申請します。
GitHubではpull request、GitLabではmerge requestといいます。

申請

GitHubの場合

GitHubのページからPull Requestを送ります。
baseにmaster、compareにpushしたトピックブランチを指定します。

GitLabの場合

Source branchにmaster、Target branchにpushしたトピックブランチを指定します。

レビュー依頼

GitHubの場合

Reviewerにレビュアーを指定してください。メールかなにかで通知が飛びます。
口頭でも一言「レビューお願いします」と言っておくと尚良しです。

GitLabの場合

レビュアーに声かけて、レビューをお願いしてください。
Assigneeに自分を指定すると、通知が受け取れるはずです。

レビュー

Reviewerは、間違っていると思われるところ・よく分からないところに指摘を入れていきましょう。
Assigneeは、指摘に対しての説明を返すか、コードを修正しましょう。
修正したコードは、同じリモートブランチにpushすることで更新されます。

マージ

すべての指摘事項が解決したら、pull request / merge requestのページからmergeをします。
mergeは原則としてレビュアーが実施します。

mergeが完了すると、トピックブランチの開発は終了です。
お疲れ様でした。