[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”4_5″ last=”no” spacing=”yes” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” border_size=”0px” border_color=”” border_style=”” padding=”” class=”” id=””][fusion_text]Github/Git、すごい便利ですね。本当にそう思うのですが、ツールが揃っていたとしても、ツールの使い方が大切だったりしますよね。むしろそっちのほうが頭の痛い問題だったりしておりました。先祖返りとか、マージの仕方とか、もめちゃったりとか、、、もう、考えただけでぞっとします。
特にWebサービスのような頻繁に更新がかかるようなものだと、なおのことです。
最近では、DevOps(デブオプス)なんていう言葉もあるようで、アジャイルソフトウェア開発や継続的インテグレーション(CI)なんかも含めて、腕の見せどころだったりするのだなと感じています。[/fusion_text][/fusion_builder_column][fusion_builder_column type=”1_5″ last=”yes” spacing=”yes” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” border_size=”0px” border_color=”” border_style=”” padding=”” class=”” id=””][fusion_text]
[/fusion_text][/fusion_builder_column][fusion_builder_column type=”1_5″ last=”no” spacing=”yes” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” border_size=”0px” border_color=”” border_style=”” padding=”” class=”” id=””][fusion_text]
[/fusion_text][/fusion_builder_column][fusion_builder_column type=”4_5″ last=”yes” spacing=”yes” background_color=”” background_image=”” background_repeat=”no-repeat” background_position=”left top” border_size=”0px” border_color=”” border_style=”” padding=”” class=”” id=””][fusion_text]で、つらつらとどうしようかなぁ、、と調べておりましたが、Github Flow(英語です)なるものが、便利そう。幸いなことに、Github Flowの日本語訳をかいてくれている人もいました。とっても助かりますね。ありがたく日本語と英語を比較しつつ、読んでみると、Githubの開発で実際に行っている方法のようで、35人での開発で回っているフローだとか。コピーキャット(模倣者こそがイノベーションを起こす)よろしく真似ていったほうが賢いよね、ってことで、参考にさせてもらうことにしました。
せっかくなので、英語の方をさらりと見てみると、
- Anything in the
master
branch is deployable
マスターブランチに上がるってことと、デプロイするっていうのが、同時なんですよね。これが一番わかり易いですよね。そうそう、そうなんだよと思いつつも、デプロイしてなかったりとか、ないですか?(笑)
- To work on something new, create a descriptively named branch off of
master
(ie:new-oauth2-scopes
)
ブランチには説明書きっぽいネーミングをつけようよ、です。これまた王道ですよね。これまた、そうそう、そうなんだよと思いつつも、テストとかつけちゃったりしてはダメってことです。
- Commit to that branch locally and regularly push your work to the same named branch on the server
ローカルにブランチ作ったらサーバ側の同じ名前のブランチにも定期的にコミットしておこうねってことですが、これはできてることが多いかしら。
- When you need feedback or help, or you think the branch is ready for merging, open a pull request
フィードバックとか助けが欲しい時、マージしたいときにはプルリクエストする、まぁ、ココはそうですよね。
- After someone else has reviewed and signed off on the feature, you can merge it into master
誰かにレビューしてもらってOKだったら・・・レビューですレビュー。大切ですねぇ。レビュー、できてるかなぁ、、、
- Once it is merged and pushed to ‘master’, you can and should deploy immediately
マスターにマージしたら、即デプロイすべき!!なんですね。shouldがイタリックになっていますよ。これは、大切なんでしょう、きっと。
いろんなチーム運営があるので、他にもベストはあろうかと思いますが、わかりやすさという意味では、非常にいいなと思いました。真似たいです。[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]