お手軽Gitの導入
PCで何か作業をされている方にとって、バージョン管理ツールは非常に有用です。プログラミングを行う方がプログラムを管理するときに特に効果的ですが、プログラムに限らずPC上の作業全般で使えます。
Git(ギット)という言葉を聞いたことはないでしょうか。バージョン管理システムといえばいくつかあるのですが、とりあえずGitが有名でしょう。ただ、Gitは導入がちょっとめんどくさい印象があるため、本記事ではGitGUIを使い、Git導入の敷居を下げることを目的とします。シンプルに、個人作業の導入例だけの紹介です。といっても長いので、必要な節だけつまみ食いしてください@_@
Gitの概要 個人作業でも十分有用です
Gitは、バージョン管理ツールを使ってバージョン管理をする一連のシステムのことを言います。具体的にはこんなことができます。
図の左側を、実際に進められているプロジェクトとします。プロジェクトが進むにつれ、色々なものが追加されていきます。この追加部分は、PC内の実際のファイル更新に相当します。作業成果ですね。これらの変更履歴を、Gitリポジトリというデータ保管庫にその都度登録していくのです。プロジェクト全体のバージョン管理がこのGitリポジトリで出来るようになるわけです。
こうしておくと便利なことが色々あります。
- いつどんな変更をしたのか一目で分かる。
- 元のデータが破損しても、履歴をもとに復元できる。
- 過去のバージョンに戻して作業をすることもできる。
整理がつきやすいのが、分かりやすい利点の一つでしょう。ちょっと進んだ使い道として、こんなことも可能になります。
レストランの原型としてプロジェクトを開始し、途中でお店の種類を分けてしまうというものです。レジと客席という共通部分まで作り終えたら、回転寿司屋を作る場合お寿司のレーンの追加、焼肉屋を作る場合は席に網を設置する、というように分岐させます。
このように分岐したバージョンそれぞれのことをブランチというのですが、ブランチを切り替えながら好き勝手にプロジェクトを進めていくことが可能となるわけです。
共同作業では更に便利なGit
個人作業の際にも便利なGitですが、複数人で共同作業を行うときには更なる威力を発揮します。
実際、複数人で計画を立ててファイルを更新していくというのは面倒な印象があると思います。同じファイルを他の人も更新していたことに気づかず、ああっ、間違えて自分の更新部分しか反映されてないファイルで上書きしちゃった、とか。共同でやるんだから、そういうことは仕方ないとして割り切るのも手ですが、Gitはそういった問題も解消してくれます。
個人作業で使っていたリポジトリは各々がローカルリポジトリとして保持しておき、インターネット上のどこかに共通で使う専用のリモートリポジトリを置いておきます。
開発者たちは基本自分のローカルリポジトリを使って作業をして、ある程度できたらネット上のリモートリポジトリに更新分を投げます。この操作をプッシュといいます。
このとき、もし他の人が同じファイルを編集していて、そのまま上書きするとどちらかの更新分が塗りつぶされてしまう状況になってしまうとしたら、きちんとエラー表示を行って塗りつぶさないようになっています。この状況をコンフリクトといって、もしコンフリクトが起こったら、他の人の更新分を自分の分にきちんと反映させて再度プッシュを行います。これにより、同じファイルいじっちゃってた問題は解消されるわけです。
ね、なかなか便利でしょ。でも今回は残念ながら共同作業のやり方についてはご割愛です。
Gitを導入しよう!
それでは実際にGitを導入して、個人作業におけるバージョン管理をやってみましょう!
Gitは上記に挙げたようなシステムの名前のことで、このシステムを運用するためのツールが必要になります。ツールは色々ありますが、これさえ使えばバッチリだわ!!みたいなものに中々出会わない印象です。
今回はシンプルかつ軽量で、見てだいたい操作が分かる、導入にはうってつけのGitGUIを使ってみましょう。*1
こちらのサイト↓の「Download 2.16.1 for Windows」みたいに書いてある部分をクリックしてダウンロードしてください。(バージョン番号は変わってるかも)押したら自動でダウンロードが始まると思います。
ダウンロード後、インストールを行います。何も読まずにデフォルトのままNextを押していって問題ないと思います。これでインストールは完了です。
GitGUIを使ってコミットをする
インストールが終わったら、スタートメニューにGit > GitGUIの項目が追加されています。これを選択してください。
↓GitGUIのスタート画面です。残念ながら英語です。日本語化の方法もありますが、割愛です。Create New Repositoryでリポジトリの新規作成、Open Existing Repositoryで既存のリポジトリを開く、です。一番上の新規作成を選択しましょう。
新規作成を選択すると、どこに作るのかを聞かれます。空のフォルダ内にしか作れません。どこかに空のフォルダを作って、それを指定しましょう。ここでは「git_sample」という名前にしておきます。日本語名でも大丈夫だと思いますが、たまに指定時にエラーになるので、今回は無難に半角文字でいきます。
リポジトリを作るとメイン画面らしきものが出てくると思いますが、一旦放置して、さっき作った「git_sample」のフォルダの中を見に行ってみましょう。こんなものが新たに追加されています。
この透明な「.git」というフォルダがGitリポジトリの内部データです。コレがあるフォルダがGitリポジトリという意味になります。git_sampleはGitリポジトリになれたということですね。冒頭で図示した、バージョン管理データ保管庫です。隠しファイルを見えなくするの設定にしていると表示されないかもしれませんが、どっちみちこのフォルダ内を手でいじることはしないので、放置でOKです。
最初の変更を加えましょう。git_sampleフォルダ内に適当なテキストファイルを追加します。
ファイルを追加したので、GitGUIのメイン画面に戻りましょう。下部のボタン群にある「Rescan」を押すと、左上のUnstaged Changesにさっき追加したファイルが表示されます。
この変更を、Gitリポジトリに記録することにしましょう。操作の流れはこんな感じです。
- Rescanを押して、変更のあったファイルをUnstaged Changesに表示させる。
- Stage Changedを押して、ファイルをStaged Changesに移動する。
- 右側のCommit Messageの欄(初回ではInitial Commit Messageになってます)にコミットメッセージ(後述)を記述する。
- Commitを押して、コミットする。
変更履歴にはメッセージを付けることができて、メッセージと一緒に変更履歴を保存する仕組みになっています。この保存操作をコミットといいます。コミットメッセージは慣習により1行目をタイトル、2行目を空行、3行目以降を詳細説明、とします。個人で使う分にはあんまりたくさん文字を書いているとめんどくさくなりそうなので、自分用に適当でいい気がします。
コミットが完了するとまた真っ白に戻ります。変更履歴の表示画面で確認しましょう。
RepositoryメニューのVisualize All Branch Historyを選択します。変更履歴の確認画面です。
左上に変更履歴が羅列されます。現在は1回しかコミットしていないので、1個だけですね。変更履歴の単位をコミットと呼びます。
コミットを選択すると、そのときのコミットメッセージ、変更のあったファイルがそれぞれ表示されます。こんな具合ですね。これを繰り返して作業をしていくことになります。
ブランチを分ける
冒頭の図に登場した、ブランチを分けた作業をやってみましょう。新しいブランチを作るには、分岐点になっているコミットで右クリックし、Create new branchを選択します。
ブランチの名前を記述します。sushiにしました。
これでsushiブランチが出現します。ちなみに、元からあるブランチはmasterブランチといいます。masterが一番上にあって太字になってますよね。太字のブランチが現在取り入れているブランチです。
sushiブランチに切り替えましょう。sushiの部分で右クリックしてCheck out this branchを押します。sushiが太字になって、ファイルの内容がsushiブランチのコミットに戻っていますよね。
この状態でファイルを再び更新します。すると、さっきの最新版であったmasterブランチとは別の変更をしたことになりますから、コミットをすると次のように枝分かれします。
このようにすれば、各々のブランチを切り替えながら作業をすることが出来ます。
ブランチをマージする コンフリクトの解消が必要です
複数に分かれたブランチを、再び一つに統一してしまうことも可能です。この操作をマージといいます。ただし、マージをすると各々の変更点が被る場合がありますので、そうなったら被っている部分を解消する必要があります。
GitGUIのメイン画面からMerge > Local Mergeを選択します。
どのブランチとマージするかを尋ねられます。上図は現在のブランチがsushiになっている例なので、masterブランチとマージする、という画面になっています。逆にmasterブランチにいる場合はsushiが表示されます。どっちでもいいです。
masterを選択してMergeを押します。
何事もなければマージ完了なのですが、変更点の被るファイルがあると、上のようにコンフリクトエラーが表示されます。
メイン画面にコンフリクト箇所が表示されています。実際にファイルを見てみると……
何やら奇妙なコードが付記された状態となっています。これは、masterブランチとsushiブランチで同じファイルを変更してしまって、それぞれのこの部分が被ってるんですよ、ということを表しています。
今回はsushiブランチからmasterブランチをマージする、という例ですので、HEADの直下にはsushiブランチの内容、=======を挟んでその下には、これからマージしようとしているmasterブランチの内容が入っています。
それぞれの変更点を吟味して、どう修正するべきかを考えます。修正の仕方は場合により様々です。今回は↓こんな感じにしてみました。
修正後、GitGUIのメイン画面に戻ってRescanをします。
内容は反映されていますね。コンフリクトが続いている状態なので、解消してマージするということで若干手続きが異なります。
Commit > Stage To Commit を選択してマージ結果をStaged Changesに移動し、下部のCommitボタンからコミットをします。コミットメッセージは元々書いてある通りのものを採用しても、何でもいいです。
コンフリクトを解消し、無事にマージすることが出来ました。sushiブランチがてっぺんに来てしまいましたが、ブランチの名前などどうでもいいので、別にmasterブランチがメインでなくてもOKです。ブランチは名前を変更したり削除したり自由にできるので、この場合気になるようでしたらmasterを削除し、sushiをmasterにリネームすればよいと思います。
ブランチを分けて後でマージするという方法の使い道として、例えばちょっと大規模な部分機能を追加するという場合にブランチを分けておいて、最後にmasterブランチに連結するという方法があります。そうすれば機能ごとに作業を分けられるので、やっている作業が明確になりやすいのです。
以上でGitの導入は終わりです。慣れるまでとっつきづらい印象のあるGitですが、慣れてしまえば、こんなに便利なものはありません。上記の基本操作をマスターしたら、他にもいろんな機能があるのでぜひ色々やってみてください。
個人作業でも、ネット上にリモートリポジトリを置いて作業をするということはよく行われています。GitHubというサイトに自分のリポジトリを置いておいて他の協力者さんを募って編集してもらうとか、そんな感じの使い方もできます。今回はリモートの使い方は割愛していますが、慣れてきたら導入おすすめします。
よきよきバージョン管理ライフを><
*1:個人的オススメはSourceTreeなのですが、重くて開くのが億劫になるという問題を抱えています。その他は何も不満がないので、非常に惜しいです……