普段からGitを使ってはいるものの、やはり「普通はどうなのか」という一般論をそもそも会話にならないので、そのために下記の本を読んでちょっとだけ勉強しました。
今回はその殴り書きです。 (本気で同僚を殴りたくなったので、そのストレス発散も兼ねた、)ただの殴り書きです。
Gitの基本的なコマンド
このへんは、すでに死ぬほど記事があるのでその辺を参照。
Git-flow
こちらも、最早デファクトスタンダードなんで、この辺をご参照ください。
ポイントだけ列挙すると、
- master/developブランチには直接コミットすることはありえない
- コードレビューの後、マージして問題ないことを確認してから、master/developブランチに反映
この手の共同開発を行う際には、mergeの運用方針でしょうか。 個人的に多いと思っているのは、
- 何人かのレビュアーがapproveしたらmerge
- 責任者がapproveしたらmerge
辺りでしょうか。 この辺はブロックチェーンの承認プロトコルみたいで面白いっすね。
git管理を始める前の手順(.gitignoreの設定)
意見が分かれるところですが、この辺を見るとgitignoreにはなんとなく3種類目的がありそうです。
- プロジェクトの不要な中間・バックアップファイル
- 機密情報（秘密鍵、パスワード情報、顧客情報、etc...）
- 個々人の開発設定
1つ目は基本的にはgiboやらgitignore.ioを使えばいいと思いますし、2つ目・3つ目は機密情報や個人設定をプロジェクトに含めるとかありえないので論外です。 このへんは技術以前のリテラシーの問題の気がしますね。
gitignore.io
gibo
※これ関連で、本気で同僚をシバこうかと思いましたが、ぐっとこらえました。パワハラになっちゃうんでね、はい。腑に落ちない気持ちをぐっとこらえた私チョー偉い。
commitするまでの手順
ここはもう趣味の問題なのであまり気にするのも気にされるのも嫌なんですが、自分もこんな感じでやっている気がします。
git commit するまでに自分がやっていること · GitHub
とにかく、後で見返したときにコミットの意味がわかって、必要十分な変更がなされていることが大事だと思っています。
メッセージの書き方例
こちらが客観的で素晴らしかったです。
[転載] gitにおけるコミットログ/メッセージ例文集100 · GitHub
こちらを参考に書けば、問題ないかと。
pushするときの手順
こんな感じになりますよね、はい。
pull request
これも好みの問題かと思いますし、チームの方針に従っていただければと思います。 個人的には、こういうのがわかりやすいですし、お互い負担が少なくて済むと思っています。
pull request自体の書き方にも、定石があるそうで（知らなかった。。。）、この辺を参考にすればレビュアーもわかりやすいかと思います。
コードレビュー
コードレビューの観点もいろいろありますが、リンクのページの内容で十分かと思います。 組織によっては削ったりしますが、こんな感じかと思います。
感想
新年一発目の記事ですね、今年もなんとか継続して記事がかけるようにがんばります。
今回は知っていることが一般論であることを確認するためにやった勉強なので、目新しいことはなかったです。 最早gitは使って当たり前のツールなんで、安全・快適なツールとして使っていきたいものです。
