Git初心者のためのメモ書き

コミット

コミットとは、新規ファイルの作成、既存のファイルの変更、不要なファイルの削除、ファイルのリネームなどの変更にメッセージをつけてリポジトリに登録する操作である。コミットした内容に誤りがあった場合でも修正を行いやすくするために、 基本的には一つの作業を終えるごとにコミットする ことが望ましい。

コミットメッセージを分かりやすく書くコツ

コミットメッセージは、 端的に誰が見てもわかるようなものにする というのが大前提。例えば、メッセージ入力欄の1行目に書いたメッセージは、そのままコミットの一覧に表示されるため、ここにはコミットのタイトルや概要を記入すると良い。さらに詳しい添え書きは、一般的には2行目を空白とし、3行目から詳細を記述する。

コミットメッセージの書き方

1行目: コミットのタイトルや概要
2行目: 空行(1行開ける)
3行目以降: コミットの概要や詳細を記入

わかりやすいコミットメッセージの例

1行目: h1見出しデザイン追加
2行目: 空行
3行目: 埋もれている見出しの視認性の向上のため

わかりにくいコミットメッセージの例

以下だと何を変更したのかわからない

バージョンアップ

バグの修正

フェッチ(fetch)とマージ(merge)

リモートリポジトリの最新の状態を取得する作業がフェッチ(fetch)。フェッチはリモートリポジトリに関する情報を更新するだけで、ローカルの状態をリモートに合わせるわけではない。そこでローカルの状態を、取得した最新のリモートリポジトリの状態に合わせるのにマージ(merge)を行う。

originとmaster

「origin/maseter」の「origin」は、リモートリポジトリの場所(URL)の別名であり、「master」はリモートリポジトリのブランチ名。

管理しないファイルを指定する

バージョン管理しないファイルを指定するには、「.gitignore」というファイルを作成する。Gitでは、.gitignoreに記述されたファイルはバージョン管理を行わない。.gitignoreの書式は以下のとおり。

書式 説明
# #から始まる行は、コメント行
! !から始まる行は、その行で指定したものを除外しない。
test.txt 指定したファイルを除外する。
/test.txt 先頭の「/」はルートディレクトリを指す。つまりルートディレクトリ直下にある「test.txt」が無視される。
testdir/ 名前が/で終わる場合、該当する名前のディレクトリのみを指す。
*.psd 「.psd」の拡張子がついたファイルすべてが無視される

.gitignoreの記述例

# ここはコメント
# 拡張子が.logのものを除外する
*.log

# 上記で.logファイルはすべて除外したが、test.logのみは管理に含める
!test.log

# ファイル名sample.htmlを除外する
sample.html

# ルートディレクトリにあるsampledirという名前のディレクトリ以下を除外する
/sampledir

# dirという名前のつくディレクトリ以下を除外する
dir/

ブランチでフォルダを管理する

Gitを利用する大きなメリットの一つが「ブランチ(branch)」である。通常、トップページなど主要ページのデザイン・リニューアルが予定されているWebサイトで、制作作業中に現在公開しているサイトの更新作業も同時に行わなければならないような場合、2つの作業を並行して進めるためには、現在公開中のサイトに対する更新作業のための環境と、リニューアル作業を行うための環境といった2つの開発環境を用意する必要がある。

一般的に、こういった2系統の作業環境で進めた場合は、互いの進捗管理が煩雑になり、「先祖返り」といった不具合が発生するなどのリスクをはらんでいる。

Gitがあれば現在公開中のバージョンを一つのブランチとして管理し、リニューアル作業も一つのブランチとして管理することで、安定したバージョンを破壊することなく、新たに機能追加をすることができる。

ブランチのメリットを要約すると以下のとおり。

  1. 同時に複数の作業の状態を独立して保持して、作業をできる。
  2. 一旦現在の作業を保流して、横から入った作業を行える。
  3. 同時に複数の作業を並行したい場合に、リポジトリを複数用意する必要はなく、一つのリポジトリの中に複数のブランチを作成することで解決できる。
  4. 過去のある時点の作業中の状態に戻ったり、最新状態に戻すことも自由自在。

ブランチの作成と切り替え

Gitリポジトリを作成した時点では、「master」というブランチが一つだけ作成され、これが最初に作成されるマスターとなるブランチである。

ブランチは任意のタイミングで作成することができ、Source Treeでは画面上部の「ブランチ」ボタンをクリックすると、「新規ブランチ」が作成できる。

実際には、ブランチは任意のコミットを起点として作成することになり、現在作業しているブランチをもとに新しいブランチを作成する場合は「作業コピーの親」を選ぶ。また、新規ブランチを作成した後、すぐに新しいブランチで作業するのであれば、「新規ブランチを作成してチェックアウト」を選ぶ。

チェックアウト(checkout)

一般的にはホテルなどで勘定をすませるといった意味だが、 Gitでは「図書館で本の貸出手続き」を行うといったイメージ。つまり、読んでいた本を戻して、別の本を書架から取り出すようなイメージ。Gitでは、作業対象となるブランチ(コミット)を切り替える時に「チェックアウト」するという。

新たに作成した「taskA」というブランチから、再び 「master」ブランチへ作業対象を切り替える には、ブランチ一覧に表示されているブランチ名(ここではmaster)上で右クリックして表示されるコンテキストメニューから 「masterをチェックアウト」 を選ぶ。

ブランチのマージ

ブランチでの作業が完了した場合、そのブランチでの作業を継続することは望ましくなく、主流のブランチに戻る必要がある。そこで、一時的な作業用として作成したブランチは作業が完了した時点で「派生元」となったブランチへマージする。

前述の例では「taskA」という作業用ブランチを作成したため、このリポジトリにはmasterとtaskAという2つのブランチが存在することになる。そしてtaskAで開発作業を進めてコミットした場合、masterよりもtaskAの最終コミットが先行することになる。

taskAでの作業が完了した際、再度masterをチェックアウトしてから、taskAをmasterへマージする。Source Treeでは、ブランチ一覧に表示されているmasterブランチを右クリックして表示されるコンテキストメニューから「現在のブランチにtaskAをマージ」を選ぶ。

結果、taskAで先行していたコミットがmasterに取り込まれ、masterはtaskAと同じコミット段階まで進む。

ブランチの削除と復元

作業が完了して元のブランチにマージしたブランチをそのままに置いておくのは無意味であり、なおかつ作業の進行とともにブランチが増加し、作業環境全体の見通しが悪くなる可能性がある。そこで、一旦作業が完了したブランチは削除する。

ブランチを削除したとしても、そのブランチで行ったコミットが削除されるわけではなく、任意のコミットに戻ることができる。またtaskAブランチですべき作業が残っていたにもかかわらずtaskAブランチを削除してしまったなど、誤ってブランチを削除したとしても、元のブランチ(ここではmaster)へマージを行なっていれば、任意のコミットを選んでブランチを作成することで、taskAでの作業を再開することができる。

Git初心者のためのブランチ運用のセオリー

ブランチは便利な機能だが、複数人での作業時、各スタッフが各ブランツを作成してプッシュしてしまうと中央リポジトリの管理状態が煩雑化する。したがってブランチの運用には、一定のルールを設けることが重要である。Git初心者のためのブランチ運用のセオリーは以下のとおり。

Git初心者のためのブランチ運用のセオリー

  1. 幹となるブランチ(多くはmaster)を決める。
  2. ブランチは「幹となるブランチ」から派生させる。
  3. ブランチ作業が完了したら元ブランチにマージする。

コメントを残す

メールアドレスが公開されることはありません。