個人サイトをGit管理する場合の要領まとめ

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

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

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

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

# 材料
* エディタ …好きなの。
 * 最近は[Sublime Text](http://www.sublimetext.com/)とか[Atom](https://atom.io/)とか[Brackets](http://brackets.io/)とか、フリーソフトでもいいのが揃ってる。
* [SourceTree](https://www.atlassian.com/ja/software/sourcetree/overview)
 * 俺はコンソール派だっていう人はそれも可。でもソフト使った方が楽だし、履歴が追いやすい。

# 基本方針
- 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番目のは英語の書き方ではあるが、日本語を使うときにも適用できる。

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

- [Gitのコミットメッセージの書き方](http://qiita.com/itosho/items/9565c6ad2ffc24c09364)
- [提言: コミットメッセージの一行目には要求仕様を書け](http://qiita.com/magicant/items/882b5142c4d5064933bc)

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

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

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

# 変更手順
## ソースコードの修正
1. masterからdevブランチを作成。
2. 気の済むまでコードを修正し、納得がいったら基本方針に従ってコミットする。
3. 何らかのミスで動かなくなった場合は、そのファイルをリセットしてコミット前に差し戻す。<br>既にコミットしている場合など最悪の場合、ブランチを破棄して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にマージ