はじめに
ブランチはコード管理において、枝のように開発のルートを分岐させ、安全に開発を進めるために使われます。
私自身、インターンに参加する前はGitやGitHubについて知ってはいましたが、コミット→プッシュという単純な操作しか知りませんでした。
この記事では、私がインターンを通して学んだブランチの運用についてご紹介します。
なぜブランチを分けるのか
私がまず初めに学んだのは、mainとdevelopの違いです。それまでは、変更を加えたらmainブランチにプッシュするという運用で行っており、ブランチを分けて開発する経験はありませんでした。
しかし、その運用で開発を進めると、開発のラインが1本しか存在せず、仮にシステムを公開し、変更にバグが含まれていた場合、そのバグもシステムへ反映されてしまうおそれがある、ということを知りました。
そのようなリスクを減らすために、開発では3つのブランチを使いました。
- mainブランチ：本番環境で動作するコードを管理するブランチ
- developブランチ：開発のベースとなるブランチ。featureブランチの変更はここにマージする
- featureブランチ：機能の追加や変更を行うためのブランチ。作業単位ごとに作成する
このようにブランチを分けることで、修正が直接本番環境に影響を与えることを防ぐことができます。実際にはfeatureブランチで作業した内容をGitHubにプッシュし、作成したプルリクエストをメンターの方などにレビューしていただき、完了後にdevelopブランチへマージするという流れで開発を進めていきました。
運用する中でつまづいたポイント
ここからは、私が実際にブランチを分けて開発を行う中で、つまづいたポイントについてご紹介します。
① プルリクエスト作成中に別の作業を始めたいとき
featureブランチで作業を終え、プルリクエストを作成しました。レビューの間に他の作業を始めようと考えましたが、どのブランチから作業すればよいか分からず、変更の整理が難しくなる不安もあり、プルリクエストのレビューが終わるのを待っていました。
その点をメンターの方に相談したところ、レビューの完了を待たずに次の作業を進めてよいとのことでした。ただし、コードの状況を見て、プルリク中のfeatureブランチから切るのか、developから切るのかを判断する必要があるということでした。
新しい作業の内容が、レビュー中のfeatureブランチの変更を前提としている場合はそのブランチから切り、そうでない場合はdevelopブランチから切る、という考え方を学びました。
このことから、プルリクエスト中でも、コードの状況を見ながら適切にブランチを活用すれば、変更内容が混在するリスクを抑え、並行して作業をすることができることを知りました。
② developブランチの変更を取り込む必要があった
次に、featureブランチで作業中、プルリクエストのレビューが完了し、developが更新された場面がありました。そのため、自分のブランチにも最新の変更を取り込む必要がありました。
しかし、変更を加えた状態のブランチに対して、どのようにdevelopの更新を反映させればよいのか分からず、手が止まってしまいました。
このような場合、変更を一度コミットした上で、developブランチをもとにリベースを行うことで、自分の変更を最新のdevelopの先頭に付け替えることができると知りました。（他にもmergeなどの方法はありますが、履歴をきれいに保てる点から、リベースを選択しました）
この経験から、ブランチは単に作業を分離するためだけでなく、他の変更を取り込みながら開発を進めていく必要があることを学びました。
③ コンフリクトが発生して解決に苦戦した
リベース処理を行った際に、同じ箇所のコードが変更されていたため、コンフリクトが発生しました。
コンフリクトが発生したときは、どのコードを残すべきか分からず、誤って削除してコードが動かなくなってしまうのではないかという不安がありました。
このような場合は、変更内容を一つずつ確認し、それぞれのコードがどのような役割を持っているのかを理解したうえで、必要な部分を残すことでコンフリクトを解消しました。
この経験から、コードのそれぞれの役割を理解することや、コンフリクトを防ぐためにもこまめにdevelopブランチの変更を取り込むことが重要だと感じました。
開発する中で学んだ運用のメリット
ブランチ運用には、以下のようなメリットがあると感じました。
まず、mainブランチへ直接変更を加えることを防げる点です。
開発中の変更がそのまま本番環境に反映されるリスクを避けることができるため、安心して開発を進めることができました。
次に、並行して作業を進められる点です。
featureブランチごとに作業を分けることで、他の作業と干渉することなく開発を進めることができました。
また、機能ごとに変更履歴を確認できる点も大きなメリットです。
変更前は正常に動作していたにもかかわらず、変更を加えたことで動かなくなってしまった場合でも、履歴を遡ることで原因を特定しやすくなりました。
これにより、過去のコードを無理に残したり、コメントアウトを多用したりする必要がなくなると感じました。
調べながら理解したこと
ブランチの運用を学ぶ際には、「改訂2版 わかばちゃんと学ぶ Git使い方入門」を参考にしました。実際に開発を進める中で感じたのは、本や記事で用語を理解するだけでなく、ブランチを切る、リベースを行う、コンフリクトを解消するといった実際の作業を経験することでブランチ運用に関する理解が深まるということでした。また、実際に手を動かして経験することで、コード変更に対する不安も軽減されると感じました。
これからコード管理やブランチ運用に取り組もうとしている方は、知識として学ぶだけでなく、実際に開発を通して試してみることをおすすめします。
まとめ
今回のインターンを通して、ブランチを分けて開発することの重要性や、リベースやコンフリクトの解消といった実践的な運用について学ぶことができました。
また、ブランチ運用は単に作業を分けるだけでなく、安全かつ効率的に開発を進めるための仕組みであると実感しました。
今後は、より効率的なブランチ運用についても学び、チーム開発の中で活かしていきたいと思います。