git・githubに対する理解があまかったのであらためて再入門したら、理解していないところがわかってきたので改めて説明する。
##[ HEAD ]
現在使用しているブランチの先頭のこと。
コミットを指定するときに~(チルダ)をHEADの後ろにつけることでHEADからの相対位置を表せる。HEAD~1（HEADの一個手前）
^（キャレット）を使うと親が複数あったときにどの親かを選択できる。
##[ margeの種類 ]
fast-forward(早送り)マージ
masterから分岐したdevelopブランチに変更を加えて、masterには変化がない状態でマージをしたとき、masterはdevelopのブランチに移動するだけで完了する。
両方に変更があった場合のマージ
新しく両方の変更が取り込まれたコミットが作られ、masterブランチの先頭はこちらに移動する。
☆ non fast-forwardマージを指定するとfast-forwardマージができる場合でも、新しくコミットを作ってマージできる。これによってブランチごとの変更の特定が容易になる。
##[ rebase ]
分岐元のコミット履歴が最新の同一内容の新しいコミットが作成される。つまりコミット履歴が一直線になり、あとはfast-forwardマージを実行すれば変更は統合される。
rebaseを使用する場合、rebase後はcontinueでfast forward margeができる。
→ 同じブランチから切られた複数ブランチが同時並行で修正されている場合などに便利。
##[ pull ]
動作としてはmargeと同じだが、fast-forwardではない場合自動でマージコミットが作られる。
fetch+margeなので、pullしたときに新しくマージコミットが作られてしまう。
できるだけ、fetch + rebase で行ったほうがコミット履歴がきれいになる。
##[ tag ]
軽量タグ
ローカルで一時的に使用する使い捨て用だったりする。
注釈付きタグ
コメントや署名を追加できたりとできることが多く、リリースタグで使われる。
##[ コミット操作 ]
amend 直前のコミットを修正（以下のような操作ができる）
・コミットメッセージの修正
・コミット内容を後から追加
revert 過去のコミットを打ち消すコミットの作成
reset コミットの状態を戻す
・soft コミットだけを戻す
・mixed インデックス内のコミットごと戻す
・hard ワークツリーでの変更までなかったことにする。
cherry-pick 別ブランチのコミットを抜き取る
rebase -i コミットの整理（統合）・書き換え・入れ替え・削除ができる
squash マージする際にコミットをすべてまとめてからマージする
##git・githubの運用の仕方に関すること
###【git flow】
・メインブランチ
masterとdevelopの２つのブランチがある。
・サポートブランチ
タスクごとに「feature」「release」「hotfixes」のいずれかのブランチを作成し、作業を行う。
*feature （master、develop、release-*、hotfix-以外）
developから分岐したブランチ。developにマージされる。
機能開発やバグ修正などの作業に利用する。
release（release-*）
developから分岐したブランチ。masterとdevelopにマージされる。
リリース準備作業を行う
hotfixes（hotfix-*）
masterから分岐したブランチ。masterとdevelopにマージされる。
リリース後に緊急の修正作業が発生した場合は、masterブランチからホットフィックスブランチを作成し、修正作業を行う。
☆ git flowというツールをinstallすることで、git flowに沿ったブランチ構成で開発ができる。
git flow ~というコマンドを使えばより効率的な開発が可能。
###【GitHub Frow】
git frowに比べるとシンプルだが以下のルールが有る。一日に複数回デプロイするようなシステムで有効。
１，masterブランチは常にデプロイ可能である
２，作業用ブランチをmasterから作成する
３，作業用ブランチを定期的にプッシュする
４，プルリクエストを活用する
５，プルリクエストが承認されたらmasterへマージする
６，masterへのマージが完了したら直ちにデプロイを行う