読者です 読者をやめる 読者になる 読者になる
おもに Groovy やアジャイル開発について勉強していることを書き散らしてます。
わたしのひとりごとが、だれかのお役に立てればと…

Git "きちんと" はじめました

去年から GitHub を個人的なソースコード置き場として使うようになりました。
ですが、ソースコードをアップする、取得するための git コマンドしか理解していませんでした。

コマンドを理解…違いますね。理解はしていなくて、都度調べながらコマンドを打っていました。
正直、壊したらどうしよう的な感覚でした。

2013年、年も明けたので

Git/GitHub についてきちんと勉強しようということで、『入門 git』を買って勉強しました。

理解した上で、自信を持って、GitHub を pull/push できるようになるのが今回のねらい。
ブランチ作成や競合のマージについては、後回しにしました。他人のレポジトリに恐れ多くも push することはないでしょうし、一人で使う分には競合なんて起こりえるはずもありません。

『入門 git』には実行例、コマンド例が多く挙げられています。
実際にコマンドを打ちながら読みました。

2時間ほどで Git の基本的なことを理解して、基本的なコマンドは自信を持って実行できるようになりました。Git を勉強する入門書として、『入門 git』はおすすめです。

GitHub などのリモートレポジトリに関する内容がもっとあればよかったです。
あくまで自分のコンテキストを考えるとですが…
 

VCS について、ふりかえり

VCSバージョン管理システム)はふたつの役割を持っています。
・ファイルを変更を記録する、その変更を追跡する
・ファイルを複数人で共有する

仕事では長らく Subversion を使っていますが、「ファイルを複数人で共有する」ことが目的のほとんどを占めています。
コミットコメントがなかったり、意味のないものであったりします。
「変更を追跡する」ために使おうとする気がない、ということがよく現れています。

コミットの頻度は少なく、日に数回。
また、複数の変更が一括されてコミットされます。つまりコミットの単位が大きすぎます。(そして、コミットコメントはそのうちの一つのことしか書かれていない…)

もっとコミット粒度を細かくしていくようにお願いしているのですが、うまくいきません。
「コミットして動かなくなるのが怖い」「不完全な状態でアップしていいものか」
…というのが実情のようです。

「共有する」ことだけが焦点になっており、「変更を管理する」ことが範疇外となっているのだと推測します。ですが、そのふたつはトレードオフではなく、バランスをとって両立させるべきです。

そこで、DVCS

Git に代表される DVCS(Distributed Version Control System:分散バージョン管理システム)は「共有する」「変更を管理する」のふたつをうまく両立させられると今回感じました。

自分のローカルリポジトリに細かくコミットして「変更を記録」して、一定のタイミングでリモートレポジトリにプッシュすることで「共有する」。
このフローが自然と実践できるのではないかと思います。

(きちんと勉強、教育しないと長所を活かしきれず、Subversion 使っているのと変わらない状態になる可能性も高いですね)

とはいえ、慣れ親しんだ Subversion から移行する抵抗は大きそうです。