概要

仕事でGitを使うのは大規模サイト、大人数編集の場合が多い。
けど、自分一人で運営している個人サイトをGit管理する場合、そこまでかっちりやる必要はなくなってくる。
(同じようにやってもいいけど冗長になりがち)
その辺のことをざっくりまとめてみる。

大規模サイトの管理は「Git Flow」とかで検索検索。

個人サイトの定義

ここで扱う「個人サイト」の定義は以下。ページ数は目安。
もっと多くても適用できるかもしれない。

  • 全ページ合わせて50ページに満たない小規模なサイト。
  • 管理者は自分一人。コンテンツの生殺与奪権は全て自分にある。
  • 更新頻度はさほど多くない静的コンテンツが主。
  • なんらかの個人的な情報・店舗情報などを掲載している、いわゆるホームページ。
  • ニュースサイトではない。

材料

  • エディタ …好きなの。
  • SourceTree
    • 俺はコンソール派だっていう人はそれも可。でもソフト使った方が楽だし、履歴が追いやすい。

基本方針

  • 1コミット1ファイル。
  • コメントをちゃんと付ける。
  • ソースの修正はdevブランチでやる。
  • 文字部分のみの修正はmasterでやって可。

1コミット1ファイル

1ファイル変更したら、変更点をコメントに記載してそのファイルをコミットする、という手順が基本。
別の視点から言うと、「違う変更点を持つファイルを1度のコミットで扱わない」。

利点は1ファイルずつコミットしておくと、後々チェリーピック機能を最大限活かせること。
(チェリーピック…特定コミットで行われた変更だけを最新版に適用する機能。部分的な差し戻しが可能となる)

変にまとめてコミットしてしまうと、チェリーピックした時に「こっちのファイルの変更は必要だけどこっちの変更はいらない!」ということが起きてしまう。

※特定のコミットのファイルを選択し、右クリック→「コミットまで戻す」を利用することで、1ファイルずつ差し戻す機能があるので、まとめてコミットした場合でもファイル単位での差し戻しは可能。

例外的に「ページをまたがって全く同じ変更をしたファイル群」は1回のコミットに収めた方が良い。

1ファイルのコミットを変更点ごとに分ける

1ファイルに複数箇所の変更点が含まれる場合、コミットを分けることも検討する。
例:ヘッダーの変更とフッターの変更が入ったファイル。

  • ファイルを編集する。
  • ファイルごとステージに追加するのではなく、SourceTreeの「Hunkをステージに移動」で、変更単位ごとにステージに追加する。
  • コメントを書いてコミットする。

バイナリ(画像)ファイルの扱い

原則的にソースファイルと分けてコミットする。
バイナリファイルだけのコミットとして1度にまとめてやっても良い。
チェリーピックを使いそう、と思うものは単体でやっておくのが理想的。

画像ファイルをまとめて扱う場合も、最低限のグループ単位に分けてコミットした方が良い。
例えば使用しているページ単位、コンテンツ単位、保存しているフォルダ単位など。
画像だからといって十把一絡げにコミットしてしまうと、そのコミットでどのページのどんな画像を追加したのかが後で分かりにくくなる。

バイナリファイルはテキストファイルと違って、差分管理をしないので、
バージョン管理しないのも手。
元々Gitで管理するには向いてない。

PSDやAIファイルは絶対にGitで管理しない方が良い。
10MBのバイナリファイルは、Gitでコミットするごとに保存容量が10MBずつ増えていくと考えて良い。
なので、100MB超えのファイルをコミットしまくると、あっという間に死ぬ。

バージョン管理しない場合、gitignoreでディレクトレリ指定して、画像ファイルの変更・更新を無視するようにすると良い。

コメントをちゃんと付ける

自分一人で管理しているし、気取って英語であれこれ書く必要はない。
日本語で、変更点を簡潔に書く。

参考になる投稿は以下。なんだかんだ言っても、Git管理する肝は結局コメントだったりする。
2番目のは英語の書き方ではあるが、日本語を使うときにも適用できる。

「バグを修正」「◯◯を更新」のような抽象的なコメントは書かないようにする事が大事。
コメントをちゃんと書こうとすると、変更点がたくさん入ったコミットより、
変更点が絞られたコミットの方が書きやすいことがわかるはず。

ソースの修正はdevブランチでやる

masterはいつでもリリース可能な状態に保つため、HTMLタグやCSS、JS、その他スクリプトの編集はdevブランチで行う。
リリースごと、機能毎に細かくブランチを分ける必要まではないが、
無茶なことをやってもいつでもmasterに戻れば編集前の状態にできるようにしておく。

CGIとか、1文字ミスっただけでエラーが起きる言語もこれで安心。

文字部分のみの修正はmasterでやって可

サイト構成に影響しない、文言「のみ」の修正はmasterブランチでそのままやってもいい。
やってもいいだけで、devブランチでやったらダメという訳ではない。
通常はdevブランチで編集している間に文言修正もしてしまうはずだが、後で文字だけ変えたくなった時に。

変更手順

ソースコードの修正

  1. masterからdevブランチを作成。
  2. 気の済むまでコードを修正し、納得がいったら基本方針に従ってコミットする。
  3. 何らかのミスで動かなくなった場合は、そのファイルをリセットしてコミット前に差し戻す。
    既にコミットしている場合など最悪の場合、ブランチを破棄して1からやり直せる。
  4. ひと通り修正して各ファイルのコミットが終了し、そこで問題がなければdevブランチをmasterにマージする。
  5. devブランチを削除する。 また更新したくなったら、1からやる。

マージが終わったらdevブランチを消す(とても重要)。
1回作ったdevブランチを使い続けるということはしない。
そうすることで、SourceTree画面に表示されるツリー表示が綺麗な状態を保つことが出来る。
見た目の問題だけでなく、不要な過去を引きずらない履歴が出来上がる。

文言修正

  1. masterにあるファイルを編集して文言修正する。
  2. 変更箇所をコメントに書いてコミット。終わり。

画像ファイルの追加

ソースコードの追加・修正を兼ねる場合
1. devブランチを作成。
2. 修正したソースファイルと分けてコミットする。
3. 確認し、問題なければmasterにマージする。
4. devブランチを削除する。

差し替えだけの場合
変更画像をmasterブランチに直接コミットしてもよい。

結果

履歴が追いやすく、何かあった時も差し戻しやすいリポジトリができあがるはず。

業務上やっちゃダメな操作

Git触り始めた時にやりやすい操作を列挙。
「個人サイトを自分一人で管理」ということで、上の要領では許容しているが、業務上は絶対ダメと考えたほうがいい。

やるとだいたい悲劇が起こる。

  • masterにコミット→ masterにプッシュ
  • 自分のブランチにコミット → masterにプッシュ
  • 自分のコミットを(許可無く)masterにマージ