ざっくりGitを理解する

現場で必ず使うGit。

これまでは断片的な知識の寄せ集めとチャッピーに聞きながら、なんとか使える、という状態でした。

体系的に身につけないとな、、と思いようやく重い腰が上がり、今に至ります。

そんなこんなで、Gitについて体系的に学んだ結果を備忘録として書き起こそうと思います。

目次

  • Gitの保存の仕組み
  • Gitの管理の仕組

Gitの保存の仕組み

Gitは「ファイルを丸ごとコピー」した「スナップショット」という形式でデータを保存する。

なぜ、スナップショット形式なのかというと、複数人開発がしやすくなるため。

これまでは差分だけ保存してバージョンを管理していたため、いちいち差分を計算してからマージしなければならず、とても非効率だった。

Gitのようにスナップショットでデータを保存する場合、差分を計算せず丸ごとコピーしたモノに置き換えるだけなので、とても効率的にデータ管理ができるようになる。

Gitの管理の仕組み

Gitは「ワークツリー」「ステージ」「リポジトリ」という3つの場所を用いて管理する。

  • ワーキングツリー:自分が作業している場所
  • ステージ:コミットする変更を準備する場所
  • リポジトリ:スナップショットを記録する場所

を指す。

Gitを使うとなにがいいの?

コミットを辿ることで、直前の状態に戻すことができる。

最新化のタイミング

最新化とはgit pull すること。
適切なタイミングでpull するのが良いとのことだが、どのタイミングでpullするのが良いのだろうか。
結論、下記のタイミングが良いとされる。

  • 1日の作業開始前
  • 新しいブランチを作成する前
  • 他のメンバーがリモートリポジトリに変更をプッシュした時
  • ブランチの切り替え前
  • コミットやプッシュを行う前
  • 長時間作業から戻った後

いっぱいありすぎるので、整理すると

  • 朝一番
  • ブランチの作成、切り替え時
  • プッシュ前
  • 他のメンバーがプッシュした時
  • 長時間作業の場合は1〜2時間を目安

になるかと。

今のうちから癖づけしておく。

リベースとマージの違い

マージは分岐した履歴をそのまま保持して新しいマージコミットを作成する
リベースは履歴を書き換えてあたかも最初から直線的に行われたかのように整理する

つまり、履歴を残して統合するかしないか、の違いってこと

リベースとマージの運用方法については以下の通り

コンフリクトしそうならマージを使う

プッシュしていないローカルの変更にはリベースを使う

プッシュした後はマージを使う

stash, pop, applyの違い

Commitをミスった時の対処法

Pushをミスった時の対処法

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です