今回はGitHubの話。
基本的な使い方は入門書がいくらでも出ているので今更私が解説するまでもないけど、ブランチ運用については腑に落ちるまで少し苦労したので今回は自分流のブランチ運用をメモとして残しておこうと思う。
ガチの開発勢から色々と文句を言わるかもしれないけど、趣味開発なのでご容赦願いたい。
thomの2ブランチ開発フロー
私は次の表の1～8のような流れで開発を進めている。
このブログの読者はExcelマクロ開発者が多いのでバージョン管理システムを使わないExcel開発を例えとして挙げてみた。対比させるとGitでやっている作業が何をしているのか少しは分かりやすいかなと思う。
本来は2～4を繰り返してこまめにdevブランチを更新しつつ、ある程度キリの良いところで充分にテストをしたうえでmasterへ取り込むんだけど、なんせ一人で開発していてユーザーも大抵自分ひとりというケースが多いので、すんなり動いているうちはdevに保存したらそのままmasterへも取り込むという運用をしている。
そう聞くとdevブランチを使うメリットってよく分からないかもしれないが、開発でソースコードがぐちゃぐちゃになって動かなくなったときに、どこまでバックアップを遡るか等と頭を悩ませることなく、単純にdevの更新をまるっと捨てていつでも完全動作するmasterに戻れるという安心感が大きなメリットとなる。masterがチェックポイント的な役割を果たすので、devの方は思い切った変更ができる。
thomの3ブランチ開発
実際にはmaster/dev以外にfeatureブランチという機能開発用のブランチを作成する場合がある。
この場合はmasterが公開版なのである程度まとまった機能単位でしかmasterは更新せず、devが手元で色々機能追加したりとりあえず自分が使ってみる段階のベータのように取り扱う。
実際の開発の際にはGitHubのIssue機能でIssue番号を発行してそのIssue番号のfeatureブランチを作成し、開発成功してdevにマージした時点でfeatureブランチは削除し、GitHub上のIssueもクローズする。
おわりに
今回私のGitHubブランチ運用を紹介した狙いはGitHubに興味をもって勉強してみたけどイマイチ実際の運用が腑に落ちない趣味勢へ情報を届けることである。(かつての私)
私が困っていたのは、具体的な使い方は書籍が出ているけど、機能紹介・操作紹介にとどまっているものが多くて実際の開発フローが分からなかったから。探せば開発フロー紹介もあるんだけど、ガチすぎて最初のブランチ運用に取り入れるにはちょっと気が重かった。
特によく分からなかったのはローカルにもマージ機能があって、GitHubにもマージ機能があって、それぞれどのタイミングでするのかということ。Gitの書籍読むとローカルでやってるけどGitHubの書籍ではプルリクしていてその後は？みたいな混乱があった。
私はプロの開発者ではないので、もし使い方間違ってたら申し訳ない。
ただ、私は便利に使えてるのでとりあえずこれで満足である。
以上
