数年前の話になりますが、チーム開発実践入門 という書籍で、開発フローの一例として GitHub Flow が紹介されています。この書籍では GitHub Flow が次のように解説されています。
- master は常にデプロイ可能である
- 開発する際は master からブランチを作る
- master に作成したブランチの Pull Request を送る
- 作成したブランチが master にマージされたらすぐに本番環境にデプロイされる
GitHub Flow が世に出てきたのは2011年頃で、当初はこのフローだったのだろうと思いますが、GitHub のブログでは次のように書かれています。
The basic workflow goes like this:
・Push changes to a branch
・Wait for the build to pass on our CI server
・Tell Hubot to deploy it
・Verify that the changes work and fix any problems that come up
・Merge the branch into master
Deploying at GitHub - The GitHub Blog
このブログが公開されたのは2012年です。GitHub の中のひとたちは割と早い段階でフローを変えていたようです。もしかしたら、今はさらに変わってたりして...。ちなみに、チーム開発実践入門が出版されたのは2014年です。同様に GitHub実践入門 も同時期。
今ではそれほど不思議ではないかもですが、feature ブランチをデプロイして問題なく動作していることを確認してから master にマージする、というところが個人的にはなかなか衝撃的で、GitHub の思想や達成したい目的に合っていて、なおかつ master を安全に保つという課題をシンプルに解決しているところに感銘を受けたものです。
まとめ
「分からないことが分かるようになりたい」という興味だけでやっているので他人と自分を比べたことがあまりないですね。少しでも分かると楽しい→好きになる→ハマる(夢中になる)って感じ。こういうこと毎日やってると、たまに人より詳しいということはあります。
— かとじゅん (@j5ik2o) May 7, 2019
たまたまこのツイートを見かけた際、このあたりのことを思い出して考えてみたんですが、自分の場合、誰かをメンターにしたりキャリアモデルを参考にしたりということがあまりなくて、どちらかと言うと、上記のような画期的なアイデアだったり、ある課題を解決するための目から鱗が落ちるような仕組みに影響を受ける傾向にある気がします。
いろいろ情報収集して自分のモチベーションに繋げたいと思う今日この頃です。
