5月10日（土）に開催されたたにぐちまことさんの「ノンプログラマでも今日から使える「Git」でバージョン管理」に参加しました。
もくじ
Git って何？
「Git（ぎっと）」とは、オープンソースの分散型バージョン管理システムです。コマンドラインでも使えますが、Source TreeなどGUIで使えるアプリケーションもたくさんあります。
Gitはプログラマーのもの？
結論から言えば、そんなことはない！とのことです。奥が深いので掘り下げるのは難しいけど、デザイナーなどノンプログラマーにももちろん利用できます。意外だったのは、Gitを使って小説を書いている方がいらっしゃるということでした。テキストであるという点ではコードも文章も似ているのかもしれません。
チームで使うもの？
協業には必須アイテムだというのはわかるのですが、個人の作業を管理するならDropboxなどのツールがあるのも事実。しかし、Gitを使えばわざわざ日付別のファイル名をつけたりする必要はありません。一人作業でも充分使えるそうです。
言葉を覚えればGitはカンタン！
Gitの利用フロー
Gitの基本的な考え方を図にしました。Gitの特徴である「インデックス」があることによって、作業履歴がごちゃごちゃせずにすみます。ステージングとコミットの違いも重要なのでまとめておきます。
-
ステージング
- 簡単に言えば「箱詰め」。倉庫であるリポジトリには箱単位でデータを詰め込めますが、カテゴリ分けしないとあとあと大変。目的別に箱を分ける作業を「インデックスへのステージング」といいます。
-
コミット
- コミットは履歴として積み重なっていきます。各コミットにハッシュという固有のIDがつくので、それをもとにいつの状態に戻すか細かく決められます。
Gitのミソは「いかに丁寧にコミットするか」
Gitで大切なのは、日々のコミットをいかに丁寧に行うか。後でコードを戻すときのことを考えながらの運用が重要です。
たとえば、同じ日に1つのHTMLファイルで「CSSで文字色を変更する」と「タイトルのJPG画像を消す」という2つの作業を行った場合でも、コミットを分けておけば、「文字色だけ戻す」「画像だけ戻す」という対応ができます。一度ステージングしてからコミットしておくと、それぞれコミットすることができるので便利とのこと。
コミットの手順
- （Source Treeの場合）リポジトリを作成し、ローカルのフォルダを選択、コミットするファイルを選択する。
- コミットしたファイルをテキストエディタなどで変更する。
- Gitに登録されたファイルに変更があったことを知らせてくれるので、あらためてコミットする。（コミットすることで、試行錯誤を残すことができる）
- 間違ってファイルを消してしまった場合はコミットしない。
履歴を見て、既存のブランチにチェックアウト（今の自分の状況を破棄して元に戻すこと）する。
合流には「マージ」と「リベース」がある
コミットで作業の履歴を残すことができたので、次は複数のブランチを合流させる必要があります。合流にはマージとリベースという2種類の方法があり、それぞれに適したシチュエーションがあります
- マージ
- 履歴が残るので、マージ前の状態に戻せる。大規模な修正向け。
- リベース
- コミット後は履歴に取り込まれるので残らない。ちょっとした修正向け。
ブランチはいつ作るの？
ブランチ（分岐の記録）をいつ作るかは作業スタイル次第なので、基本的な考え方は以下の通り。重要なのは後で見たときに見やすいかどうかだそうです。
- リリースまでに時間がかかりそう（2、3日）かかりそうな作業
- 実験的な作業（あとでなかったことにできる）
- 全体に大きな影響を与えそうな作業
また、ブランチ名のつけ方は英数字なら自由ですが、ソフトウェア開発では「git-flow」というガイドラインがあります。マスターブランチ（デフォルトのブランチ）と4つのブランチを作り、ルールに従って5つのブランチを使い分けます。Web制作にぴったり即しているわけではありませんが、名付け方がシンプルなので迷うことがなくなりそうです。
チームでGitを使うには
1台のマシンならローカルリポジトリまでで充分ですが、Gitの真価はチームでの作業で発揮されます。外部サーバーにリモートリポジトリを作ることで、複数のマシンでファイルと履歴のやりとりができるようになります。リモートリポジドリの作り方としては、Gitホスティング（Gitのためのサーバー）をレンタルするのが一般的とのことです。よく名前を聞く「Github」もGitホスティングのひとつですが、Githubの考え方はソースコードを公開してみんなで触ってみよう！というものなので、制作案件ではBitbucketやBacklog（有料版のみ）がよく使われているとのこと。
プッシュとプルの手順
リモートリポジドリにファイルを置くことを「プッシュ」、ファイルをローカルに持ってくることを「プル」といいます。
- リモートリポジドリをクローン（ローカルに複製）する。
- 変更をコミットする。
- リモートにプッシュすると、サービスによってはそのリモートリポジドリをクローンしている他のユーザーに通知がいく。
- 別のユーザーがプッシュすると通知がくるので、それをプルすることで常に最新のデータになる。
コンフリクト（競合）の解消方法
複数のユーザーが同じファイルの同じ部分を触ったときに発生するのがコンフリクト（競合）。どちらの変更を反映すればいいのかわからないので、プッシュすることができません。「手動でマージをする」作業です。
- まずリモートをプルをする。（SourceTreeの場合は、「！」アイコンがついたら競合している）
- ソースコードの緑色になっている部分に注目。（<<< HEAD がリモートのもの）
- ファイル内に競合した文字列が書かれるので、エディタで目視で確認し、修正する。
- プッシュができればコンフリクトは解消。
Gitを使いこなせるようになるには
いきなり協業での実戦投入はちょっと…と思っていたら、たにぐちさんがおすすめのフローを教えてくださいました。
- まずはソースツリーをインストール。
- 1人で、テストプロジェクトで試す。
- 1人で、実戦投入する。
- チームで利用する（タグをいつつける、どのブランチでどういう作業をするのか等のルールはしっかり共有しよう）
近々イラストと写真をまとめるためのブログを作りたいなーと思っているので、個人制作でさっそく使ってみます。
