前置き
今までZIP（笑）で送付し、新卒のコードをレビューしていましたが、今回僕がコードレビューをするのでそんな負の習わしは積極的にブチ壊して行こうという事で今年度からソースをgitでコード管理をするように致しました。
という事で今回はその新卒達に向けた記事となっております。
現場独自の運用ルール等があった場合はもちろんそちらを優先してください。
flowについて
gitに置けるflowとは、運用パターン、構造のようなものです。
Git flow,GitHub flow,GitLab flow等様々なflowが存在しますが、本記事ではGitHub flowを使用して運用の解説をして行くので、もし運用方法についてこの記事に記載されていない事などがあればGitHub flowでググれば出ると思います。そんな事無いようにしますが。
GitHub flowとは
かなりザックリいうとmasterブランチとそれ以外のブランチからなる構成です。
基本的にmasterブランチにコミット、プッシュは禁止で、他ブランチからのマージによってツリーを形成していく運用方法となります。
恐らく今記事を読んでる新卒のみなさんはファルシのルシがコクーンでパージみたいな状態になってると思いますが、理解はしなくていいです。この辺りはgitを使ってるうちに「ああ、あいつが書いてたのはこういう事ね」になっていくと思うので。
ブランチの分け方
基本的に機能単位でブランチを切ります。
例としてTwitterをあげた場合
・プロフィール変更画面ブランチ
・タイムライン画面ブランチ
・RT,いいね機能ブランチ
程度の粒度でブランチを切っていきます。
あまりに細かすぎるとその画面と依存する部分がブランチによっては動かなくなってしまうので最初のうちは画面単位でいいと思います。
ブランチの寿命
基本的にGitHub flowでのブランチの寿命はマージまでとなります。
マージをした後ならば対象ブランチを削除してもグラフとして存在し続けるので安心してください。
マージが終わったらビビらずにブランチを削除してください。
masterブランチに直プッシュする運用をした場合…？
〜ある人物の勤務風景〜
「今暇でリリース出来るから〇〇アプリのIPAくれ！」
「おお、やっとか。一週間前に出来てたから待ちくたびれたで。ポイ〜（IPAファイル送付）」
「ちょっとmogiくん？なんか次回リリース予定の画面に遷移するボタン表示されてんねんけど…」
「！？！？（次回リリースまだ先やから急ぎタスク先に消化してて追加してるの忘れてもうてた！！！）」
この後この方は罰としてお腹と背中にトランセル種市のタトゥーを彫られたそうです…
…こういったことがmasterブランチに直プッシュしない事によって防ぐことができます。
人がポンコツな場合運用パターンに沿って行動させることがミスを減らすコツです。
ブランチを分けてもmasterブランチを選択し忘れた場合は知りません。
コミットメッセージのテクニック
ブランチは基本的にはマージしてグラフを一本にしたら削除しますので、時間が経てばブランチ名からなんの改修を行ったかがわからなくなります。
そこで役立つテクニックがコミットする際のメッセージに必ずブランチ名を入れるです。
そうする事により、バージョンアップ作業時などに修正点、追加点などをまとめる事がコミットグラフを見るだけでアプリに関係していない人間でも出来るようになります。
いつも後輩に教える際、呪文のように「十年後の自分が見てもわかる内容にしろ」と言っています。
これは「プロジェクトに関係しない人間が見ても理解出来るようにしろ」という意味でもあります。
最後に
まだまだ色々あるというか、操作に対して一切書いていないので大丈夫か？感がありますが、やはり一番は触って覚えることが最速でGitをマスターする１番の近道だと思います。
ですが、Gitは他人のソースにも影響を与えてしまう事があるので怖くて触れないという方が多いと思います。
今回うちの新卒には何してもいいリポジトリを作成し、好き勝手アプリを作成してもらう予定なので運用にのみ要点を置いて書いてみました。
まあ逆にこれさえ守ってたらチームに迷惑もかけないと思います。
駄文ですが、読んでいただきありがとうございました。