はじめに

はじめまして。

私は開発未経験でエンジニアになりました。入社から4か月弱が経過しますが、毎日学ぶことがたくさんで驚いています。

なんでエンジニアになったかという話もしたいですが、今回はGitでブランチをきったときに気をつけておいたほうがよいことについて書きます。
※Gitとは…簡単にいうとファイルの変更履歴を記録・管理するバージョン管理ツール

開発経験者なら基本かも知れませんが、開発は本来のソースコードを修正して問題が起きないように、複製のようなものを作ってそこで編集します。その後レビュアーに確認してもらい、問題がなければ本来のソースコードに反映するという仕組みで行います。（私も最初は知りませんでした）

そこで使用するのがGitです。

【Gitの手順（コマンド）】

①　mainに戻る (git checkout main)
②　pullする (git pull)
③　新しいブランチをきる (git checkout -b ブランチ名)
④　作業
⑤　addする (git add .)
⑥　commitする (git commit -m "コミットメッセージ")
⑦　pushする (git push)
⑧　プルリクエスト（以下、PR）→マージ後に削除
⑨　メインに戻る (git checkout main)

実際の失敗談

ここからが本題です。
私は最近、ブランチをきって、他の人（同期）のソースコードに追記する機会がありました。それはうまくマージできたのですが、その際にきったブランチを残したまま、VS Code上で自分のソースコードを編集してしまいました。（その時の私は、ブランチの概念もわかっていなかったため、ブランチを意識してソースコードを編集していませんでした。）

編集が終了し、PRを送るためにGitを操作していたらエラーが起きました。（他の人に影響させていないかなと動揺しました。）
ただ同期にいろいろ手伝ってもらって無事解決しました。（本当に感謝してます）

その際に、同期に「一度マージしたブランチは消すのが一般的だよ」「mainからpullして」とアドバイスをもらいました。
私はその時にGitの勉強をもっとしないと、現場で意図しない差分を作ってしまうと思い色々勉強して今では少しは成長したと自負しております。

それと同時になぜマージ後にブランチを削除するのが一般的なんだろうと考えました。
以下にその理由を掲載します。

1．コンフリクトが発生しやすくなる

自分のPRがマージされた後も、他のメンバーはどんどんmainにマージします。その中で古いブランチを使い続けると、他の人の変更が反映されていない古い状態でコードを書くことになります。その結果、2回目のPRを出したときにコンフリクトが発生します。

2．PRの差分が見づらくなる

1回目のマージ後、そのブランチに新しい変更をコミットして2回目のPRを作ると、レビュアーの画面にマージ済みの古い変更まで出てくる場合があります。

マージしたブランチの削除方法

git branch -d ブランチ名**

おわりに

このような問題をなくすために、作業用ブランチはマージ後に削除するのが一般的だと学びました。
この経験から開発現場ではあらゆることが仕組化され、それらを理解するにはGitのようなツールの使い方を知っているだけではなく、根本的な構造を理解しておく必要があると思います。
私もブランチを消すのを忘れないように気をつけていきます。