【ITニュース解説】Developing Two Features at Once with Git Branches. (merge)
2025年09月27日に「Dev.to」が公開したITニュース「Developing Two Features at Once with Git Branches. (merge)」について初心者にもわかりやすく解説しています。
ITニュース概要
Gitブランチを活用し、2つの新機能を同時開発した経験を紹介する。専用ブランチで安全に実装・テストを進め、作業ディレクトリが単一であることや`git log`の重要性を学んだ。最終的にメインブランチへのマージでコンフリクトも解決し、Gitの理解を深めた。
ITニュース解説
今回の記事では、Gitのブランチ機能を使って二つの新機能を同時に、しかも互いに影響を与えずに開発した経験が語られている。システム開発において、複数の機能を並行して進めることはよくあるが、そのような場合にGitのブランチは非常に強力なツールとなる。ブランチとは、プロジェクトのコードの流れから一時的に分岐し、独立した作業空間を作り出す機能のことである。これにより、特定の機能の開発やバグ修正を、メインのコードベースに影響を与えることなく進められる。
著者は自身の「Repo-Code-Packager」というツールに二つの機能を追加した。一つはファイル内容に行番号を表示する--line-numbers機能、もう一つはディレクトリ構造だけを表示し、ファイル内容は表示しない--dirs-only機能である。
まず、--line-numbers機能の開発について述べる。この機能は、ユーザーが-lまたは--line-numbersフラグを指定すると、ファイルの内容の左側に行番号を追加するものである。開発の第一歩として、GitHub上に「issue-7」という課題を作成し、作業を明確化した。これは、開発すべきタスクを効率的に追跡するための良い習慣だ。次に、mainブランチから「issue-7」という専用ブランチを作成し、この新しいブランチ内でコードの追加とテストを行った。このようにメインブランチから独立したブランチで作業することで、メインブランチを壊す心配なく、安心して新しい機能の変更やテストに集中できた。具体的な実装としては、argparseライブラリを使って-lフラグを認識させ、format_file_contents関数を修正してファイル内容を行ごとに分割し、それぞれに行番号を追加する処理を実装した。この機能の開発は比較的スムーズに進んだようだ。
次に、--dirs-only機能の開発に移る。この機能は、-dフラグが指定された場合に、すべてのコード内容を取り除き、ディレクトリ構造のみを表示するもので、プロジェクト全体の構造を素早く把握するのに役立つ。この機能についても、まず「issue-8」というGitHub課題を作成し、作業内容を明確にした。そして、この機能のための専用ブランチ「issue-8」をmainブランチから作成し、その中で開発とテストを行った。この機能はメインの関数のロジック変更を伴うため、厳密なテストが必要だった。そのため、メインブランチから分離された環境で作業できたことが、安心してコードを改善する上で大きな利点となった。実装においては、出力方法の変更が主な点だった。以前は一つの大きな文字列で結果を生成していたが、-dオプションの有無によって出力内容が変わるため、冗長なコードになる可能性があった。そこで、出力する各要素(ヘッダー、Git情報など)をoutput_partsというリストに格納し、ユーザーのリクエストに応じて動的にリストの内容を変更し、最終的に結合して出力する効率的な方法を採用した。
著者は開発中に一つ大きな混乱を経験したという。新しいブランチを作成し、git checkoutコマンドを使ってブランチを切り替えても、main.pyファイルの内容が全く変わらないように見えたのだ。main、issue-7、issue-8のどのブランチにいても、コードはすべて同じに見え、一時的にパニックに陥ったという。この経験から得られた重要な教訓は、「作業ディレクトリは単一である」ということだ。Gitを使用しているプロジェクトフォルダは、一度に一つのブランチの内容しか表示できない。git checkoutコマンドは、切り替えたブランチの状態に合わせて作業ディレクトリのファイルを瞬時に変更する。しかし、この時には実際にはどのブランチでも変更をコミットしていなかったため、どのブランチをチェックアウトしても作業ディレクトリの状態に変化がなかったのだ。git logコマンドは、このような状況で非常に役立つ。これはリポジトリ全体の変更履歴を地図のように表示し、各ブランチがどのコミットを指しているか、どのような変更が加えられたかを明らかにする。著者はgit logを使うことで、自身が実際に変更を正しくコミットしていなかったため、すべてのブランチが同じ場所を指している状態だったことを理解した。この経験から、いったんすべてのブランチをクリーンアップし、再度変更を適用し直すことになったが、非常に価値のある学びとなった。
混乱を乗り越え、二つの異なる機能を持つブランチがそれぞれ独立した状態で完成した後、いよいよそれらをmainブランチに統合する段階に入った。この統合にはgit merge [ブランチ名]コマンドを使用する。まず「issue-7」ブランチをmainにマージしようとした際、コンフリクト(衝突)が発生した。これは、著者が「issue-7」ブランチを作成した後、誤ってmainブランチにも変更を加えてしまっていたためである。Gitは、同じファイルの同じ箇所が複数のブランチで異なる変更をされた場合に、自動的にどちらの変更を採用すべきか判断できないため、コンフリクトを報告し、手動での解決を促す。著者は、このコンフリクトを解決する必要があったが、幸いにもコードを再配置するだけで、難しい問題ではなかったと述べている。このコンフリクトを解決し、「issue-7」ブランチをmainにマージした後、「issue-8」ブランチも同様にmainブランチへとマージされた。こうして、二つの新機能が無事にメインのプロジェクトに組み込まれたのである。毎週新しい技術を学ぶ中で、このような実践的な経験は、システムエンジニアを目指す上で非常に興味深く、かつ重要なステップとなる。