概要
仕事でGitを使うのは大規模サイト、大人数編集の場合が多い。
けど、自分一人で運営している個人サイトをGit管理する場合、そこまでかっちりやる必要はなくなってくる。
（同じようにやってもいいけど冗長になりがち）
その辺のことをざっくりまとめてみる。
大規模サイトの管理は「Git Flow」とかで検索検索。
個人サイトの定義
ここで扱う「個人サイト」の定義は以下。ページ数は目安。
もっと多くても適用できるかもしれない。
- 全ページ合わせて50ページに満たない小規模なサイト。
- 管理者は自分一人。コンテンツの生殺与奪権は全て自分にある。
- 更新頻度はさほど多くない静的コンテンツが主。
- なんらかの個人的な情報・店舗情報などを掲載している、いわゆるホームページ。
- ニュースサイトではない。
材料
- エディタ …好きなの。
- 最近はSublime TextとかAtomとかBracketsとか、フリーソフトでもいいのが揃ってる。
- 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ブランチで編集している間に文言修正もしてしまうはずだが、後で文字だけ変えたくなった時に。
変更手順
ソースコードの修正
- masterからdevブランチを作成。
- 気の済むまでコードを修正し、納得がいったら基本方針に従ってコミットする。
- 何らかのミスで動かなくなった場合は、そのファイルをリセットしてコミット前に差し戻す。
既にコミットしている場合など最悪の場合、ブランチを破棄して1からやり直せる。 - ひと通り修正して各ファイルのコミットが終了し、そこで問題がなければdevブランチをmasterにマージする。
- devブランチを削除する。 また更新したくなったら、1からやる。
マージが終わったらdevブランチを消す（とても重要）。
1回作ったdevブランチを使い続けるということはしない。
そうすることで、SourceTree画面に表示されるツリー表示が綺麗な状態を保つことが出来る。
見た目の問題だけでなく、不要な過去を引きずらない履歴が出来上がる。
文言修正
- masterにあるファイルを編集して文言修正する。
- 変更箇所をコメントに書いてコミット。終わり。
画像ファイルの追加
ソースコードの追加・修正を兼ねる場合
- devブランチを作成。
- 修正したソースファイルと分けてコミットする。
- 確認し、問題なければmasterにマージする。
- devブランチを削除する。
差し替えだけの場合
変更画像をmasterブランチに直接コミットしてもよい。
結果
履歴が追いやすく、何かあった時も差し戻しやすいリポジトリができあがるはず。
業務上やっちゃダメな操作
Git触り始めた時にやりやすい操作を列挙。
「個人サイトを自分一人で管理」ということで、上の要領では許容しているが、業務上は絶対ダメと考えたほうがいい。
やるとだいたい悲劇が起こる。
- masterにコミット→ masterにプッシュ
- 自分のブランチにコミット → masterにプッシュ
- 自分のコミットを（許可無く）masterにマージ