こんにちは。テクマトリックスの長久保です。
【これからのソースコード管理！チーム開発を加速するGitによる効率的な開発環境】というセミナーを2025年7月15日に開催しました。

本ブログではセッション内で回答しきれなかったものも含め、改めて皆様から頂いた質問について回答をさせていただきます。また、質問文につきましては、基本的に誤字・脱字の修正を除き、原文のまま掲載させていただきます。

質問1：GitHubのコミットとブランチについて

はい、関係はあります。詳細については、公式ドキュメントの3.1 Git のブランチ機能 – ブランチとはを参照ください。
コミットはリポジトリのある時点のスナップショットを表す不変のオブジェクトとなります。こちらはハッシュ値などで一意に識別され、内容は永続的に変わりません。一方ブランチは単なるポインタで、コミットの履歴に対してラベルを貼っていくというイメージです。

上記のようにmainブランチでコミットをしていきます。すると「963e5ed」「6f22bfd」のようにハッシュ値が降られているのが分かると思います。いまコミット3まで存在する状態で、mainブランチからfeature-aというブランチを作成します。

上記のように、mainブランチもfeature-aブランチも、同じコミット3の「63b21eb」のハッシュ値を参照していることが分かります。このままfeature-aブランチに対して、新しいコミットとして「コミット4」を作成すると、コミット4にはfeature-aラベルが貼られ、mainブランチのラベルは貼られません。

よくある誤解として、「コミットにはブランチ名が埋め込まれている」「ブランチを消すとコミットが消える」というものがあります。
「コミットにはブランチ名が埋め込まれている」については、コミット自体には親コミット(履歴のため)とコミット内容へのハッシュしか保持しておらず、ブランチ名は保持しません。
「ブランチを消すとコミットが消える」については、どのブランチも参照していないコミットはgit logコマンドで表示されなくなるため消えたように見えてしまいがちですが、情報としては存在します。こういったデータはgit reflogコマンドを用いることでハッシュ値を確認できます。
ただし、このような通常では到達されないコミットについては、ガーベッジコレクトの対象になるため、注意が必要です。詳細については、10.7 Gitの内側 – メンテナンスとデータリカバリを参照ください。

質問2：RedmineとGitHub Issuesの使い分け

プロジェクト管理の粒度と開発リポジトリの結びつきで整理されるとよいかと思います。
Redmineは、不具合修正の管理はもちろん、プロジェクト管理全体の課題管理ツールとして活用が可能です。開発だけでなく、QAチームのタスクや外注管理といった全体スケジュールを管理することができます。また、ガントチャートや進捗率、親子チケットでの管理も可能ですし、権限管理も柔軟に行うことが可能です。
一方GitHub Issuesは、開発リポジトリに関連づく軽量な課題管理ツールというイメージです。コードやプルリクエストと強く結び付いているため、開発者目線でバグ修正や実装タスクをコード単位で管理する点で優れています。

例えば、複数リポジトリや複数チームにまたがるような課題管理を行う場合はRedmineを活用することになります。それ以外にも柔軟なワークフローや進捗管理が必要であったり、チケットに関連づくタスク管理等が発生する場合はRedmineの方が向いています。
一方、単一リポジトリで完結する実装や、よりコードに近い部分のみの課題管理をする場合は、一つのプラットフォームで完結するため、GitHub Issuesを活用したほうがメンテナンス箇所も減るため有効でしょう。

質問3：GitHub Actionsに組み込めるツールについて

セミナー内で、静的解析と単体テストを用いたGitHub Actionsのデモを行いました。

こちらの環境はGitHubホストランナー(ubuntu-latest)を用いて、そこに対して、setup-javaというactionsを用いて実行環境を整え、MavenのSpotBugsを用いて静的解析を実行しました。そのため、GitHub Actionsが提供する範囲内で、Mavenのコマンドを実行したという形になります。
関連する部分のyamlファイルは以下になります。

name: Maven CI/CD Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  # ステージ3: 静的解析
  code-analysis:
    name: Code Analysis
    runs-on: ubuntu-latest
    needs: build
    strategy:
      matrix:
        java-version: [11, 17]
    
    steps:
    - name: Checkout code
      uses: actions/checkout@v4
    
    - name: Set up JDK ${{ matrix.java-version }}
      uses: actions/setup-java@v4
      with:
        java-version: ${{ matrix.java-version }}
        distribution: 'temurin'
        cache: maven
    
    - name: Download compiled classes
      uses: actions/download-artifact@v4
      with:
        name: compiled-classes-java-${{ matrix.java-version }}
        path: target/classes
    
    - name: Run SpotBugs analysis
      run: mvn spotbugs:check
      continue-on-error: true
    
    - name: Generate SpotBugs HTML report
      if: always()
      run: mvn spotbugs:spotbugs -DskipTests
    
    - name: Upload SpotBugs results
      uses: actions/upload-artifact@v4
      if: always()
      with:
        name: spotbugs-results-java-${{ matrix.java-version }}
        path: |
          target/spotbugsXml.xml
          target/site/spotbugs.html
        retention-days: 7

質問4：GitHub Actionsのテスト結果の取り扱いについて

例えば以下の理由などから、テスト結果をバージョン管理対象としてGitに保存することはあまり無いかと思います。

• サイズが膨大になってしまう
  コードと比較して、テスト結果のカバレッジのHTMLやスクリーンショットなどはコードよりもファイルサイズが大きくなる傾向にあります。テストの都度=コミットの都度Gitに保存するとリポジトリのサイズが肥大化してしまいます。
• 履歴のノイズとなってしまう
  テスト結果はタイムスタンプやログの内容が実行の都度変更になることが多く、Gitの履歴を追う際にノイズとなってしまうことが多いです。
• 再現が可能
  テスト結果は、基本的にソースコードとテストコードがあれば再現可能です。そのため、履歴管理する必要性も低いと思います。

テスト結果自体の保存として、たとえばCI/CDの実行結果にアーティファクトとして残すということが考えられます。

上記のように単体テストで失敗した際に不具合内容として、GitHub Actionsの実行結果に保存することができます。 こちらは開発者のデバッグ等短期的な利用をする場合には向いています。

また、それ以外にテスト管理ツールやテスト結果のダッシュボードツールと連携するという方法もあります。
弊社取り扱いツールである、Parasoft Jtestを例に挙げると、Parasoft DTPというダッシュボードツールと連携が可能です。CI実行の都度、こういったデータを登録していくことで、品質の遷移を後から追うことができるようにもなります。

監査や分析に長期的に保存する場合は共有フォルダといった外部ストレージや弊社が取り扱いしているテスト管理ツール、TestRailに連携しテスト結果を保存するということも考えられます。

方針としてはGitには再現に必要なソースコードやテストコードを保存し、実行毎に変わるテスト結果などは用途ごとに配置場所を変えるというのが一般的なベストプラクティスかと思います。

質問5：GitHubのブランチ管理について

質問1：GitHubのコミットとブランチについてでも触れましたが、コミット自体には「どのブランチで生まれたか」といった情報は入っていません。
推奨としては、mainにマージする際にはプルリクエストを利用することを推奨します。プルリクエストを用いてマージした場合は、プルリクエストページでブランチを削除後であってもどのブランチからマージされたのかを確認することができます。

また、ブランチを削除後も復元することが可能です。

ただし、プルリクエストを介さずに直接mainブランチにマージし、マージ元のブランチを削除した場合に、元ブランチ名を特定する方法は、少なくとも私は知りません。そのため、mainブランチへのマージにはプルリクエストを用いてのマージを推奨します。

質問6：GitHubとGitLabの主な違いについて

基本的には差異よりも類似点の方が多いです。
コア機能になるバージョン管理は当然として、それぞれプルリクエスト、マージリクエストと名称は異なりますが、ブランチ間のマージをサポートする機能も存在します。最近話題の生成AIによるコード生成サポートについて、GitHub Copilotの方が知名度は高いですが、GitLabにもGitLab Duoというコード生成サポート機能があります。また、それ以外に、CI/CD機能についてもGitHub Actions、GitLab CI/CDとそれぞれ存在します。
プラットフォーム自体の更新頻度もGitHubは四半期ごとに新機能と機能のアップグレードが行われ、GitLabも高頻度でバージョンが更新されています。個人的にはここでの優劣はあまりないかと思います。
機能面というよりも、ライセンスや構築方法に拠って決定されることが多い印象です。

質問7：Configファイルのバージョン管理方法

原則として、コミットはリリース直前ではなくなるべく早いタイミングでのコミットが推奨されます。直前にまとめてコミットをした場合、「誰が・いつ・なぜ」変更したかが不明瞭になり、問題発生時に原因をたどりづらくなります。
例えば、Configファイルの検証中にはConfigファイル検証用のブランチを作成し、検証が完了し、本番環境にデプロイする前にmainブランチにマージして、mainブランチの内容をデプロイするという方法が考えられるかもしれません。

また、Gitとは少し外れますが、設定値を頻繁に更新するとのことですので、Configuration as Codeの概念を取り入れてもよいかもしれません。
参考：Configuration as Code でパイプラインにトレーサビリティを導入するには

質問8：コード以外に関するGitでのバージョン管理について

基本的にGitはバイナリファイルの履歴管理には向いていません。また、標準機能では調べた範囲では特に見つかりませんでした。
また、私自身も知見がありませんので、Qiitaの記事を共有し、質問への回答とさせていただきます。

参考：
Microsoft Access をGITでソース管理している内容を共有します。他にもいい方法があれば取り入れたいです。
【完全保存版】Microsoft AccessをGit/GitHub管理する方法

質問9：コマンドラインでのGitの操作について

弊社のグループ会社である株式会社カサレアルが基礎から学ぶGitコマンド-しっかり身に付くバージョン管理-という講座を実施しております。過去私も受講しましたが、2日がかりで実際のGitを用いてコマンド操作しながら学習を進めることができるため、体系的に学習するには適したコンテンツかと思います。

質問10：ディレクトリの権限の指定方法について

質問の意図を汲み取れていなかったら申し訳ありません。
まずGit自体はディレクトリの読み書きや実行権限は管理しません。追跡するのはあくまでファイルの実行権のみです。例えば「クライアントがpushしてきたコミットがサーバー側のディレクトリ権限を変えてしまう」ということは発生しません。

また、リポジトリ自体のファイル権限を制御したい場合、次の様な手順が考えられるかと思います。

リポジトリ直下で以下のコマンドを実行します。

$ sudo chown -R 所有者:グループ 対象のディレクトリ(hoge.gitなど)
$ find hoge.git -type d -print0 | xargs -0 chmod 770 #ディレクトリの権限設定
$ find hoge.git -type f -print0 | xargs -0 chmod 660 #ファイルの権限設定
$ find hoge.git -type d -print0 | xargs -0 chmod g+s #親ディレクトリのグループを継承するようにする

また、Gitの設定で新規ファイルの権限の指定をすることも可能です。

git config --bool core.sharedRepository group

参考：core.sharedRepository
このように設定することで、権限についてはある程度安全に制御できるようになるかと思います。

まとめ

今回はセミナー内でいただいた以下の質問について回答させていただきました。

• 質問1：GitHubのコミットとブランチについて
• 質問2：RedmineとGitHub Issuesの使い分け
• 質問3：GitHub Actionsに組み込めるツールについて
• 質問4：GitHub Actionsのテスト結果の取り扱いについて
• 質問5：GitHubのブランチ管理について
• 質問6：GitHubとGitLabの主な違いについて
• 質問7：Configファイルのバージョン管理方法
• 質問8：コード以外に関するGitでのバージョン管理について
• 質問9：コマンドラインでのGitの操作について
• 質問10：ディレクトリの権限の指定方法について

本ウェビナーの資料ダウンロードは、こちらのページより可能です。

テクマトリックスでは環境構築からトレーニングまでGitの導入支援が可能です。
お客様のご要望や開発プロセスをヒアリングしたうえで、Gitを用いたソフトウェア構成管理（バージョン管理）の環境構築・移行を行います。また、運用のコンサルティング、トレーニングなども実施しています。
特に、Gitの適切な運用方法や、問題が発生した際の対処法などについての教育は、開発の効率化と安全性向上に大いに寄与します。どのような運用が最適か迷ったり、Gitの使い方についての疑問がある場合は、お気軽にご相談ください。

詳細については、次のボタンより参照ください。