今更感あるが、改めてGitを学習したのでその備忘
基本的なことのまとめの為、細かいコマンドなどは省略
Gitのデータ構造
- gitはスナップショットで記録する
- データを圧縮してスナップショットで保持している
- 差分保存だとブランチを切るときに時間がかかる
- コミットが直前のコミットを記録している
- 変更履歴をたどることができる
- リポジトリは履歴データのデータベース
- gitとは3つのエリアがある
- ワークツリー→ステージ→リポジトリ
- ステージはコミットの準備
- 変更分だけ記録する
- リポジトリはスナップショットを記録
バージョン管理してたくないファイル
- .gitignoreファイルを作成する
- 自動生成ファイルやパスワード記載ファイルなどの載せたくないファイル
addとcommitとpush
- 作業して変更したファイルの反映
- git add
- ワークツリー→ステージ
- git commit
- ステージ→ローカルリポジトリ
- git push
- ローカルリポジトリ→リモートリポジトリ
fetchとpull
- fetchを基本的に使う方が良い
- fetchでリモートリポジトリからローカルリポジトリへ変更を反映
- mergeでワークツリーに反映
- pullはfetchとmergeを同時に行う
- pullは別のブランチで使うと統合するつもりがなくともmergeされてしまう
ブランチ
- 複数の機能を同時並行で開発するための仕組み
- ブランチを分岐させれば他の人の変更の影響を受けない
- ブランチはコミットIDを記録したポインタ
- HEADは作業ブランチへのポインタ
- Gitはブランチの作成や切り替え、マージが他のバージョン管理ツールより高速
コンフリクト関連の事故が起きにくい運用ルール
- 複数人で同じファイルを変更しない
- pullやmergeをする前に変更中の状態をなくしておく
- pullするときは、pullするブランチに移動してかたpullする
- コンフリクトしても慌てない
ブランチを利用した、開発の流れ
- masterブランチをリリース用、トピックブランチを開発用に作成して進めるのが基本
- バグが起きた時に前のバージョンに簡単に戻せる
プルリクエスト
- 手順
- masterブランチを最新に更新
- ブランチを作成
- ファイルを変更
- 変更をコミット
- GitHubへプッシュ
- プルリクエストを送る
- コードレビュー
- プルリクエストをマージ
- ブランチを削除
リベース
- 変更を統合する際に、履歴をきれいに整えるために使うのがリベース
- マージとの違い
- リベースは履歴が一直線
- マージは枝分かれ
- GitHubにプッシュしたコミットをリベースするのはNG
マージかリベースか
- マージ
- メリット
- コンフリクトの解決が比較的簡単
- デメリット
- マージコミットがたくさんあると履歴が複雑化する
- メリット
- リベース
- メリット
- 履歴をきれいに保つことができる
- デメリット
- コンフリクトの解決が若干面倒（コミットそれぞれに解消が必要）
- メリット
- 作業の履歴を残したい場合・・・マージ
- 履歴をきれいにしたい場合・・・リベース
- 基本的な方針
- プッシュしてないローカルの変更にはリベースを使い、プッシュした後はマージを使う
- コンフリクトしそうならマージを使う
- プルのマージ型
- 通常の形
- マージした記録を残したい場合
- プルのリベース型
- —rebaseをつける
- 記録が残らないので、GitHubの内容を取得したいだけの時