・Gitコマンドに慣れるのは凄く大事です （2回目）
前回（【Git操作編①】）の続きです。
ここでは git merge, pull といった、チームメンバと切磋琢磨してプロジェクトを推進していく為に必須のコマンドについて説明していきます。
前回記事でも話しましたが、自分は小規模スクリプトの作成を任されることが多く 個人開発 ⇔ 上司のレビュー・フィードバック という流れが多いです。基本1on1です。
そのため、上記コマンドを あまり使い慣れていません。
かといって逃げてはいけないので、自分の勉強の為に記事を書きます。
皆さんのご指導、ご鞭撻のほどお待ちしております。
・リモートリポジトリの全データをコピーして、新しいローカルリポジトリを作成する（clone）
まずは、リモートリポジトリの履歴やブランチをローカルリポジトリに コピー します。
チームメンバみんなで共有している作業場が、今「どういう状況なのか」はここで分かります。
プロジェクトが焼け野原でないことを祈りつつ 以下のコマンドを使用します。
| コマンド | 説明 |
|---|---|
| git clone [リポジトリURL] | 指定したURLのリモートリポジトリの全履歴やブランチも含めてローカルリポジトリにコピーする |
| git clone -b [ブランチ名] [リポジトリURL] | 特定のブランチのみコピーする |
基本的に1プロジェクトに1回使うコマンドなのかな？
指定するURLは「http://~~~.git」みたいな感じです。
以下は一例です。
git clone http://hogehoge12345.git
git clone で取得した後は、次回以降は git pull を使って更新を反映していきます。
・リモートリポジトリの最新の変更を自分のローカルリポジトリに反映する（pull）
既にgit cloneしたリポジトリに対して使います。
その「リモートリポジトリ」の最新状況を「ローカルリポジトリ（自分の作業場）」に反映させます。
| コマンド | 説明 |
|---|---|
| git pull [repositry] [branch name] | リモートリポジトリのブランチ（[branch name]）の最新の変更を取得し、自分のローカルリポジトリ（[repositry]）に反映する |
今回は「Project_0213」の変更内容を反映させます。
基本、ローカルでもルートリポジトリ名は「origin」と思います。
なので今回の場合、
git pull origin Project_0213
（※ originは省略可能です。）
これで、自分のローカルリポジトリに「チームメンバが実施した追加、変更」をまるっと反映させて、ローカルリポジトリ範囲内なら自分も好きに手が加えられるようになります。
・複数のブランチの変更を一つに統合（merge）する
お試しコード挿入やらバグFixやら機能追加やらで、基本的にブランチは複数作成されていくことと思います。
一旦これでマイルストーン（区切りのいい中間点）かな？とチームメンバと話し合いの上決定できたら 複数のブランチを一つのブランチにガッチャンコします。
| コマンド | 説明 |
|---|---|
| git merge [branch name] | カレントディレクトリに、[branch name]ブランチの変更を統合 |
一旦、統合先のブランチに移動する必要があります。
「Project_0213」をメインのプロジェクトにマージしたいなぁって時にありそうな流れとしては以下です。
git checkout Main_project # 統合先のブランチ（一例：Main_project）に移動
git merge Project_0213 # 統合元（Project_0213ブランチ）の変更を統合
これで「Project_0213」で作成・変更した内容を「Main‗project」に統合させることができました。
・git pullとgit mergeの関係
git pullは、内部的にしれっと以下の2ステップを行っています。
git fetch # リモートリポジトリの最新情報を取得（反映はしない）
git merge # 取得した最新情報を参照に、変更をローカルリポジトリに「統合」
「今のあそこのブランチ（リモートリポジトリ）どうなってんやろ」と思ったときは、必ず git fetch で変更内容を確認しましょう。
以下に、よく使いそうなその他のコマンドをリストに殴り書きます。
前の記事と重複するものもありますが改めて。
| コマンド | 説明 |
|---|---|
| git fetch | リモートの最新情報を取得（反映はしない） |
| git branch | ブランチの一覧を表示 |
| git checkout [branch] | 指定したブランチに移動 |
| git log | コミット履歴を表示 |
| git stash | 一時的に変更を退避 |
| git rebase | 履歴をきれいに整理しながら統合 |
| git remote -v | リモートリポジトリのURLを確認 |
よくあるトラブル（主にコンフリクト）について原因と解決策をGPT先生に聞いたのでメモとして貼っておきます。
すごく簡単な一例として、同じファイルを別々の人が変更を加えて、それを「一つのブランチに統合」しようとしたら怒られます。
例えばVisual Studio Codeを使用している場合、コンフリクトしている箇所が表示されます。
変更があった場合、変更前or後のどちらかハッキリさせる必要があります。
一例として、マージに失敗した後VSCに「HEAD」「Project_0213」で色分けして ここに差分があるよ と怒られた場合、大体の場合は変更前（HEAD）のコードを消して対応することになると思います。
内容が薄い気もしますが以上です。
うーん、 現場でpullして業務したことがないから自分で書いていてしっくりこない。
いずれ複数人でプロジェクトを進めるお仕事が降ってくるかもしれないので、定期的に見返していつでも対応できるようにしておきたいです。
話が脱線しますが、いざそういう場面になっても恐らく高いレベルで対応できないんですよね。
事前学習によってミスの頻度は減らせるかもしれませんが、 実務でのインプット・アウトプットに勝る勉強法はないと個人的に思います。
おわり