Git Pullエラーの対応方法

Gitの操作に慣れてないので自分用にまとめました。

コミット → ローカル(自分のPC)に履歴を保存
プッシュ → リモート(GitHubなど)に履歴を送信
プル→リモートから変更を自分のローカルに取り込む

  1. コミットとプッシュはセットで行う。
  2. プッシュ前にプルする癖をつけるとコンフリクトが減る。
  3. 自分のローカルに未コミットの変更がある場合は、プルを実行する前に変更をコミットしておく。
  4. 修正だけしてコミットしてないと、プルしたときにコンフリクトが起きやすくなる。

コンフリクトとは、ローカルでの変更とリモート(GitHub)で、異なる変更が同じファイルに加えられている場合のエラー。

統合方法

Git操作がVS Code内でエラーになる場合、以下の方法で統合方法を指定できる。

VS Code内でターミナルを開く

  • Windowsの場合: Ctrl + “(バッククォート)でターミナルを開く。
  • Macの場合: Command + “

git statusでGitのリポジトリの現在の状態を確認

ローカルの変更をステージして、コミット

git add .
git commit -m "ローカル変更の保存"

これで、作業中の変更がローカルリポジトリに保存される。

統合方法を選択して設定(次回以降はこのコマンドを実行する必要はない)

マージ方式をデフォルトにする
git config pull.rebase false

リベース方式をデフォルトにする
git config pull.rebase true

マージを使用するのが一般的。

設定後、git pullを再実行。リモートの変更がローカルにマージされる。
ローカルの変更が先にコミットされているから、コンフリクトがなければスムーズに統合される。

マージとリベースの違い

マージ(Merge)

履歴をそのまま残して、シンプルに統合したい場合。
ローカルとリモートの履歴がブランチ上にそのまま残り、過去のコミット情報がすべて確認できる。

リベース(Rebase)

枝分かれした履歴を、別の履歴の後ろにくっつけ直す。
リベースは、履歴をきれいにまとめたいときに使う。
→ 1人で完結する作業ならリベースOKだが、履歴が書き換わるから、ミスすると元に戻せなくなる可能性がある。
→リモートにプッシュ後のリベースは、他の人の作業に影響を与える可能性があるから基本的に避ける。

A—B—C ← main(メインブランチ)
  \
   D—E ← feature(機能開発ブランチ)

ブランチを分けて同じファイルAをそれぞれ別々に編集すると、それぞれの変更内容が独立して進む。
例えば、mainブランチでファイルAにコメントを追加し、一方でfeatureブランチではファイルAに新しい関数を追加する。
この場合、featureブランチをmainブランチに統合(マージ)するときに、どちらの変更をどう統合するかを決める必要がある。

リベースのメリットと注意点

  1. ローカルの変更を一時的に取り外す
    現在のブランチで行った変更(コミット)を一時的に保留
  2. リモートの履歴をローカルに取り込む
    リモートブランチの履歴をブランチの先頭に移動
  3. 保留中の変更をリモート履歴の後に適用
    変更(コミット)がリモートの最新履歴の後ろに追加される

リベースを使って変更を取り込むと、リモートに変更をプッシュした際に、他のメンバーのリモート履歴と自分のローカル履歴が一致しなくなる可能性がある。
リベースは「履歴を書き換える」操作であり、コミットID(ハッシュ値)が変わる。
GitはIDをもとに履歴を管理しているため、同じ内容でもIDが別物として扱われる。

例えば、他のメンバーがすでに D と E のコミットを取り込んで作業していた場合、リベース後にプッシュすると、「同じ変更内容が別IDで存在する」状態になり、重複したコミットができてしまう

最悪の場合、他の人の作業が消えることもあるので、共有されているブランチでリベースを使う場合には慎重に行う必要がある。

コメントを残す

CAPTCHA


このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください