Javaプログラミングでgitというツールを使っています。

これが無いと困るとは聞いていましたが、初めはどう困るのかよく分かっていませんでした。

そこで、gitが無いとどうなるののか？本当に必要なのか？について軽くご紹介します。

gitは何のためにある？

gitをはじめとするバージョン管理システムは、ソースコードなどの変更差分をコミットと呼ばれる単位にして、リポジトリに格納しています。

gitでは、ローカルリポジトリにコミットしたものを、プッシュという作業をすることでリモートリポジトリに変更を反映させます。このようにしてチームメンバーが変更を確認し、自分のローカル環境に取り込むことができます。

gitがあることで、チームで作業するための情報共有を行うことができます。

昔はどうだった？

gitなどのバージョン管理システムが存在しないころは、ファイル名やフォルダ名に日時を書いたり、ソースコードにコメントで修正日時をメモしたりしていました。

このようなアナログなやり方をすると、いくつか以下のような問題点が生じてきます。

• 他の人の更新ファイルを古いファイルで上書きしてしまう。
• 他の人の更新ファイルと自分のファイルを混ぜる時にミス。
• 更新ファイルがほかにもあったことを見落とす。
• ファイルの日付表現が人によって違う。
• 使っていないファイルが本場環境にデプロイされることがある。

昔は毎日のように事故が起きていたそうです。

バージョン管理システムを使用することで、人に頼ったアナログなやり方はしなくてよくなりました。

gitの前に登場したSubversion

Subversionはgitの前に登場したバージョン管理システムで、今でも多くの現場で使われています。

Subversionにはいくつか問題点があり、gitの方が優れていると”言われています”。

こまめにコミットしづらい

Subversionにはローカルリポジトリがありません。

コミットをすると即みんなが使っているリポジトリに反映されますので、コンパイルが通らないようなソースはコミットできません。

ちゃんとした状態になるまでコミットできませんので、コミットとコミットの間が空きがちになります。その期間が長いほどローカルでの変更を追うことは難しくなります。

ブランチを作るとある程度自由になるのですが、自分専用でない限りは制約は出てしまいます。それにローカルブランチが作れませんので、たくさんのブランチを頻繁に作成することにはどうしても躊躇します。

レビューしづらい

gitではブランチを作って、ローカルコミットをして、リモートリポジトリにプッシュします。レビューする人はブランチでのコミットごとに確認できるので、小さい単位で短時間でレビューできます。

ただ、Subversionでもブランチは作れますし、小さい単位でコミットもできます。

gitがレビューしやすいと言われているのは、gitの利点というより、GitHubやBitbucketのプルリクエストの存在が大きいのはないかと思います。

最後に

バージョン管理システムが無いとチームで作業する際に非常に不便です。

Subversionがgitより劣っているとは思いませんが、どうせならgitの考え方や使用方法に慣れておきましょう。

gitのローカルリポジトリがあるだけでもかなり便利だと思います。