gitで初心者がプッシュまでする流れとよくあるエラー対処について書いてみた。
gitって何、gitって何が起きているの状態だと実務で詰む。
個人で使ったことがあっても、実務ではブランチ戦略による違いに戸惑うのでまとめてみた。
Gitって何
バージョン管理ツールのこと。
仮に、ファイルを作成して、更新した日ごとに新しく名前を付けて保存したとする。
イメージはこんな感じ。
2025年4月5日時点の内容を見たい、5月以降の内容は不要になったから4月時点のファイルに付け足したい、といった要望が発生する。
もし、ファイルの更新ごとに上書き保存していたら、4月時点と言われてもどこを追加したかわからない。
上図のように、更新のたびに新しく名前をつけて保存していたら回避できるかもしれないが、◯◯の変更をした時のやつなんて言われたらファイル名も意味がない。
この方式は、膨大な量のファイル保存も必要になる。
さらに、他人も参加してファイル名の付け方が違ったり、更新順序がわからなくなったり、担当者が変更になったりしたら最悪だ。
これを解決するのがGit
イメージはこんな感じ。
ファイル本体は１つに対して、「変更の記録」を保持しておくことができる。
ファイルを開くと基本的に最も新しい更新内容が表示されるが、戻そうと思えばある時点のファイル表示に戻すことができる。
他にも
- 更新順序を変更する
- 過去の修正をする
- 変更を取り消す
- 保存前に他の人の変更をみる
- 必要な変更だけ自分の作業に取り入れる
など、履歴に対してさまざまな操作ができる。
GitとGitHub
GitとGitHubという名前があるが、これは別物。
Gitは自分の手元のパソコンでバージョン管理をするツールであり、
GitHubはチームのソースコードをweb上（クラウド上）で保管して共有できるサービス。
チームのソースコードはみんなで共有できるように、どこかに保管しておかなければいけない。
保管場所として大体がGitHubを使用している。
GitHubにあるソースコードを手元のパソコンにコピーして修正し、修正した変更の記録はGitHubに残してチームのメンバーが見られるようにする。
このGitHubの役割がリモートリポジトリであり、大体がGitHubなのでこの記事ではリモートリポジトリ＝GitHubとして扱う
ちなみに、リポジトリとは保管庫という意味らしい。
最初に理解するGitコマンド
まず、コード変更から記録するまでの基本のGitの流れ
チームのソースコードを自分のパソコンに持ってくる（初回のみ）
↓
ブランチを切る
↓
コードを書く
↓
変更を記録する
↓
変更をチームのソースコードにも記録する
git clone
チームのソースコードが置いてあるリモートリポジトリから自分のパソコンにソースコードをコピーする
ターミナルを開き、フォルダを作成したい場所で以下のコマンドを実行する
% git clone <リモートリポジトリのURL>
<リモートリポジトリのURL>はGitHubのリポジトリに入るとCodeボタンからコピーできる。
HTTPSかSSHを使うかはチームで確認が必要。
cloneでコピーされるのはソースコードと変更の記録。
git branch / git switch
作業をするには作業用のブランチを作る必要がある。
ブランチは枝や枝分かれのことで、なぜ作るかというとmainというブランチは本番用や確定したソースコードを置いておくブランチとして使用されていることが多いからだ。
ブランチの運用はチームによって異なる。
複数の運用パターンがあるが、ここではGitHub flowのようなmainからfeature/firstというbranchを作成することとする。
作成する前に、自分がどこのブランチにいるか確認する
% git branch
// 表示結果
* main
結果は現在あるブランチ名が表示され、＊マークがついているブランチが現在地である（上記の場合はmainブランチが現在地）
ブランチ作成元のブランチへ移動する
% git switch main
mainブランチが現在地であることを確認したら以下のコマンドで作業用のブランチを作成し、移動する
// ブランチを作成する
% git branch feature/first // feature/firstのところはブランチ名
// ブランチを移動する
% git switch feature/first
// ブランチ作成と移動を一度に行う場合（上記のコマンドをまとめて実行する場合）
% git switch -c feature/first
※<ブランチ名>はチームルールに従った名前をつける
git add
変更を記録する前にステージングエリアへ追加する。
ステージングエリアは記録を残す準備段階と考えておいて良い。
// 全ての変更をステージングエリアに追加する
% git add .
// 特定の変更ファイルだけをステージングエリアに追加する場合
% git add <ファイル名>
慣れないうちはコミットする単位でステージングに追加してコミットした方が良い。
git commit
変更を記録する
% git commit
上記はステージングエリアに追加したファイルを全てコミット（記録）する。
実施すると、コミットメッセージ追加のため、vimが開く。
キーボードの「i」を押して入力モードに変更し、メッセージを入力後、escキー→:wqで保存する
※コミットメッセージの書き方はチームルールがある場合はそれに準ずる
% git commit -m "コミットメッセージ"
git commitの後に-mでコミットメッセージをつければ、コミットメッセージをつけてコミットできる。
この場合はvimでの編集は不要になる。
% git commit -- <ファイル名>
上記でファイル指定してコミットもできる。
※-m "コミットメッセージ"をつける場合はcommitの後に書く。
git merge
mainブランチでプッシュする場合は、feature/firstブランチをmainブランチに統合してからプッシュをする。
イメージとしては以下
(◯がコミットで、main1やfeature/first1というのは違うコミットであるのがわかるよう数字を振ってます)
mergeしたよというコミットが作成されるのでここでブランチを統合したというのがはっきりとわかる
mainにfeature/firstを統合する場合はまずmain(統合される方)へブランチを変更する
// mainに移動
% git switch main
// 統合される方のブランチ(main)で統合するブランチ(feature/first)を指定
% git merge feature/first
これでマージ(統合)されるので現在地がmainでもfeature/firstの変更を取り入れたファイルが見られる。
git rebase
マージ同様に統合する手段の１つ。
イメージは以下
履歴がきれいな一直線になる一方で、後からfeature/first消したい！となったときに分かりにくい。
// mainの後にfeature/firstの記録を追加する
% git switch feature/first
% git rebase main
// mainに反映する
% git switch main
% git merge feature/first
mainを基準にfeature/firstをmain上に付け替えるイメージ
git push
mainに統合したらローカルの変更をリモートのmainにコピーする
% git push origin main
これでリモートのmainに変更がコピーされる。
feature/firstをプッシュして、リモートのorigin/feature/firstとして反映させたい場合は、リモート追跡ブランチの作成が必要。
% git push --set-upstream origin feature/first // リモート追跡ブランチorigin/feature/firstが作成される
--set-upstreamをつけてプッシュする。
(おまけ)git status
git statusコマンドを実行すると、現在のコミット状況を見ることができる。
よくある失敗と対処
git add忘れ
git addでステージングエリアに変更を上げ忘れてgit commitするとメッセージが出る
On branch feature/first
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: practice.txt
no changes added to commit (use "git add" and/or "git commit -a")
【解決方法】
git addする
リモートの変更が取り入れてなくてpushできない
git push時に、リモートの最新の変更をローカルに取り入れてないためエラーが出る
作業用ブランチを切った後、チームの誰かがmainを更新していて、その変更を取り込まずにpushした時
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the remote contains work that you do
not have locally.
【解決方法】
git pullで変更を取り入れる
// リモートの変更を自分のローカルブランチにマージする
// main->mainへのプッシュ時
% git pull
// pullされたら
$ git push origin main
pullするとマージコミット（リモートmainの変更を取り入れたよ！）が作成される。
pullでコンフリクトのエラーが出た場合↓↓
コンフリクト（衝突）
mergeやpullなど現在の作業ブランチにない変更を他から持ってきた時に発生する
同じファイルの同じ箇所などに変更があると、gitがどちらを優先するか判断できず、食い違ってる部分を修正してというエラーを出す。
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
【解決方法】
コンフリクトを解消して再度merge(またはpullなど)をする。
コンフリクトしているファイルには
<<<<<<< HEAD
このプロジェクトはチームで管理しています。
=======
このリポジトリは個人用に作成されました。
>>>>>>> feature
このような表示が出る。
mainブランチにfeatureブランチをmergeした場合は、上部がmain、下部がfeatureの内容。
どちらに合わせるか手動で修正、修正したら再度mergeをする。
未保存のままブランチ変更でエラー
作業ブランチでの変更を未コミットのままブランチを切り替えようとしたときらエラー
error: Your local changes to the following files would be overwritten by checkout:
practice.txt
Please commit your changes or stash them before you switch branches.
Aborting
【解決方法】
➀変更をコミットしてからブランチを切り替える
% git commit -am "コミットメッセージ"
% git switch <変更先ブランチ名>
➁git stashで変更途中のままブランチを切り替える
stashとは隠すという意味で変更を一旦避けておくことができる。
// 変更を全てstashする
% git stash
// stashにコメントをつけておく
% git stash push -m "ブランチ切り替えのため"
// stashしたらブランチを切り替える
% git switch <変更先ブランチ名>
作業していたブランチに戻った時にstashを戻すのを忘れずに行う。
// stashした内容を確認
% git stash list
// stashを戻す
% git stash pop // stashした全てが戻る
間違えてコミット
間違えたファイルを含めてしまった！などコミットを取り消したいとき
【解決方法】
①git revertで「コミット削除したよ」というコミットを作る
削除も履歴のうちなので、コミットを消すというよりコミットをなかったことにするというコミット。
「あいうえお」って追加して「あいうえお」って追加する感じ。
// 最も直前（最新）のコミットの場合
% git revert HEAD
// いくつか前のコミットの場合
// コミットログを確認して打ち消すコミットを探す
% git log
// 打ち消すコミットのcommitの後に続く数字とアルファベットの文字列（コミットID）を確認
% git revert <コミットID>
②git resetでコミットを消す
コミット自体をなかったことにする。
ローカル上では使用できるが、すでにプッシュしたコミットには不適。
// 最も直前（最新）のコミットの場合
// コミットを取り消してステージングエリアに戻す
% git reset --soft HEAD^
// コミットを変更ごと全て破棄
% git reser --hard HEAD^
// いくつか前のコミットの場合
// コミットログを確認して打ち消すコミットを探す
% git log
// 打ち消すコミットのcommitの後に続く数字とアルファベットの文字列（コミットID）を確認
% git reset <コミットID>
間違えてプッシュ
プッシュしちゃった！というとき
【解決方法】
git revertで打ち消しコミットを作成してプッシュする
// ローカルのmainからリモートのmainにプッシュした場合はgit branchで現在地も確認
// 直前のコミットのみの場合
% git revert HEAD
% git push origin main
// 複数コミットを一緒にプッシュした場合
% git revert HEAD~3 // 現在地から戻すコミットの数を入れる
% git push origin main
コミット打ち消しのコミットが出来上がるので、消したことは履歴に残る。
完全に消しても問題ないかはブランチ状況とチームでのルールによるため、事前に確認する。
まとめ
もっと多くのコマンドやオプションがあるが、ひとまず初心者が最低限知っていれば対応できそうな内容で書いてみた。
私もまだまだ勉強中です。