Gitの仕組みと基本概念

Gitを効率的に活用するためには、データが保存される4つの領域を理解することが不可欠です。

• ワークツリー（Working Directory）: ユーザーが実際に作業を行い、ファイルを編集・作成・削除しているディレクトリです。
• ステージングエリア（Index / Staging Area）: コミットする準備が整ったファイルを一時的に保持する領域です。git addコマンドでファイルをここに登録します。
• ローカルリポジトリ（Local Repository）: git commitによってステージングエリアの内容が記録される、自分のPC内にあるデータベースです。
• リモートリポジトリ（Remote Repository）: GitHubやGitLabなどのクラウド上にあるリポジトリで、チームメンバーと共有するための場所です。git pushでここに反映されます。

環境構築と認証設定

SSHとHTTPSの選択

リモートリポジトリとの連携には、主にSSHとHTTPSの2つのプロトコルがあります。

• SSH: セキュリティが高く、一度鍵を登録すればパスワード入力が不要になるため、頻繁なコミットに適しています。
• HTTPS: 設定が簡単ですが、接続のたびに認証情報（2要素認証含む）が必要になる場合があります。

大規模なプロジェクトや継続的な開発では、SSH接続の設定が推奨されます。

SSH鍵の設定

ターミナルを開き、以下のコマンドでSSH鍵ペアを生成します（メールアドレスはご自身のものに置き換えてください）。

ssh-keygen -t ed25519 -C "your_email@example.com"

生成後、公開鍵の内容をコピーし、GitHubやGitLabの設定ページから「SSH Keys」として登録してください。

cat ~/.ssh/id_ed25519.pub

プロジェクトの初期化と依存関係管理

package.jsonとロックファイル

Node.jsプロジェクトにおいて、依存パッケージの管理は極めて重要です。

• package.json: プロジェクトが依存するパッケージ名とそのバージョン範囲（SemVer）を記述したマニフェストファイルです。
• package-lock.json (npm) / yarn.lock (yarn): 実際にインストールされた正確なバージョンと、依存ツリー全体の構造を記録した「スナップショット」です。このファイルがあることで、異なる環境やチームメンバー間で全く同じ構成のnode_modulesを再現できます。

依存パッケージのインストールとトラブルシューティング

プロジェクトをクローンした後は、以下のコマンドで環境を構築します。

# npmの場合
npm install

# yarnの場合
yarn install

インストールに失敗する場合の対処法：

1. キャッシュのクリア: 古いキャッシュが干渉している可能性があります。

   npm cache clean --force
   

2. ロックファイルの削除と再インストール: 依存関係の解決が矛盾している場合、node_modulesとロックファイルを削除して再インストールします。

   rm -rf node_modules package-lock.json
   npm install
   

Gitの基本ワークフロー

ブランチ戦略

チーム開発では、機能ごとにブランチを切り、本流（mainやmaster）へマージする流れが一般的です。

# 新しいブランチを作成して切り替え
git switch -c feature/add-user-auth

# 変更をステージングエリアへ追加
git add .

# コミットを作成
git commit -m "feat: ユーザー認証機能を追加"

# リモートへプッシュ（上游ブランチの設定も同時に行う）
git push -u origin feature/add-user-auth

変更の更新とプル（stashとpull）

作業中にリモートの最新状態を取り込みたいが、手元の未コミット変更を一時的に退避させたい場合はstashを使用します。

# 未追跡ファイルを含めて変更を退避
git stash push -u -m "一時退避中"

# リモートの最新変更を取り込み（rebaseで履歴を綺麗に保つ）
git pull --rebase origin main

# 退避した変更を復元
git stash pop

コミット履歴の管理と修正

履歴の改変（Reset vs Revert）

間違ったコミットを取り消したい場合、状況に応じてコマンドを使い分けます。

• git reset: ローカルの履歴を巻き戻す場合に使用します。すでにプッシュした履歴に対しては、履歴が書き換わるため原則使用禁止です。

  # 直前のコミットを取り消し、変更はステージングエリアに残す
  git reset --soft HEAD~1
  
  # 直前のコミットとステージングを完全に破棄
  git reset --hard HEAD~1
  

• git revert: プッシュ済みのコミットを取り消す場合に使用します。「取り消す」という新しいコミットを作成するため、履歴が残ります。

  git revert <commit-hash>
  

ファイルの変更確認と取り消し

作業中のファイルを元の状態に戻すにはrestoreを使用します。

# ワーキングツリーの変更を破棄
git restore path/to/file.js

# ステージングされた変更をステージング解除
git restore --staged path/to/file.js

エラーハンドリングとGUIツール

マージ競合（Conflict）

複数人で同一ファイルを編集した場合に発生します。git pull --rebaseやマージの最中に競合が起きたら、以下の手順で解決します。

1. 競合しているファイルを開き、衝突箇所（<<<<<<<や>>>>>>>）を手動で修正する。
2. git addで修正済みファイルをステージングする。
3. git rebase --continueまたはgit commitで操作を完了する。

GUIクライアントの活用

コマンドライン操作に不慣れな場合や、視覚的に履歴を確認したい場合はSourceTreeやForkなどのGUIツールが有効です。これらはブランチの切り替え、マージ、diffの確認を直感的に行えますが、裏側ではGitコマンドが実行されているため、エラーメッセージの理解は依然として重要です。