GitHub Flow を取り入れた背景
私は SIer で小規模チームを取りまとめています。ソースリポジトリは Git を使っていたのですが、ブランチを切らずに master のみで運用していました。
課題
master のみの運用だと正常動作しないコードが混入することもありました。
対応
なので、新機能開発やバグフィックスの際にはブランチを切って、レビューの通ったコードのみ master にマージするようにしました。マージ後はすぐにデプロイします。
成果
master をクリーンな状態に保てています。また、レビューにより若手メンバの育成にもなります。
できていないこと
- プルリクエスト → 席が近いので、口頭で対応しています。
- テストコードを書くこと → 今後、ソースが大きくなると不可欠なのですが、現時点ではテストコードをかけてないです。
- デプロイの自動化 → 手作業が混ざってます。
品質や費用対効果を見ながら施策を打つ必要がありますが、テストコードくらいは書かないとなーと思っています。
コマンド
よく忘れるので、いつどのようなコマンドを実行するかも一通り書いておきます。
新機能の開発やバグフィックスをする時
branch を切って開発します。ブランチ名は何をするかがわかるような名前にします。次のコマンドでブランチを切りつつ、ブランチに移動します。
$ git checkout -b ブランチ名
定期的に push します。一通り書けたらレビューアに声がけする運用にしています。
$ git push origin リモートブランチ名
他の開発者やレビューアが pull する時
まず、ブランチを切り、ブランチに移動します。
$ git checkout -b ブランチ名
そのブランチ上で pull します。
$ git pull origin リモードブランチ名
なお、この状態からコミットを行なって push したい場合は次のようにローカル、リモートの両ブランチを指定する必要があります。
$ git push origin ブランチ名:リモートブランチ名
レビューが通って、マージする時
master に移動します。
$ git checkout master
マージします。
$ git merge ブランチ名
master を push します。
$ git push origin master
最後に
上記の施策は何ちゃって GitHub Flow ではあるのですが、以下の効果が出ています。
- master をクリーンに保つ
- レビューにより、若手メンバの育成
シンプルなフローなので、覚えることが少なくすぐ取り入れられる施策でした。とはいえ、開発効率をスケールさせつつ品質を保つにはその他の自動化も推進しなければ！と思っています。