gitについて

Posted at 2025-10-08

gitでのソース管理についてのまとめ

💡 まずゴールのイメージ

「Gitを使える」とはつまり次のことができる状態を指し、これを目指します。

コードの履歴を残せる（変更前の状態に戻せる）
他の人と同じファイルを安全に編集できる（衝突を解決できる）
本番用・開発用など複数のバージョンを管理できる

VSCODEでリポジトリを管理する
まずはローカルで自分でファイルを作成して、作成ファイルの中にデータを保存していく流れになる
ローカルgitリポジトリを作成する。作成した内容をコミットしてローカルに履歴として保存する。
その内容を変更点を確認したり、状態を確認したりになります。ここまでではリモートリポジトリにはまだ反映されていない

Git作業での全体的な流れ
① 作業ディレクトリ（ワークツリー）で変更
　　実際にファイルを編集している場所
↓
② ステージング（git add）
　　変更内容を記録したいをマークする場所
↓
③ ローカルにコミット（git commit） ←ここまではローカルの中だけ
　　ローカルに変更内容を履歴として保存する
↓
④ リモートリポジトリにプッシュ（git push） ← これをしないと共有されません
　　自分のコードを保存する「クラウド上の倉庫」の共有リポジトリに保存する

会社の案件での実際のGit運用の流れ（基本的なチーム開発の形）

① スタート：新しいプロジェクトに参加したとき

あなたがやる最初の作業：

リモートリポジトリ（GitHubなど）からクローンして、ローカルに作業環境を作る

git clone https://github.com/会社のリポジトリ.git
cd プロジェクト名

📌 つまり、最初にローカルリポジトリを 自分で作るのではなく、会社の公式リポジトリを clone して使う のが基本です。

❓なぜ最初からリモートリポジトリをcloneするのか

本番で動いているソースコードや設定、構成がすでに入っている
チーム全員が同じリポジトリを共有して、そこからブランチを切って作業する
勝手に git init して空のリポジトリを作ることは基本的にしません（例外あり）
main ブランチを直接触ると、何がどう変わったか確認しにくい
ブランチを分けることで「どの機能でどんな修正をしたのか」がはっきりする
差分（git diff）や履歴（git log）が機能単位で整理される

　
たとえば会社のGitHubには、以下のようなURLがあります：

https://github.com/example-company/hr-system.git

これが「リモートリポジトリ（会社のリポジトリ）」です。
このURLを使ってクローン（コピー）します。
下記を実行するとclone完了です。

git clone https://github.com/example-company/hr-system.git

すると、あなたのPCに
「hr-system」というプロジェクト一式がダウンロードされて、
開発を始められるようになります。

💡他の人がリモートリポジトリを更新した場合の対応

他の人がリモートリポジトリを更新した場合、自分のローカルリポジトリは古い状態のmainとなるので、mainを最新版に修正する必要があります。
その時の処理が下記内容となります：「リモートmain（GitHub）」から最新を取り込む、という意味です
この内容に関しては⑦補足でも説明しております。

git pull origin main

② cloneした後の作業：ローカルブランチを切る

あなたの役割が「新しいボタンを追加してほしい」という作業だとします。

git checkout -b feature/add-button

✅ これが「ブランチを切る」ということです！

main や develop ブランチから分岐して、
あなたの作業専用のブランチを作成する

ブランチとは
「同じソースコードを元に、別の作業用の道を作ること」
＝mainブランチ（本線・完成したコード、ローカルとリモートの二つのmainが存在することになります）
＝featureブランチ（あなたの作業中の支線）

現在の自分のブランチ確認コマンド：

git branch

結果の例：

* feature/add-button
  main

この「*（アスタリスク）」がついているブランチが「今あなたが作業中のブランチ」です。
この例では、feature/add-button ブランチで作業中という意味になります。

ローカルからリモートブランチ一覧を見るコマンド：

git fetch origin　　　←リモートの変更を「取得」する（※ローカルブランチには反映しない）
git branch -r　　　　←リモートのブランチ状況を確認する

ブランチの管理について：

Git Flowに基づく運用方法が下記内容となり、基本的にこの運用方法を使用するのが一般的とのことです

ブランチ名	役割
`main`	本番（リリース）用ブランチ。常に安定した状態
`develop`	開発のベースブランチ。新しい機能はここから作られる
`feature/〇〇`	新機能の開発用。`develop` から作る
`release/〇〇`	リリース準備ブランチ。最終調整・バグ修正など
`hotfix/〇〇`	本番の緊急修正用。`main` から作成して、`main` と `develop` にマージする

③ 作業開始

ブランチ切った状態で作業をして、その作業内容を履歴としてローカルに保存する。
addで「変更したファイルをコミットの対象にする」で .（ドット） は「カレントディレクトリ（＝今いるフォルダ）以下すべて」という意味

ファイルを編集
差分を git diff や git status で確認
動作確認もローカルの開発環境で行う（Salesforceの場合はSFDXなどを使う）

コミットする：

git add .
git commit -m "ログ用のメッセージ"

　
修正していく中で修正内容が全てコミットされているか確認する必要がある。その際に下記コマンドで確認できる。もしコミットされていない部分があれば、コミットするかどうか聞かれるので必要に応じてコミットする。

git status

　
cmdでの作業で
・ファイル内の物を一覧で確認したい時は「dir」
・ファイルを削除したい時は「del ファイル名」
・特定のファイルの中身を確認したい時は「type ファイル名」
　※ファイル中身確認の時に文字化けする場合は文字コードの違いによるもので、cmdはデフォがShift-JISとなっていてファイルはUTF-8になっていることが多いです。なので確認したい時は下記コマンドで文字コードを変更する

chcp 65001
type ファイル名

・上記の記述で文字コードを UTF-8 に切り替えることが出来ます。が完全対応では無いのでこれでも表示が難しいならVSCodeで開く等の切り替えが必要になります。

④ 作業をGitHubに共有（push）

当たり前ですが、プッシュするにはプッシュ先のリモートリポジトリが必要です。
コミットしていないとプッシュは出来ません。

案件参画では自分でリモートリポジトリを作成するという事は基本的には無いと思いますが、今回は練習なのでまだリモートリポジトリが無い状態です。なので作成手順としてはGitHubにリモートリポジトリを作成する→作成したリポジトリのURLをローカルへ紐づける→プッシュ実行って感じです。作成後にプッシュします。

　
プッシュ操作コマンドが下記になります

git push -u origin feature/ブランチ名

これで、あなたの作業ブランチがリモート（GitHub）にアップされる
チームメンバーや上司が見られるようになる
あくまで作業履歴をリモートリポジトリに送る処理です

※originは基本はoriginという記述固定で、初めて git clone したときに、自動的にリモートに origin という名前が付きます。もし origin ではなく、たとえば upstream や my-remote など他の名前が付いていたら、その名前を使う必要があります。
「-u」この記述は追跡設定です。二回目以降のプッシュをリモート名とブランチ名を省いて記述できます。

下記記述でリモート名を変更できる

git remote rename 現在リモート名 変更したいリモート名

⑤ レビュー依頼（Pull Request）

GitHub上で Pull Request（PR） を作成
main や develop との変更点（差分）が表示される
上司がそれをレビュー・コメントしてくれる
マージ対象とマージ元のデータ指定を必ず確認する
必要ならレビュアーを指定、ラベルを付けたりIssue番号をリンクしたりと現場による

簡単なPR手順
１，あなたの作業ブランチ（例： feature/〇〇）を GitHub に push しておく
（-u オプションで上流追跡設定しておくと便利）
２，GitHub のリポジトリページへ行く
３，ブランチ切り替えドロップダウン（通常は “Branch: …” ボタン）から自分の作業ブランチを選ぶ
４，「Compare & pull request」や「Pull request を作成」ボタンをクリック
５，ベースブランチ（Merge先、たとえば main や develop）と、比較対象のブランチ（あなたの作業ブランチ）を確認
６，タイトル（PRの名前）と説明（何をどう変えたか）を記入
７，必要ならレビュアーを指定、ラベルを付けたり Issue 番号をリンクしたり
８，「Create pull request」または「Draft pull request」をクリックして作成

⑥ 承認されたらマージ

上司 or 担当者が OK なら main にマージ
あなたの変更が正式にプロジェクトに反映される

⑦ 他の人の変更を取り込む（pull / fetch）

ローカルのmainを最新状態にする為の作業。リモートリポジトリmainからローカルリポジトリのmainに適用させる。

他の人がマージした内容は、自分のローカルには反映されていないため：

git checkout main
git pull origin main

この記述はあくまでリモートmainからローカルmainに更新させるのみ
その他のローカルの作業ブランチは更新されません

⑦補足　他の人がリモートmainを更新した時の対応

リモートの main が更新された場合、修正中のローカルの作業ブランチ（feature/〇〇）にどうやってその最新内容を取り込むのかという問題。下記内容が問題の内容。

リモートの main ブランチが更新された
自分のローカル main にそれを反映したい
自分のローカル作業ブランチ（例：feature/login）にもリモート main の更新を反映したい
かつ、自分が作業ブランチで行っていた修正・変更内容もちゃんと残したい（消えたりしないようにしたい）

この問題の回答としては、mainを更新した後、作業ブランチに取り込む操作が必要になります。「元の作業内容を保ちながら、他の変更を取り込む」ための手段です。
方法は二通りあります。

方法⓵　マージする（git merge）

# 最新のmainを取得（ローカルmainを更新）
git checkout main　　　　　←ローカルのmainブランチに切り替え
git pull origin main　　　　←リモートのmainをローカルのmainに取り込み

# 作業ブランチに戻る
git checkout feature/login　←作業ブランチに切り替え
git merge main　　　　　　　　←mainブランチの内容を今のブランチに取り込む（統合する）

🔹 方法⓵での修正結果：自分の修正内容はそのまま残ります。

main（更新された）: A---B---C
                         \
作業ブランチ：           D---E---M（← マージコミット）

D と E はあなたの修正内容
C はリモート main の変更
M は Git が自動的に作るマージ結果のコミット

方法②　`rebase` を使う（履歴がきれい）

# 最新のmainを取得
git checkout main
git pull origin main

# 作業ブランチに戻る
git checkout feature/login

# rebaseでmainの下に履歴を載せ替える
git rebase main

🔹 方法②での修正結果：修正内容は残ります。（ただし Git 内部的には「新しく作り直されたコミット」として扱われる）

main（更新された）: A---B---C
                            \
作業ブランチ：               D'---E'（← mainのあとに並び替え）

方法⓵とそこまで変わりませんが、最後のrebaseで違いがあります。
これも 自分の作業内容（D、E）はしっかり残ります

イメージとしては
mergeだと元々の古いバージョンのmainを更新して作業ブランチにも反映させる。履歴は安全重視で多少汚くてもいいならmerge。
rebaseだと元々の古いバージョンのmainはそのままで作業ブランチ側の履歴を変更する。元のブランチの履歴をmainの末尾に「載せ替える」操作となる。履歴をきれいにしたい（PR前など）はrebase。

注意点（補足）

コンフリクト（衝突）が起きた場合は手動で解決が必要です
rebase のあとは、--force をつけて push する必要があることがあります

追跡ブランチについて

ローカルリポジトリ         リモートリポジトリ
main       　　　  →          　main     
↑                           　   ↑     
feature    　　　  →      　   feature

これは、以下のような関係を示しています：

ローカルブランチ	対応するリモートブランチ（追跡先）
`main`	`origin/main`
`feature`	`origin/feature`

ローカルの main ブランチは、リモートの origin/main を追跡していて、
ローカルの feature ブランチは、リモートの origin/feature を追跡している。

追跡ブランチ（tracking branch）とは？

Git では、ローカルブランチを作成するときに、リモートブランチを追跡する設定を自動または手動で行います。

例えば：

git checkout -b feature origin/feature

→ feature ブランチは origin/feature を追跡します。

または：

git push -u origin feature

→ feature をリモートに初めて push すると、自動で追跡設定されます（-u は --set-upstream の略）。

🔍 ブランチ追跡先を確認するには？

git branch -vv

このコマンドで、各ローカルブランチがどのリモートブランチを追跡しているかが表示されます。

🧠 エラーが出るときの基本チェックリスト

確認項目	コマンド	内容
今いるブランチ	`git branch`	現在のブランチ名に push しようとしているか？
コミットがあるか	`git log` / `git status`	まだコミットしていないなら push はできません
スペルミスしていないか	手打ちの文字列	`origin` や `feature/xxx` にミスがないか？

📌 まとめ：実際の案件でのGit運用フロー

手順	実際にやること	コマンド例
① リモートからリポジトリをクローン	GitHubやGitLabからコピー	`git clone https://github.com/company/project.git`
② クローンしたフォルダに移動	ローカルで作業	`cd project`
③ ブランチを切る	作業用ブランチ作成	`git checkout -b feature/add-login`
④ 編集 → コミット	コードを書く・コミット	`git add .` → `git commit -m "ログイン機能追加"`
⑤ リモートに push	プッシュして共有	`git push -u origin feature/add-login`
⑥ プルリク（マージ依頼）を出す	GitHub上で操作	ブラウザで Pull Request 作成

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up