概要
公式のgithub-flowをベースに、入門用として簡易化したgithub-flowとチケット管理システムとの論理的な連携について説明する。
前置き
- gitの操作方法
- 本来のgithub flowの概念
- チケット管理システムとtaskboard(KANBAN)の理解
なぜ素のgitを使わないのか
- 開発安定版ブランチ（以下develop）へのマージに対する心理障壁を低くしたい
- 簡単に(1)コードレビューして、(2)マージという流れで操作したい
- リモートのdevelopブランチへpushしなければならないルールから抜けたい
想定する環境
- macかlinuxのコンソール
- github
ここで出てくるコマンドと用途
-
git clone URL- リモートからローカルへソースツリーをコピー
-
git checkout -b BRANCH- 新しいブランチを現在ブランチから作成（枝分かれするぞ）
-
git checkout BRANCH- 既存のブランチへワークスペースを移動
-
git add .- ブランチへの変更を追加する
-
git commit -m 'COMMENT'- ブランチへの変更を確定する
-
git commit --amend -m 'COMMENT'- 最新のコミットメッセージを書き換える
-
git log --oneline- コミットコメントとリビジョン番号だけ表示する
-
git push origin BRANCH_NAME- BRANCH_NAMEに相当するブランチをリモート(origin)にコピー
-
git pull origin develop- リモート(origin)のdevelopブランチから現在のブランチへマージ
-
git rebase -i BRANCH_NAME- 現在のブランチのHEADからBRANCH_NAMEに相当するブランチのHEADまでのcommitをマージする
-
git fetch --prune- 無効になったリモートリポジトリの情報を管理情報から削除する
-
git branch -d BRANCH_NAME- ローカルブランチを削除する
1. 大まかな事前準備
- githubでrepositoryを作成する
- ローカルにcloneする
- ブランチがmasterになっているので、developへ切り替えてfirst commit.
- リモートにdevelopをpushする
- githubのsettingsを開き、デフォルトブランチをdevelopに設定
- TOPページに戻って上部メニューのbranchを辿るとmaster , developの２つが見える
- おもむろにmasterブランチを削除。以降masterはdevelopからtagを使って切り出すだけの存在へ。
- .git/hooks/prepare-commit-msgを配置する。
- 試しに別のリポジトリをローカルで作成して
prepare-commit-msgの効果を確かめてみろ - 準備は整った！
$ git clone https://github.com/hogehog.git # 2
$ cd hogehoge/
$ git checkout -b develop # 3
$ echo 'hogehoge poo' > README.md # 3
$ git add . # 3
$ git commit -m 'first commit' # 3
$ git push origin develop # 4
$ touch .git/hooks/prepare-commit-msg # 8
$ vi .git/hooks/prepare-commit-msg # 8
.git/hooks/prepare-commit-msg
#!/bin/sh
# BRANCH_NAME COMMIT_MESSAGES
# ブランチ名取得
branch=$(git branch | grep ^* | sed 's/\* //g')
# first commit前等で、ブランチ名が取れなかった時用
if [ ! $branch ]; then
echo 'branch name CAN NOT retrieved..'
exit 1
fi
if [ $branch == 'develop' ]; then
echo 'DO NOT COMMIT to $branch !!!!!!!'
exit 1
fi
if [ $branch == 'master' ]; then
echo 'DO NOT COMMIT to $branch !!!!!!!'
exit 1
fi
# コミットメッセージの置換
msg=$(cat $1 | sed -e "s/ (branch:[0-9a-zA-Z_]\+)$//g")
if [ $branch != 'master' ]; then
msg="$branch $msg"
fi
echo $msg > $1
2. 大まかなフローはこのとおりだ
- リモートのdevelopから最新を取得する
- チケット番号単位でタスクブランチを作成する
- タスクブランチにcommitし、リモートもタスクブランチのままpush
- githubでcompareしてコードレビュー
- 他者にマージ実行してもらう
良い所
- 人間がpushするのは必ずdevelop以外になること
- 危うくdevelopにpushしてしまいそうなら、github側でprotected branchに登録するんだ。
- addしてしまっていたらstashすればいい。その後は自分で調べるんだ。
- developにマージするのはgithubだけということ
- そして何より、マージする前にコードレビューを挟み込めること
- ここで色々なWeb的な連携が可能になるのもミソだ
- CIで全テストをやってもらってもいい
悪い所
- チケット番号単位でブランチを作成するからその分コードレビューもチケット番号単位になるんだ
- 細かくチケットを分割し過ぎると作業量もその分増える
- チケットを細かくしてもそれらを統括するようなチケットを用意して、その番号でレビューをしてもらえば回避できる
- これは都合の良い方法を自分で探すんだ
3. さあ始めよう俺俺github-flow
- taskboard(KANBAN)からチケット番号を見つけよう。ここでは100番だ。
- まずはリモートからdevelopをpullしてローカルを最新にしよう。
- そして、ブランチ名OREORE_100をdevelopから作成する（チケット番号の前には何かの略語を入れると様になるぞ）
- ロジックを書いて〜
- OREORE_100へcommit
- そのままOREORE_100をリモートにpush
- githubを見て、developとOREORE_100をcompare & pull requestする（緑色のボタンをクリックだ）
- pull request作成画面に移動するのでタイトルと修正内容をコメント欄に書き、 create pull requestだ。
- コメント欄にはチケットのURLを書いておくといいぞ
- チケット側にはpull requestのURLを書いておくといいぞ
- 誰か他の人にこのpull requestをコードレビューしてもらえ
- このブランチが開発安定版developにマージされていいかの視点を持って確認する作業だ。
- タスクと関係ないファイルの変更がコミットに余分に含まれていることがある。そういうのも指摘するんだ。
- 問題なければ
This pull request can be automatically merged.と出ているはずだ。- 問題があれば
conflictを解消しろと出ているはずだ。 - 問題がなければ、誰か他の人にmerge pull requestをクリックしてもらえ（緑色のボタンをクリックだ）
- 問題があれば
- 更に confirm merge をクリックしてもらえ
- メッセージの左のアイコンが紫色になったら Merged でdevelopへOREORE_100がマージされた！
- もうOREORE_100は不要だったら、ついでに同じ画面から Delete branchだ。
- ローカルのブランチをdevelopに戻そう
- ローカルのdevelopも最新化しておけ
- ついでにgithubで削除したブランチの接続情報を掃除しておけ
- ついでに無用になったローカルブランチも掃除してしまえ
$ git pull origin develop # 2
$ git checkout -b OREORE_100 #3
$ git add . # 5
$ git commit -m 'implemented oreore methods.' # 5
$ git push origin OREORE_100 # 6
$ git checkout develop # 14
$ git pull origin develop # 15
$ git branch -a # 16
$ git fetch --prune # 16
$ git branch -d OREORE_100 OREORE_101 master # 17
### git fetch --prune 例
(before)
$ git branch -a
OREORE_100
OREORE_101
* develop
master
remotes/origin/HEAD -> origin/master
remotes/origin/OREORE_100
remotes/origin/develop
remotes/origin/master
$ git fetch --prune
(after)
$ git branch -a
OREORE_100
OREORE_101
* develop
master
remotes/origin/HEAD -> origin/master
remotes/origin/develop
4. commitのたびにpushしなくてもいいぞ？rebase -i developだ
- 前述の操作同様に、developからOREORE_101を作成する
- OREORE_101ブランチで何度かcommitをする
- logを確認すると自分のコミット履歴が見えるぞ
- このままdevelopへのマージ操作に入ってもいいが、煩雑な履歴になるからrebaseして綺麗にしよう
- 先頭だけ残して残りはpickからfixupに書き換えて保存しろ
- 他のコミットが最初のコミットにまとめられた。リビジョン番号は変化するぞ。
- コミットコメントが内容に沿わなくなったから書き換えろ
- 終わったらremoteにpushしてpull requestだ！
下の方に補足で書いている例を確認すると気づくことがあるだろう？commit前、rebase前、rebase後を比較するとrebase -i developが何をしたか理解できるはずだ。
理解できない人のために説明すると、commitで増えたHEADからdevelopの最新HEADまでの間をインタラクティブにマージしたんだ。リビジョン番号を指定して部分的にマージしてもいいが、自身の細々としたログだけ片付けられればいいのでdevelopの最新HEADとの差分全てをマージしてしまえばいい。
$ git checkout -b OREORE_101 # 1
$ git add .
$ git commit -m 'implemented create method' # 2
$ git add .
$ git commit -m 'implemented update method' # 2
$ git add .
$ git commit -m 'implemented delete method' # 2
$ git log --oneline
$ git rebase -i develop # 4
$ git log --oneline
$ git commit --amend -m 'implemented CRUD method' # 7
$ git push origin OREORE_101
commit 前
$ git log --oneline
cdfd5ec Merge pull request #1 from imasami/OREORE_100
3699a52 OREORE_100 oreore
c5e7e60 Initial commit
rebase 前
$ git log --oneline
2c7900e OREORE_101 implemented create method
c6db866 OREORE_101 implemented update method
15d024b OREORE_101 implemented delete method
cdfd5ec Merge pull request #1 from imasami/OREORE_100
3699a52 OREORE_100 oreore
c5e7e60 Initial commit
rebase 後
$ git log --oneline
933ba0d OREORE_101 implemented CRUD method
cdfd5ec Merge pull request #1 from imasami/OREORE_100
3699a52 OREORE_100 oreore
c5e7e60 Initial commit