注意
この記事は、2014年に投稿されたものです。
時代は変わっても運用におけるベースは大きくは変わっていませんが、投稿としては古い内容ですのでご注意下さい。
未だにストックなど多くいただきますので注意事項として、追記させていだきます。
以下本文です。
はい、今更かもしれませんが。俺としてはGitを扱う上で結構重要だと思っている commitやpushの頻度 について書きたいと思います。はじめに断っておきますが技術的なテクとかの話ではないです。ほとんどが 言われてみれば当たり前じゃん 程度の内容だと思って下さい。
ですが、flowとか運用方法 とか gitを使いこなすちょっとしたテク なんかより重要だと思っているのは俺だけでしょうか...？
どの単位でコミットしたりプッシュしていますか？
みなさん、どのような単位でコミットしたりするようにしていますか？未だに 適当にやってる みたいな人がいますが、決まったルールがない場合や一人で運用しているリポジトリなどの場合は確実に 単位や頻度 というものは意識してGitを使ったほうがいいです。誰よりも自分のために。
俺の例
コミットの最大粒度は1タスク
自分の場合、会社ではPivotalTrackerを使っているので基本的には Storyと呼ばれるタスク単位 が最大の粒度になると考えています。コミットをそれ以上大きなものにしてしまうと、良いことなんてなにもないと思っているからです。
たとえタスクが途中でもキリが良ければ即コミット
サブタスク単位 とか 本日の作業終了時 など、キリが良いタイミングがあればガツガツコミットしていきましょう。
頻度は高ければ高いほど正義だと思って下さい。
注意点としてはコミットコメントが適当になることですが、コミットコメントルールがない場合でも、コメントで容易に内容が差別できる程度のコメントは書くようにしましょう。
*最悪 rebase -i などでコミット整理するのもありですが、個人的にはあまり使わないです。ここらへんは個人的な好みの話なので、みなさんチームや個人で模索していただけると良いと思いますが個人的には、整理するなら squash marge派です。
コミットしたらプッシュしとこう
プッシュは簡単です。commitしたらpushする だけです。
極端な言い方すると。
git commit -m 'hoge'; git pull; git push origin :branch
毎回これだけでも、OKですね。もう何も考えずプッシュしまくりましょう。
コミットしたからにはプッシュしない理由なんてありません。たとえ途中のコードだとしても、リファクタ予定のコードだとしても、プッシュしましょう。
途中のコードが見られるの恥ずかしい なんてナンセンスです、ガツガツ見てもらいましょう。
もちろん、あとあと修正してから
git push -f origin :branch
なんてしないでくださいねｗ
なぜ、細かい単位での頻度を推奨するのか
あくまで個人的な考え方ですが、そうする理由をリストで簡単に説明します。なぜかは考えてみてくださいｗ
コミットの頻度を細かくする理由
- 自身の見積もり精度やタスク管理能力向上
- 複数タスクが混在したコミットは悪
- コミットとタグの相性UP
- Pivotalなどの外部サービスとの連携が容易
- 履歴を参照する際のコスト低下(log, reset, bisect, rebase時など）
- 自分や他人がみてもcommit内容の把握が容易
プッシュの頻度を細かくする理由
- 大きなコンフリクト発生頻度低下
- git pull の頻度も自然と上昇
- チーム間での状況共有が容易
- コードは即他人に晒すという意識向上
デメリットはないの？
特にないと思います。敢えていうなら「手間のコスト」ですが、そもそも大したコストじゃないですし、得られるメリットと比べるとROIは高い思うのは私だけでしょうか？
あとは人によっては、「コミットは整理してからPUSHしたい」などもあると思いますが、整理欲高いとPUSHタイミングが遅れがちになるので個人的にはすきじゃないです（なんどもいいますが、ここは好みの話です。）
なぜ、頻度を意識することが重要だと思うのか
Gitが何を期待しているのか考えてみる
実は、これは自分なりに導き出した答えというよりは「Gitが期待しているであろう使い方」を考えた結果の使い方なんです。
なぜそう考えるかというと、「ちょっと変わった使い方」とか「無理すればこういう風にも使える」みたいな使い方は、なるべくやめたほうがいいと考えているからですね。
ツールの使い方・考え方
ちょっと脱線しますが、Gitというのはツールです、自分やチームのために便利なツールがあるから利用しているんですよね？
で、Gitに限らずツールには「期待された使われ方」があります。もちろん「期待以上の使い方」を発見することもあるでしょうが、基本的には「間違った使い方をしてツールのせいにする」ほうが多いと思うので、「期待された使い方」をまずは実践することをオススメします。
なぜなら、それがツールの一番パフォーマンスを発揮するための近道だからです。
そういった点に意識を向けてみると、Gitの他のコマンドとの相性などを考えて使えるので、とっても自然に使いこなすことができるようになると思いますよ。
余談
他のコマンドの考え方も整理してみよう
今回は、コミットとプッシュのみに焦点を絞りましたが、ぜひ以下なども再検討してみてください。
- git commit時のオプション
- git merge時のオプション
- git rebaseの使用頻度
- コミットメッセージ
- git tagの使い方
根本的な考え方が整理できていると自分やプロジェクトにあったコマンドの利用方法が見えてくると思います。
実は、はじめてAdventCalendarつくりました。
はい、今年は書く気満々だったので、我先にとGitを作成させていただきました。現時点でほとんどのCalendarが埋まっているのをみてホッとしていますｗ
実は会社では Gitおじさん と呼ばれていまして・・・ｗ
一応会社では、Gitのことならこじてぃにみたいな立場でやらせていただいてます。
デザイナーさんにGit浸透させることにも成功したりして、「もっと広めるべきですよ！」みたいなことも言われたので、自分が出来る範囲でアウトプットしていければと思っていたりもします。
このAdventCalendarの人気っぷりに、「まだまだ、Gitを学習する需要がある」とわかったので、AdventCalendarが終わっても何らかのアウトプットしていければと思います。
とりあえず、この Git AdventCalendar も3回書く予定なので、そちらもよろしくお願いしますｗ
ご意見あればぜひコメントください。
- 俺はこういう理由でこうやっているよ
みたいなご意見とか参考例などあればぜひ教えてください。