MENU
  1. ホーム
  2. Development
  3. 初心者がGitを学んでみた

初心者がGitを学んでみた

Development
【PR】SAPテンショクの相談申し込みサイト
目次

学習の経緯

個人開発でバージョン管理に困っていたので、Gitについて学習しました。また、Recursionというオンラインサービスでも学習をしており、そこでもGitを学んだため自分なりにまとめてみようと思います。

Gitとは

ソースコードのバージョンを管理するオープンソースのツールです。ソースコードの変更履歴などすべてをリポジトリで管理します。複数のPCで作業していたとしても、GitHubのような管理ツールを使うことでローカルのリポジトリの情報をサーバーにアップロードして管理することができます。

Gitは基本的に、その時の全てのファイルの状態のスナップショットを撮り、そのスナップショットへの参照を格納するのです。効率化のため、ファイルに変更が無い場合は、Gitはファイルを再格納せず、既に格納してある、以前の同一のファイルへのリンクを格納します。Gitは、むしろデータを一連のスナップショットのように考えます。

3つの状態

開発を行う際、ローカルのPC上ではファイルは「Working Directory」として存在しています。ファイルに何かした変更があった場合には「Staging Area」にあげます。ステージングエリアに上げたら、コミットすることでそのファイルをリポジトリに格納することができます。リポジトリにあるファイルはブランチで管理されており、コミットの履歴をたどることができます。このようにGitで管理することで、以前のコミット履歴にバージョンを戻すことが可能です。

Git 3ステートフロー
Working Directory → Staging Area → Repository の3つの状態

ファイルの状態

Gitファイル状態
Untracked（追跡されていない）と Tracked（追跡済み）の違い

新規ファイルを作成した場合

この場合はuntracked（未追跡）となり、gitがバージョンを管理できていません。一度ステージングエリアにあげて追跡可能な状態にする必要があります。

ファイルの変更を行った場合

一度コミットしているので、ファイルの変更部分が管理されます。

ファイル変更の検知

Gitでは内部で「チェックサム」が使用されています。チェックサムとは、データが送受信時や保存時に破損したり改ざんされたりしていないかを確認するために算出される「検証値」のことです。チェックサムを使うことでファイルの変更点やファイルが破損していないかを検知します。

具体的には「SHA-1ハッシュ」が使用されており、16進数の文字が40文字（20バイト）並んでいます。

24b9da6552252987aa493b52f8696cd6d3b00373

Gitではコミット名にこのようなハッシュ値が使用されており、その名称を追跡します。

確認方法

以下のコマンドで簡単にファイルの状態を確認することができます。

ABAP
git status
git status

新規ファイルを作成した場合（未追跡）:

echo 'My Project' > README
git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
  README
nothing added to commit but untracked files present (use "git add" to track)

ファイルの変更のみ行った場合:

git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   CONTRIBUTING.md

addとcommit

「add」と「commit」についていまいち違いが分からないというか、ステージング（git add）の必要性が分からないというのが正直なところです。なぜファイルをステージングエリアに追加する必要があるのでしょうか。

ステージングとは、作業ディレクトリの変更を「次のコミットに含める操作」として登録する操作です。つまり、このような表現で例えることができます。

「カゴに商品を入れる（add）」 → 「レジで会計する（commit）」

基本的なコマンドのまとめ

# 外部URLからリポジトリを複製
git clone [URL]
# ローカルにリポジトリ作成
git init
# ステージングエリアに追加
git add [file名]
# コミット
git commit
# git commit -m "コメント"
# GitHubリポジトリにPush
git push

前回のコミット履歴に戻る場合

作業していて、前回のコミット履歴に戻りたい時に困ったことがありました。Untrackedファイル（新規追加したファイル）と編集したファイルの両方がコミットされていない場合、一旦新規追加したファイルを削除した後コミット履歴を戻す必要があることがわかりました。

# ステータスの確認
git status
# Untrackedファイルを削除
git clean -df
# Staged/Modified状態の変更を破棄し、HEADを現在のコミットにリセット
git reset --hard HEAD

⚠️ 注意: git clean -df と git reset --hard は取り消しできない破壊的操作です。実行前に変更のバックアップやブランチを作成してください。

推奨のやり方（目的別）

公開ブランチで履歴を壊さずに戻したい（おすすめ）

git revert HEAD
git push

まだpushしていない直前のコミットを作り直したい

# 変更を保持したまま一つ前に戻す
git reset --soft HEAD^
git commit -m "やり直しのコミット"

作業ツリーの変更だけ捨てたい／ステージ解除したい

# 作業ツリーの変更を破棄
git restore <file>
# ステージ解除
git restore --staged <file>
# 一時退避（未追跡も含める）
git stash -u

チェックアウト

git switch（推奨）や git checkout でブランチ間を移動できます。

ブランチについて

ブランチは「コミット列の先頭」を指すラベルで、HEADは「いま作業中のブランチ」を指すポインタです。この関係を理解すると仕組みが掴みやすくなります。

# 新しいブランチを作って切り替え（推奨）
git switch -c feature/awesome
# 既存ブランチに切り替え
git switch feature/awesome
# 互換コマンド（昔からある書き方）
git checkout -b feature/awesome  # 作成 + 切替
git checkout feature/awesome     # 切替

HEADポインタが指し示しているブランチに対してGitコマンドの操作が反映されます。ブランチを切り替えると、HEADはそのブランチを指すようになります。

GitブランチとHEAD（switch前）
git switch前のHEADポインタとブランチの関係
GitブランチとHEAD（git switch後）
git switch後、HEADポインタが移動した状態

マージ

複数のブランチをマージすることができます。基本は、作業ブランチ（例: feature/awesome）をメインブランチ（main）へ取り込む操作です。

Fast-forward（早送り）

main が分岐後に進んでいなければ、ポインタを前に進めるだけの単純な取り込みになります。

git switch main
git merge --ff-only feature/awesome

マージコミット

main も進んでいる場合は、分岐を一つにまとめるコミットを作ります。

git switch main
git merge feature/awesome  # 必要に応じて --no-ff

コンフリクトが起きたら

  1. 競合ファイルをエディタで解消（<<<<<< ====== >>>>>> の印を編集）
  2. 解消したファイルをステージ: git add <file>
  3. マージを完了: git commit

パッチファイル

変更したソースコードなどをまとめたファイルをパッチファイルと呼ぶ。

# パッチファイルを作成
git diff > changes.patch
# パッチファイルを適用
git apply changes.patch
# 元に戻す
git apply --reverse changes.patch

Gitサーバー（リモート）

GitHub / GitLab / Bitbucket などのホスティングサービスを「リモート」として登録してやり取りします。

初回の接続とプッシュ

git remote add origin https://github.com/<user>/<repo>.git
git branch -M main
git push -u origin main

更新の取得と反映

git fetch origin
git merge origin/main  # マージで取り込み
# または
git rebase origin/main  # リベースで取り込み（履歴を直線化）

git switch main
git pull --ff-only  # 予期せぬマージコミットを避ける

プルリクエスト（PR）の実務フロー

  1. 作業ブランチを切る: git switch -c feature/awesome
  2. 小さな論理単位でコミット: git add -p → git commit -m "Add awesome thing"
  3. リモートへプッシュ（初回は追跡設定）: git push -u origin feature/awesome
  4. GitサーバーでPRを作成（base: main / compare: feature/awesome）
  5. 説明・スクリーンショット・関連Issueを記載
  6. CIが通るか確認 → レビュアーに依頼
  7. フィードバック対応
  8. マージ（チーム方針に合わせてSquash mergeまたはMerge commit）
  9. 後片付け: git branch -d feature/awesome / git push origin --delete feature/awesome

PR前のセルフチェック（おすすめ）

# 差分の最終確認
git diff main...HEAD
# 履歴の見やすさ
git log --oneline --graph --decorate
Development
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！
目次