現場で使えるGit & GitHub入門：基礎から実践的なチーム開発まで

Last updated at 2025-01-09Posted at 2025-01-07

はじめに

今回はGitとGitHubについて基礎から実践的な使い方まで説明をしていきます。
特に、個人開発からチーム開発への移行を考えている方や、GitHubでのコードレビューに携わり始めた方に役立つ内容となっています。
本記事を通じて、GitHubの基本的な使い方から実践的なチーム開発の手法まで、ステップバイステップで理解を深めていただければ幸いです。

GitとGitHubとは？

Gitとは、ファイルのバージョン管理を行うツールです。一方、GitHubはGitをベースにしたオンラインのバージョン管理プラットフォームです。GitHubを利用すれば、開発中のソースコードやデータをオンラインで保存・管理でき、どこからでもアクセス可能です。また、チーム開発では変更内容を一元管理できるため、効率的に共同作業を進めることができます。

GitHubでできること

GitHubでできることはさまざまありますが、いくつか紹介します。

バージョン管理 :
ソースコードやデータ変更の履歴を記録し、過去の状態に戻したり、過去の履歴と比較したりできます。
(例：不具合が起きても、以前のバージョンに復元可能)
オンラインストレージ :
開発中のファイルをGitHub上に保存することで、どこからでもアクセスが可能
(例: 家で作業したコードを、職場のPCで開ける)
チーム開発の効率化:
チーム内でプログラムやタスクなどの情報を共有でき、変更内容のレビューも行える
(例：プルリクエスト機能を使って、コードレビューを行う)
学習ツールとしての活用:
他人が公開しているプログラムや研修資料を参考にしたりできる
(例：オープンソースプロジェクトのコードを見て学ぶ)
成果物の公開・共有:
個人で作成した成果物を公開・共有することができ、ポートフォリオなどを公開することもできる
(例：ポートフォリオを作成し、就職活動などで公開・共有する)

おさえておきたい基礎知識

GitHubを使う前におさえておきたい基礎知識は以下になります。一つずつ説明をしていきます。

リポジトリ
コミット
プッシュ/プル
ブランチ

1. リポジトリ

一言で表すと、データやファイルなどの保管場所を表す言葉になります。英語で、「貯蔵庫」「倉庫」などを意味します。GitやGitHubでデータやファイルを管理する際に必ずリポジトリが必要になります。

リポジトリの種類は2種類

ローカルリポジトリ：自分のPC内に作成するリポジトリ
リモートリポジトリ：ネットワーク上に作成するリポジトリ(例：GitHub)

2. コミット

一言で表すと、ローカルリポジトリに変更を保存することです。これにより、変更履歴を確認したり、特定の状態に戻したりすることができます。また、コミットをする際は、変更を簡潔に説明するメッセージを含める必要があります。

3. プッシュ/プル

一言で表すと、ローカルリポジトリの変更内容をリモートリポジトリにアップロードすることです。これにより、自分が行った変更がネットワーク上に保存され、公開、共有することができます。

一方で、プルとは、リモートリポジトリからローカルリポジトリに変更をダウンロードすることを指します。

pull：ダウンロード
push：アップロード

4. ブランチ

一言で表すと、履歴の流れを分岐させて記録していく機能のことです。これにより、プロジェクト本体に影響を与えずに開発を行えるようになります。リポジトリには必ず一つ以上のブランチが必要となるため、リポジトリを作成するとmainというデフォルトのブランチが自動的に作られます。

▼ブランチ命名規則

ブランチ種別	プレフィックス	説明	例
公開するもの	main	公開するものを置くブランチ	main
開発中のもの	develop	開発中のものを置くブランチ	develop
機能開発	feature/	新機能の開発用	feature/add-login
バグ修正	fix/	バグ修正用	fix/login-error
ホットフィックス	hotfix/	緊急の本番バグ修正用	hotfix/critical-error
リリース	release/	リリース準備用	release/v1.0.0
機能改善	improve/	既存機能の改善用	improve/login
リファクタリング	refactor/	コードの修正用	refactor/auth-logic
ドキュメント	docs/	ドキュメント更新用	docs/api-guide
スタイル	style/	コードスタイル修正用	style/fix-indent
メンテナンス	chore/	その他の修正用	chore/update-packages

▼ブランチ名ベストプラクティス

すべて小文字を使用
単語の区切りはハイフン(-)を使用
簡潔でわかりやすい名前を付ける
チケット番号がある場合は末尾に付ける（例：feature/add-login-#123）

▼主要ブランチ

main/master: 本番環境用
develop: 開発環境用
staging: テスト環境用

GitHubワークフロー

GitHubのワークフローを理解するのに、下記４点をおさえるようにしましょう。

ワークツリー
インデックス
ローカルリポジトリ
リモートリポジトリ

1. ワークツリー(Working Tree)

定義：作業ディレクトリを指し、現在編集中のファイルがおかれている場所
特徴：
- git cloneでリポジトリを取得すると、ワークツリーにファイルが置かれる
- ファイルを編集したり、新しいファイルを追加すると「変更有」などとして認識される

2. インデックス（Index）

定義：次回のコミットに含める変更を一時的に保存する場所
特徴：
- git addを実行すると、ワークツリーからインデックスに変更内容が追加される
- インデックスに追加されていない変更は、次のコミットに含まれない

3. ローカルリポジトリ（Local Repository）

定義：自分のPCに保存されているリポジトリ。過去の変更履歴が含まれる
特徴：
- git commitによってインデックスの内容がローカルリポジトリに保存される

4. リモートリポジトリ（Remote Repository）

定義：GitHubなどのサービス上にホスティングされるリポジトリ
特徴：
- git pushによってローカルリポジトリの内容をリモートに送信する

▼ワークフロー詳細

step1: ワークツリーに変更を加える

新しいファイルを作成したり、既存ファイルを編集
git status を実行して、変更の状態を確認

未追跡ファイル: 新規作成されたがインデックスに追加されていないファイル
変更されたファイル: インデックスに登録済みだが、内容が更新されたファイル

step2: インデックスに変更を追加

git add <ファイル名> または git add . で、変更をインデックスに追加
git status を実行して、変更の状態を確認

step3: ローカルリポジトリにコミット

git commit -m "コミットメッセージ" を実行し、ローカルリポジトリにインデックスの内容を保存
git log を実行すると、コミット履歴を確認できる

step4: リモートリポジトリにプッシュ

git push origin <ブランチ名>を実行し、GitHubに変更をアップロード

初回のプッシュ時にはリモートリポジトリが指定されている必要がある
(例：　git remote add origin <リポジトリURL>)

実践編

1. リポジトリの作成

GitHubにログインをする
「Repositories」の「New」ボタンをクリックする
リポジトリ名を入力する(例：sample)
リポジトリを公開したい場合は「Public」、非公開にしたい場合は「Private」を選択
「Create repository」をクリック
リポジトリのURLを取得(cloneで使用)

2. クローン

作業をしたいディレクトリに移動
取得したURLを使用しコマンドを実行

# クローンコマンドを実行
$ git clone https://github.com/username/sample.git

# warningが表示されるが、無視してOK
Cloning into 'sample'...
warning: You appear to have cloned an empty repository.

# 作業ディレクトリに移動
$ cd sample

# vs codeを起動
$ code .

3. 最初のプッシュ

リポジトリ作成後の最初のpushを行います。新しく作成したローカルディレクトリをGitリポジトリとして初期化し、リモートリポジトリと連携させる必要があります。

# 初期化
$ git init

# ステージングとコミット
$ git add .
$ git commit -m "first commit"

# mainブランチの設定とプッシュ
$ git branch -M main
# リモートリポジトリの登録
$ git remote add origin git@github.com:username/sample.git
# -uオプション：以降のpush/pullで対象ブランチを省略可能にする
$ git push -u origin main

# developブランチの作成
$ git checkout -b develop
$ git push -u origin develop

4. ファイル編集(スタイル追加)

index.htmlの追加

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link rel="stylesheet" href="style.css">
    <title>Document</title>
</head>
<body>
    <h1>Hello world!</h1>
</body>
</html>

style.cssの追加

body{
    width: 100vw;
    height: 100vh;
    padding: 0;
    margin: 0;
    box-sizing: border-box;
    display: flex;
    align-items: center;
    justify-content: center;
    background-color: yellow;
}

h1{
    color: red;
    font-size: 80px;
}

5. スタイル用のブランチを作成

# developブランチに移動
$ git checkout develop
# developブランチから最新のファイルを反映
$ git pull origin develop 
# styleブランチを作成して切り替え
$ git checkout -b style/add

6. プルリクエストの作成（style/add → develop）

pushコマンドを実行

# スタイルブランチで作業後、プッシュ
$ git add .
$ git commit -m "style: 文字のスタイルを追加"
$ git push -u origin style/add

GitHubへログイン
1. リポジトリページに移動
2. 「pull requests」タブをクリック
3. 「New pull request」ボタンをクリック
4. ブランチの選択
  - base: develop（マージ先）
  - compare: style/add（マージ元）
5. プルリクエストの内容を記入
6. 「Create pull request」をクリック

# 概要
- 文字スタイルの追加
- レイアウトの中央揃え設定

## 変更内容
- フォントサイズを80pxに設定
- テキストカラーを赤色に変更
- 背景色を黄色に設定
- Flexboxによる中央配置の実装

## 確認項目
- [ ] フォントサイズは適切か
- [ ] 色のコントラストは十分か
- [ ] レスポンシブ対応は問題ないか

## スクリーンショット
（実装画面のスクリーンショット）

プルリクが完了すると、「Pull request」タブの箇所が1となります。

プルリクエスト（PR）は、特定のブランチペア（例：style/add→ develop）の間で既にPRが存在する場合、新しいPRを作成することはできません

▼対処法

既存のPRを更新する
この場合、自動的に既存のPRに変更が反映される。

# 同じブランチで追加の変更を行う
$ git add .
$ git commit -m "style: フォントスタイルを更新"
$ git push origin style/add

２. 新しいブランチを作成
新しいブランチから新しいPRを作成できる。

# 新しいブランチを作成
$ git checkout -b style/add-v2
$ git add .
$ git commit -m "style: フォントスタイルを更新"
$ git push origin style/add-v2

▼ベストプラクティス

1つの機能に対して1つのPRを維持
追加の変更は既存のPRに追加コミット
どうしても新しいPRが必要な場合は、別ブランチを作成

7. developブランチにマージ

プルリクを確認してもらい、何も問題がない場合は、developブランチに対してmergeを行います。

8. ブランチの削除

style/addブランチはもういらないので、削除します。

リモートリポジトリから削除

ローカルリポジトリから削除

# マージ済みブランチを削除する場合
$ git branch -d style/add

# 強制的に削除する場合（マージされていないブランチも削除）
$ git branch -D style/add

# 現在のブランチ一覧を確認
$ git branch

# style/addブランチが消えていることを確認
* develop
  main

既存のブランチが削除したいブランチになっている場合は、削除できないのでgit checkoutで他のブランチに移動してから削除してください

よく使用するgitコマンド

1. 基本操作

コマンド	説明
`git init`	リポジトリを初期化（新しいGitプロジェクトを作成）
`git clone <URL>`	リモートリポジトリをローカルに複製
`git status`	作業ディレクトリの状態を表示
`git add <ファイル名>`	ファイルをステージングエリアに追加
`git commit -m "メッセージ"`	変更をローカルリポジトリにコミット
`git log`	コミット履歴を表示

2. ブランチ操作

コマンド	説明
`git branch`	ローカルのブランチ一覧を表示
`git branch　-r`	リモートリポジトリに存在するブランチの一覧を表示
`git branch <ブランチ名>`	新しいブランチを作成
`git checkout <ブランチ名>`	ブランチを切り替え
`git checkout -b <ブランチ名>`	ブランチを新しく作成し、切り替え
`git switch -c <ブランチ名>`	ブランチを新しく作成し、切り替え(推奨版)
`git switch <ブランチ名>`	ブランチを切り替え（checkoutの代替）
`git merge <ブランチ名>`	他のブランチを現在のブランチにマージ
`git branch -d <ブランチ名>`	ブランチを削除

3. リモート操作

コマンド	説明
`git remote -v`	リモートリポジトリの情報を表示
`git push <リモート名> <ブランチ名>`	ローカルの変更をリモートリポジトリに反映
`git pull <リモート名> <ブランチ名>`	リモートリポジトリから変更を取得してマージ
`git fetch <リモート名>`	モートから最新情報を取得するが、ローカルブランチには影響を与えない

4. 差分と変更履歴

コマンド	説明
`git diff`	ステージング前の変更を表示
`git diff --staged`	ステージング済みの変更を表示
`git log --oneline`	簡潔なコミット履歴を表示
`git blame <ファイル名>`	ファイルの各行を誰が変更したかを表示

5. リセット・復元

コマンド	説明
`git reset <ファイル名>`	ステージングエリアからファイルを削除
`git reset --hard`	コミットや変更をすべて取り消して以前の状態に戻す
`git restore <ファイル名>`	ファイルを作業ディレクトリに復元
`git revert <コミットID>`	指定したコミットの変更を取り消す（履歴は残す）

6. その他便利なコマンド

コマンド	説明
`git stash`	変更を一時的に保存
`git stash pop`	一時保存した変更を復元
`git cherry-pick <コミットID>`	特定のコミットを別のブランチに適用
`git show <コミットID>`	特定のコミットの詳細を表示

おわりに

実務では個人開発が多く、なかなか実践の機会が限られていましたが、最近コードレビューを担当することになり、GitHubの使い方をしっかりと学び直して実務に活かしていきたいと思います。これを機に、チーム開発にもスムーズに対応できるよう成長していけたらと考えています！

最後までご覧いただき、本当にありがとうございました。この記事が少しでも皆さまのお役に立てば幸いです！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up