Gitで始めるバージョン管理

Tools

もはやバージョン管理と言えばGitですね。
とりあえずこれさえ覚えておけば、という頻出のコマンド例をメモしておきます。

はじめに

バージョン管理システムとは、要はファイルの変更履歴（変更箇所や変更された順番）を管理するもの、です。Gitは分散型のバージョン管理システム、と言われていますが、多人数でコードを共有しようとするとやはりサーバが必要になります。Githubや、GitlabなどGithubのクローンでソースコードをサーバで管理するケースがほとんどでしょう。

Gitで変更履歴を管理する場所をレポジトリ（リポジトリ）といいます。
サーバで管理されているソースコード一式（リモートレポジトリ）を、
手元のパソコン（ローカルレポジトリ）へコピーしてきて変更（＝ソフトウェア開発）し、作業が完了したらサーバに送信して反映する、
というのがここで記載するシナリオです。

リモートレポジトリからローカルレポジトリへコピー・同期することをプル、逆にローカルレポジトリからリモートレポジトリへ変更点を反映することをプッシュ、と言います。プログラマ視点で呼び名を付けているのですね。

 

また、チームで作業する際には、開発するモジュールを分担したり、うっかり同じ部分を変更して競合させてしまったり、といったことが発生します。そんなときは、ブランチと呼ばれる機能を使って、作業範囲やチーム体制に応じて複数のバージョンを並行して保管できるようにします。

例えば、masterブランチにはリリース品質のものを配置し、開発用にはdevelopブランチを作成（チェックアウト）して変更を管理、さらにdevelopからサブチームや機能モジュール毎、バグフィックス毎にfeature-xxxブランチを派生させて作業する、といった具合です。この例では、コード開発が完了し、テストが通ったブランチを（競合があれば解消して）再度合流させる（マージ）ことでリリース版を作っていきます。

ブランチの切り方は、いわば開発スタイルなので、開発手法として複数のパターンが知られています。が、脱線するのでここでは深入りしません。

インストール

WindowsでGitを導入する場合は公式（https://git-scm.com/）からダウンロードしてインストールします。ウィザードの設定値で問題ないので、インストール特に迷うところはないと思います。

初期設定

ユーザ名を設定します。まあお約束です。
ここでは--globalオプションでデフォルトの値を設定していますが、このオプションを付けないでレポジトリ毎に設定することもできます。

ローカルレポジトリの作成

ここでは２つのやり方を記載します。既にリモートレポジトリで開発が進んでいる場合はパターン１、開発をいちから始める場合はパターン２です。レポジトリに設定されたディレクトリには、.gitサブディレクトリが自動的に作成され、設定ファイル等が格納されます。

パターン１：リモートレポジトリからのクローン

おそらく最も頻度の高いケース。
Githubなどリモートレポジトリからソースコード一式をコピーします。
単にソースファイルのコピーだけではなく、変更履歴を含めて持ってくる意味で、コピーではなくクローンと名付けられているのでしょう。

カレントディレクトリの直下に、レポジトリ名(上記の例ではproject)と同じ名前のサブディレクトリ（＝ローカルレポジトリ）が作成され、ソースコード一式が保管されます。
サブディレクトリの名前を続けて書いてリモートレポジトリとは別の名前を指定することもできます。

パターン２：ローカルレポジトリでの初期化

そもそも手元のローカルレポジトリで開発を始めて、その後リモートレポジトリへ公開するケース。
リモートに空のレポジトリがあるものとします。

originはリモートレポジトリのエイリアス（別名）。masterブランチはデフォルトのブランチで、通常は削除することができません。

ローカルでの開発作業

コーディング作業を行う際には、ブランチを作成して変更を行い、作業が完了したらサーバへプッシュします。

ブランチの作成

ブランチを新規作成しつつ移動するには、-bオプションを指定します。

ちなみに、git branch -aでブランチの一覧を表示できます。
下記がその例ですが、ローカルで作成されているmasterブランチとdevelopブランチは、リモートレポジトリ上のorigin/masterブランチとorigin/remoteブランチからは区別されていることが分かります。ローカルとリモートのレポジトリは、pushやpullが行われるまで同期されることはありません。

リモートレポジトリとの同期

他のチームメンバがリモートデポジトリのdevelopブランチを更新していた場合は、
最新のコミットと同期するためにプルします。

コミットとプッシュ

ソースコードを変更したら、変更箇所をステージングし、ローカルレポジトリにコミットします。
ふつうはコミットするまで他のブランチに移動（チェックアウト）できません。

例えばdevelopブランチにある時など、現在のブランチをプッシュすると、リモートでも指定した名前のブランチが作成され、サーバで公開されます。

masterブランチへ移動（チェックアウト）、developブランチをmasterブランチへマージしたのち、リモートレポジトリへプッシュ。
ここでのマージは、ローカルレポジトリのブランチを合流させる作業なので、マージしたものをプッシュしてリモートレポジトリに反映させる必要があります。

マージした後、作業ブランチが不要になれば、削除することもできます。

おわりに

ここではカバーできなかったことはまだ沢山あります。
マージするときに競合したら実際どうすんの、とか、レポジトリから除外したいファイルがあるんだけど、とか、前のコミットまで巻き戻したいんだけど、とか、プルリク（マージリクエスト）とかどうやんの、とか。

その話はまた今度。