沖縄高専ICT委員会技術継承　Git/GitHub編　#03-応用編

はじめに

Hey Guys!
この度、委員長の指示で沖縄高専ICT委員会技術継承としてGit/GitHubを教えるアヤノです。

最終回となる第3章では、Githubを使ったチームでのバージョン管理の理解を目的として、最低限知っていたほうが良い内容を説明します。今回も演習もあるので、頑張りましょう！

チームで行うバージョン管理

昔は、USBメモリやGoogle Driveを使ってプロジェクトのファイルを共有し、バージョン管理を行うチームもありました。この方法は以下の場合では大きな問題はなく、ある程度スムーズに共同作業を進めることができます。

• 学校の授業での短期間のチーム開発
• 個人での小規模なプロジェクト

しかし、プロジェクトの規模が大きくなると、次のような問題が発生します。

• 「どこが編集されたのか分からない」（変更履歴が管理しにくい）
• 「誰が編集したのか分からない」（責任の所在が不明確になる）
• 「コードレビューが適切に行われたのか不明」（品質の管理が難しくなる）

特に、複数人で同時に作業する場合、ファイルの競合や誤って古いデータで上書きしてしまうリスクもあります。そのため最近では、多くのチーム開発ではGitHubを活用してバージョン管理を行います。

Githubとは

GitHubは、ソフトウェア開発プロジェクトのためのバージョン管理サービスです。Gitというバージョン管理システムをベースにしており、主にプログラムのソースコードを効率的に管理・共有するために使われます。また、インターネット上でプロジェクトを管理できるため、個人開発から大規模なチーム開発まで幅広く活用されています。

GitHubを使うことで、以下の利点に肖れます。

• リモートリポジトリの管理：プロジェクトをオンラインで保存し、どこからでもアクセス可能
• チームでの共同開発：複数人で同時に作業しても、変更履歴や差分を管理できる
• プルリクエスト（Pull Request）：コードの変更点をチームでレビューし、品質向上を図る
• 課題管理（Issues）：バグや新機能のタスク管理も一元化できる

GitとGitHubの違い

初心者がよく混同しがちなGitとGitHubの違いについて説明します！

• Git： バージョン管理を行うためのツール（ローカル環境でも使用可能）
• GitHub： Gitで管理されたデータをオンライン上で共有・管理するためのサービス

つまり、Gitは道具、GitHubはその道具を活かすための場所と考えるとイメージしやすいでしょう。

Githubを使う上で必要になるGitコマンド

それでは、Githubを使う上で必要になるGitコマンドの流れとそのイメージを説明します。

紹介するコマンドのイメージ

gitでは、基本的にはこの8つのコマンド（clone, switch, add, commit, push, pull, merge/rebase）を使って、バージョン管理をします。個人的には、この8つのコマンドを理解・使用ができれば、後は調べながらでもgithubとgitを使えると考えています。

コマンドの紹介(前回解説したものを除く)

ここでは、先程のイラストに登場した5つのコマンド（clone, push, pull, merge, rebase）の説明と例を説明します。前回説明した内容は省いているので。気になる方は「沖縄高専ICT委員会技術継承　Git/GitHub編　#02-基礎編」を参照してください。

git clone

git clone は、リモートリポジトリの内容を自分のローカル環境に複製するコマンドです。新しいプロジェクトを取得するときや、他の人のリポジトリを手元で編集したいときに使います。

git clone <リポジトリのURL>

これで指定したURLのリポジトリがローカルにコピーされます。また、このコマンドは、GitHubからプロジェクトをダウンロードする際によく使われます。

git push

git push は、ローカルで行った変更をリモートリポジトリに反映するコマンドです。チームでの共同作業では、自分の作業を共有するために欠かせません。

git push origin -u <ブランチ名>

これで指定したブランチの変更内容がリモートリポジトリにアップロードされます。origin はリモートリポジトリの名前、<ブランチ名> は更新したいブランチを指します。-uはオプションで、おまじない程度の認識でOKです。

git pull

git pull は、リモートリポジトリの最新の変更をローカルに取り込むコマンドです。チームメンバーが行った変更を取得し、自分の環境に反映させたいときに使います。

git pull origin <ブランチ名>

これで指定したブランチの最新の変更がローカルにダウンロードされ、自動的にマージされます。
※git fetch と git merge をまとめて実行するイメージです。(詳しく知りたい方は要検索！)

git merge

git merge は、異なるブランチの変更を統合するコマンドです。新しい機能を開発したブランチの内容をメインブランチに取り込むときなどに使用します。

git merge <ブランチ名>

現在いるブランチに、指定したブランチの変更を統合します。しかし、コンフリクト（衝突）が発生した場合は手動で解決する必要があります。

git rebase

git rebase は、あるブランチの変更履歴を別のブランチの先頭に付け替えるコマンドです。履歴を直線的に整理したいときに便利です。

git rebase <ブランチ名>

これで現在のブランチの変更を、指定したブランチの最新のコミットの上に再配置します。
git merge に比べて履歴がスッキリしますが、使い方を誤るとトラブルの原因になることもあるので注意が必要です。

GitHubのプロフィールを作ろう（演習）

それでは、演習としてGitHubのプロフィールを作りましょう。
今回作成するプロフィールは、私が使っているモノを再現することを目標にします。

1. リポジトリを作成する

自身のgithubと同じユーザー名のリポジトリを作成するために「New」を押します。

上記の図のような設定をし、一番下の「Create repository」を押して、リポジトリを作成します。

2. リポジトリをローカルにダウンンロードする

「Code」を押して、git cloneに必要なURLを取得します。

URLの取得が出来たら、ターミナルで以下のコマンドを入力し、リポジトリをダウンンロードします。

git clone <URL>

3. ファイル(README.md)を編集する

git cloneが出来たら、ダウンンロード出来たフォルダーの中で「README.md」を作成し、以下の内容を埋めてください。

<h1 align="center"> <ユーザー名> </h1>
<h3 align="center"> Goals for 2025 : ＜2025年の目標＞ </h3>

## Tech Stack
### programming languages
- Python
- C
- ＜追加があれば書いてね！＞
### design
- ＜追加があれば書いてね！＞
### others
- Ubntsu
- ＜追加があれば書いてね！＞

4. ローカルの変更をリモートにアップする

それでは、編集したファイルがある場所で以下のコマンドを実行しましょう！

git switch main
git add .
git commit -m "update: README.md"
git push -u origin main

5. プロフィールを確認する

最後に、自身のgithub（https://github.com/＜ユーザー名＞）を開き、かっこいいプロフィールを確認しましょう！
ここで編集したプロフィールが確認出来たら、演習の成功です。
失敗したら、周りにいる先輩に聞いて見て「なにが原因か」を考えましょう。

チーム開発をする上で知っておきたいGitHubについて

GitHub Actions

GitHub Actionsは、GitHub上でCI/CD（継続的インテグレーション/継続的デリバリー）を自動化するための強力なツールです。プッシュ、プルリクエスト、マージなどのイベントに応じて、テストの実行、ビルド、デプロイなどのプロセスを自動化できます。

GitHub Actionsの主な特徴は以下のようになり、チーム開発に導入するとコミットの量の調整やテスト等が良い感じになります。

• 自動化: コードのテスト、ビルド、デプロイを自動化できる
• 柔軟性: カスタムワークフローをYAMLファイルで定義可能
• GitHubとの統合: GitHub内で完結するため、外部ツールの導入が不要

GitHub Actionsの見本

Node.jsアプリのテストを自動化するワークフロー

name: Node.js CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '16'
      - run: npm install
      - run: npm test

テンプレート・サンプルが纏められているサイト？

• Marketplace
• sdras/awesome-actions: A curated list of awesome actions to use on GitHub

gitignore

.gitignoreは、Gitでバージョン管理の対象外にするファイルやフォルダを指定するためのファイルです。一時ファイルや個人の設定ファイル、機密情報など、リポジトリに含めたくないファイルを除外する際に使います。基本的は、公式（GitHub gitignore）が.fitignoreの見本を沢山公開しているので、適時参照することをおすすめします。

.gitignoreのポイントは以下のようになり、使用する開発言語によっては導入が必須となります。

• すでにコミットしたファイルは無視されない: コミット済みのファイルを無視するにはgit rm --cached <ファイル名>が必要
• 階層ごとに設定可能: プロジェクトルートやサブディレクトリに個別の.gitignoreを置ける

git-flow

Git-Flowは、Gitを使った開発フローのひとつで、機能開発・リリース・ホットフィックスなどの作業を効率的に管理できる方法論です。ブランチを役割ごとに分け、明確なルールで運用することで、複雑なプロジェクトも整理しやすくなります。Git-Flowで使用される主要なブランチは以下の表のようになっています。

ブランチ名	役割	作業内容
main	本番環境用	安定したバージョンのみを管理
develop	開発用	新機能開発のベースとなるブランチ
feature/*	機能開発用	新しい機能や改善点を個別に開発
release/*	リリース準備用	リリース前の最終調整やバグ修正
hotfix/*	緊急バグ修正用	本番環境の緊急バグ修正を行う

コミットメッセージの工夫（コミットメッセージのプレフィックス）

コミットメッセージにプレフィックスをつけることで、変更内容が一目でわかるようになり、レビューや履歴の確認が効率化されます。使い方は、「＜プレフィックス＞：＜コミットメッセージ＞」です。

プレフィックス	説明
add	新しい機能やファイルの追加
fix	バグ修正やエラーの修正
update	既存の機能やリソースの更新
refactor	コードのリファクタリングや構造の改善、パフォーマンスの最適化
remove（delete）	コードやファイルの削除
move	ファイルやディレクトリの移動またはリネーム
revert	以前のコミットの取り消し
rename	名前の変更やリネーム
docs	ドキュメントの変更や追加
style	コードのスタイルやフォーマットの変更
perf	パフォーマンスの改善
chore	雑務やビルドプロセスの変更

プレフィックスを使うことで、以下の利点に肖れます。

• 変更内容の可視化: 履歴を見ただけで何をしたのかがわかる
• チーム内のルール統一: コードレビューやCIのトリガー条件としても活用できる
• 自動化との連携: GitHub Actionsなどで条件分岐に使える

おわり

三回にわたる講座、お疲れさまでした。
これで、Git/GitHubの基礎が修得できたと言えます！
これからの開発で、この講座の知識が活かされることを願っています。

P.S.　Githubは就活にも使えるから、普段から使うことをおすすめします！

おまけ（GitHubでよく使う用語の説明）

今回のおまけは、GitHubでよく使う用語の説明です。ココにある単語はGitHubを使う上で逃げられないので、時間がある時に読んでおいてください。

リポジトリ

リポジトリは、ソースコードや関連ファイルを管理する場所です。GitHub上でプロジェクトを管理するための「フォルダ」のような役割を果たします。バージョン管理が可能で、コードの履歴や変更点を追跡できます。

GitHubとGitでは、リポジトリの名称が変化します。

• ローカルリポジトリ: 自分のPC上で管理するリポジトリ
• リモートリポジトリ: GitHubなどのサーバー上で管理するリポジトリ

また、GitHubのリポジトリは後悔する範囲によって名称が変化します。

• パブリックリポジトリ（Public Repository）: 誰でも閲覧可能なリポジトリ
• プライベートリポジトリ（Private Repository）: 許可されたユーザーのみが閲覧・編集できるリポジトリ

README.md

README.mdは、リポジトリの概要や使い方を説明するためのドキュメントです。GitHub上ではリポジトリのトップページに自動で表示されます。また、Markdown形式で記述されるため、見出しやリンク、コードブロックを簡単に追加できます。

コンフリクト

コンフリクト（Conflict）は、複数の人が同じファイルの同じ箇所を編集したときに発生する競合状態です。これは、Gitが自動的にマージできず、手動で解決する必要があります。以下のように表示された部分を確認し、どちらの変更を残すか、あるいは両方を組み合わせるかを決めます。

# 例: コンフリクト発生時の表示
<<<<<<< HEAD
自分の変更
=======
相手の変更
>>>>>>> branch-name

issue

issue（イシュー）は、バグ報告、機能追加の提案、タスク管理などに使うGitHubのチケットシステムです。タスクの進捗状況を可視化するために、プロジェクトボードやラベルと組み合わせて使うことが多いです。

issueの用途は以下の通りです。

• バグの報告: プロジェクトで見つかった不具合を共有
• タスク管理: やるべき作業を可視化して管理
• 議論の場: 新しい機能の提案や設計について議論