当社では、システム開発におけるソースコードの管理に、GitHubやGitLabを活用しています。
複数のメンバーで同じシステムを開発する場合、それぞれの変更内容を適切に管理し、安全にプログラムへ反映することが重要です。
今回は、機能開発からコードレビュー、不具合修正まで、チーム開発における基本的な流れをご紹介します。
Git・GitHub・GitLabの役割
Gitは、ソースコードの変更履歴を管理するための仕組みです。
Gitを使用することで、誰が、いつ、どのファイルを変更したのかを記録できます。また、問題が発生した場合には、過去の状態を確認したり、変更前の状態へ戻したりすることも可能です。
GitHubやGitLabは、Gitで管理しているソースコードをチーム内で共有するためのサービスです。
ソースコードの保存だけでなく、次のような用途にも利用できます。
- 開発課題や不具合の管理
- ブランチの管理
- Pull RequestやMerge Requestの作成
- ソースコードのレビュー
- 開発状況の共有
- 変更履歴の確認
GitHubでは一般的に「Pull Request」、GitLabでは「Merge Request」という名称が使用されていますが、変更内容を確認してからブランチへ反映するという基本的な役割は同じです。
作業内容ごとにブランチを作成
新しい機能の開発や不具合の修正を行う場合は、作業内容ごとに専用のブランチを作成します。
例えば、新しいお問い合わせ機能を開発する場合は、次のような名前を付けます。
feature/contact-form画面表示の不具合を修正する場合は、次のような名前にします。
feature/contact-formブランチを分けることで、開発途中のソースコードが他のメンバーの作業に影響することを防げます。
当社では、ブランチ名を見るだけで作業内容が分かるように、一定の命名ルールを設けています。
例えば、次のように使い分けます。
feature/：新しい機能の開発fix/：通常の不具合修正hotfix/：緊急性の高い不具合修正refactor/：機能を変えずにコードを改善docs/：ドキュメントの更新
ルールを統一することで、現在どのような作業が行われているのかを、チーム内で把握しやすくなります。
機能開発の基本的な流れ
新しい機能を開発する場合は、最初に課題や仕様を確認します。
その後、開発用ブランチを作成し、実装と動作確認を行います。
基本的な流れは次のとおりです。
要件・課題の確認
↓
開発用ブランチの作成
↓
プログラムの実装
↓
担当者による動作確認
↓
Pull Requestの作成
↓
コードレビュー
↓
開発環境へ反映実装前に、対象となる画面や機能、影響範囲、確認方法などを整理しておくことで、認識のずれを防ぎやすくなります。
また、変更内容が大きくなりすぎないように、可能な範囲で作業を小さく分けて進めています。
一度のPull Requestに多くの変更が含まれていると、レビューに時間がかかり、問題を見落としやすくなるためです。
Pull Requestで変更内容を共有
開発や修正が完了したら、Pull Requestを作成します。
Pull Requestには、変更したソースコードだけでなく、作業内容や確認方法も記載します。
主に次のような内容を記載します。
- 対応した課題
- 追加・修正した機能
- 変更した画面
- 動作確認の方法
- 確認してほしいポイント
- 関連するIssueや課題番号
- 画面変更がある場合のスクリーンショット
変更内容を文章で残しておくことで、レビュー担当者が内容を理解しやすくなります。
また、後から履歴を確認する際にも、なぜその変更を行ったのかを把握できます。
コードレビューで確認すること
Pull Requestを作成した後は、他のメンバーがコードレビューを行います。
コードレビューでは、単にプログラムが動くかどうかだけではなく、さまざまな観点から確認します。
例えば、次のような内容です。
- 要件どおりに実装されているか
- 他の機能に影響がないか
- エラー処理が適切に行われているか
- コードが分かりやすく書かれているか
- 同じような処理が重複していないか
- セキュリティ上の問題がないか
- テスト内容が十分であるか
修正が必要な場合は、Pull Request上でコメントを付け、担当者が追加修正を行います。
すべての確認が完了した後、対象のブランチへマージします。
コードレビューを行うことで、一人では気付けなかった問題を早い段階で発見できます。また、チーム内で実装方法や知識を共有する機会にもなります。
不具合修正の進め方
システムに不具合が見つかった場合は、最初に発生条件や影響範囲を確認します。
不具合の内容は、GitHubやGitLabのIssue、または社内で使用している課題管理ツールに記録します。
不具合を登録する際は、次のような情報を整理します。
- 不具合が発生した画面
- 発生した日時や環境
- 操作手順
- 本来の想定結果
- 実際に発生した結果
- エラーメッセージ
- 再現できるかどうか
- 影響を受ける機能
内容を整理した後、不具合修正用のブランチを作成します。
不具合の確認
↓
発生条件・原因の調査
↓
修正用ブランチの作成
↓
プログラムの修正
↓
修正箇所と関連機能のテスト
↓
Pull Request・コードレビュー
↓
修正内容の反映不具合を修正する際は、該当箇所だけでなく、関連する機能に影響がないかも確認します。
特に共通部品や共通処理を変更した場合は、複数の画面に影響する可能性があるため、影響範囲を意識したテストが必要です。
コミットメッセージも分かりやすく
Gitでは、変更内容を保存する単位をコミットと呼びます。
コミットを行う際は、後から見ても変更内容が分かるように、簡潔で具体的なメッセージを付けます。
例えば、次のように記載します。
お問い合わせフォームの入力チェックを追加
スマートフォン表示時のレイアウト崩れを修正
ログイン失敗時のエラーメッセージを変更「修正しました」「更新しました」だけでは、何を変更したのか分かりにくくなります。
変更対象と内容を明確に書くことで、履歴を確認しやすくなり、問題が発生した際の調査にも役立ちます。
チーム内でルールを共有
GitHubやGitLabを導入するだけでは、チーム開発が自動的に円滑になるわけではありません。
ブランチの作成方法、Pull Requestの書き方、レビューの進め方などについて、チーム内でルールを共有することが重要です。
プロジェクトによって開発方法や規模は異なるため、すべての案件で同じルールを使用するのではなく、メンバー数や開発内容に合わせて調整しています。
安全で分かりやすい開発を目指して
GitHubやGitLabを活用することで、ソースコードだけでなく、開発の経緯や判断内容も記録できます。
ブランチ、Pull Request、Issue、コードレビューを適切に利用することで、複数人での開発でも変更内容を管理しやすくなります。
当社では、今後もチーム内で開発ルールや知識を共有しながら、安全で分かりやすく、品質の高いシステム開発に取り組んでまいります。
