Posted at

GitHub Flow で master を汚さない開発を


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 をクリーンに保つ

  • レビューにより、若手メンバの育成

シンプルなフローなので、覚えることが少なくすぐ取り入れられる施策でした。とはいえ、開発効率をスケールさせつつ品質を保つにはその他の自動化も推進しなければ!と思っています。