Gitから学ぶ仕事のしかた

現在railsコーチングをして頂いている先生が、Gitを奨めて下さいました。
実際のバージョン管理も体験させて頂き、基本的な使い方は何となくわかってきたのですが、考え方の面で特に勉強になっています。

WEB+DB PRESS Vol.50 特集『はじめてのGit』 より


論理的に関係のない複数の変更は別々のコミットとして記録するのが、お行儀の良いバージョン管理のコツです(これはgitに限ったことではありません)。 〜 p.69 【git add -p を使う】


トピックブランチを使ったワークフローでは、1つのトピックは1つのテーマのみに徹した変更を行うのが基本で、最後にそのトピックを統合ブランチに併合したとき、そのテーマに関連しない変更が何一つ統合ブランチに現れないようにすることを一番の目標とすべきです。 〜 P.92 【トピックへの統合ブランチの併合】


これらの話は、開発に限らず、仕事のしかたそのものにも通ずるのではないでしょうか。


仕事を因数分解して明確なタスクまで落とし込む(=仕事をアトミックな単位に分割する・1つのタスクには1つのテーマしか持たせない)のは、非常に重要なことだと思います。
なぜなら次のような効果が得られるからです。

    • ゴール達成に必要な要素を抜け漏れなく洗い出せる
    • 計画を立てやすい
    • 起こりうる問題を予測できる
    • 問題が起きたとき原因を発見しやすい
    • 問題の処理範囲が明瞭になる
    • 他者とプロセスを共有しやすい

      ⇒ 手際よく正確にゴールを達成でき、チームメンバーの時間を必要以上に奪うこともない


ここでGitの話題に戻りますが、もちろん「Gitでなければアトミックコミットができない」ということはありません。
ただ、どれだけ管理のことを考えずに済むかで、敷居の高さは変わってくると思うのです。


私自身、仕事ではSubversionTracによるチケット駆動開発をしています。
(本来は1ブランチにつき1チケットが理想なのでしょうが、)重要度の低い小さな修正をいくつかまとめてFixすることもあるため、「せめてブランチへのコミットはアトミックに」と意識してはいるのですが・・・。
Subversionの場合、アトミックコミットを実現するには、コミットごとにどこを修正するか自分で管理しなければなりません。


その点Gitは、同一ファイル内でもコミットする変更を取捨選択できるなど、アトミックコミットに対して最適化されているなぁと感じます。
最適化されていれば、それだけアトミックコミットという作法を忠実に守れるようになるので、より正しい仕事のしかたが身につきやすいのではないかと。


とは言え大切なのは、ツールに頼るのではなく、ツールから学んだ仕事のしかたを自分でも心がけることですね。


と、Gitからの学びを簡単にまとめたところで、ひとまず自宅のWindowsmsysgitを入れてみましたので、今後いじってみようと思います。