📗

Gitについての基礎知識

に公開
Git
GitHub
tech


行いたいこと

  • Gitの基本概念から実践的な使い方まで体系的にまとめる。
  • GitとGitHubの違いについて。
  • よく使うコマンドやワークフローを整理し、開発で役立つ手引きをまとめる。






Gitとは？

  • ファイルの変更履歴を記録・管理するバージョン管理システムこと。
  • 複数人での開発作業を効率化する。
  • ファイルの変更を追跡し、過去の状態に戻すことが可能になる。
  • 分散型なのでオフラインでも作業できる。

つまり、Gitとは、プログラムのソースコードなどの変更履歴を記録・追跡するための　分散型バージョン管理システム


GitとGitHubの違い

項目 Git GitHub
種類 バージョン管理システム（ツール） オンラインサービス・プラットフォーム
動作場所 ローカルコンピュータ クラウド上
操作方法 コマンドラインツール Webブラウザ・GUI
開発元 オープンソース Microsoft社が運営
主な機能 バージョン管理・履歴追跡 リモートリポジトリ・協業機能
ブランチ戦略との関係 Git Flow（技術的手法） GitHub Flow（サービス最適化手法）


Gitの初期設定

[基本設定]

1. git config --global user.name "名前": ユーザー名を設定
2. git config --global user.email "メールアドレス": メールアドレスを設定
3. git config --global init.defaultBranch main: デフォルトブランチ名をmainに設定
4. git config --list: 設定内容を確認

[SSH鍵の設定]

1. ssh-keygen -t rsa -b 4096 -C "メールアドレス": SSH鍵を生成
2. ~/.ssh/id_rsa.pubの内容をGitHubに登録
3. ssh -T git@github.com: 接続テスト


Gitの基本概念

用語 説明
リポジトリ プロジェクトのファイルと履歴を保存する場所
コミット ファイルの変更を記録するスナップショット
ブランチ 開発の流れを分岐させる仕組み
ワーキングディレクトリ 実際に作業するフォルダ
ステージングエリア コミット前の変更を一時保存する場所
HEAD 現在作業中のブランチの最新コミットを指すポインタ


よく使うGitコマンド

コマンド 説明 用途
git init 新しいリポジトリを作成 初期化
git add ファイルをステージングエリアに追加 ステージング
git branch ブランチの作成・一覧表示 ブランチ管理
git commit 変更をコミット 保存
git status 現在の状態を確認 状態確認
git log コミット履歴を表示 履歴確認
git checkout ブランチの切り替え ブランチ操作
git merge 現在のブランチを他のブランチとマージする マージ
git rebase 元のブランチに変更点を再適用 リベース
git push リモートリポジトリに送信 アップロード
git pull リモートから最新版を取得 ダウンロード
git clone リモートリポジトリを複製 複製


GitHubとの連携方法

[手順の簡易的な記載]

1. GitHubでリポジトリを作成
2. ローカルリポジトリとリモートを紐付け: git remote add origin [URL]
3. 初回プッシュ: git push -u origin main
4. 以降はgit pushでアップロード、git pullで他の人の変更を取得


リモートリポジトリ操作

リモート管理

コマンド 説明
git remote add <name> <url> リモートを追加
git remote -v リモート一覧を表示
git remote set-url <name> <url> リモートURL変更

ブランチ・タグ操作

コマンド 説明
git fetch リモートの変更を確認のみ
git push -u origin <branch> 追跡設定付きプッシュ
git push --delete origin <branch> リモートブランチ削除
git push origin <tagname> タグをリモートに送信


履歴操作・修正コマンド

一時保存

コマンド 説明
git stash 現在の作業を一時保存
git stash list stash一覧を表示
git stash pop 最新のstashを復元して削除
git stash apply stashを復元（削除はしない）

コミット修正

コマンド 説明
git reset --soft HEAD~1 最新コミットを取り消し（変更は保持）
git reset --hard HEAD~1 最新コミットを完全に取り消し
git revert <commit> 指定したコミットを安全に打ち消す
git commit --amend 最新コミットのメッセージを修正
git cherry-pick <commit> 特定のコミットのみを取り込む

ファイル復元

コマンド 説明
git restore <file> ファイルをHEADの状態に戻す
git restore --staged <file> ステージングを取り消す
git checkout <commit> -- <file> 指定コミットからファイルを復元


ブランチの作成・マージ手順

[手順の簡易的な記載]

1. 新ブランチ作成: git branch [ブランチ名]
2. ブランチ切り替え: git checkout [ブランチ名]
3. 作成と同時に切り替え: git checkout -b [ブランチ名]
4. マージ: git merge [ブランチ名]
5. ブランチ削除: git branch -d [ブランチ名]


プルリクエスト

[プルリクエストの目的]

  • コードレビューを経てマージする仕組み
  • 品質向上とバグ防止
  • チーム内での情報共有
  • 実装意図や背景の説明（コメント・議論の場として活用）
  • テストやCI/CDの自動実行トリガーとして利用
  • マージ前に仕様や設計方針との整合性を確認
  • 関連する課題（Issue）とのリンクによる進捗管理

など


[プルリクエストの手順の簡易的な記載]

1. featureブランチで作業完了
2. GitHubでプルリクエストを作成
3. タイトルと説明文を記入
4. レビュアーを指定
5. レビュー完了後、マージボタンでmasterに統合
6. 不要になったfeatureブランチを削除


コンフリクトの解決方法

[コンフリクトとは]

  • 同じファイルの同じ箇所を複数の人が異なる内容で変更した際に起こる衝突
  • Gitが自動でマージできない状態
  • 複数人開発では避けられない現象


[発生する状況]

  • 同じ行を異なる内容で変更した際に発生
  • 異なるブランチで同じファイルを編集した場合
  • マージやプル時に競合が検出される


[コンフリクトの解決手順の簡易的な記載]

1. コンフリクトが発生したファイルを確認（git statusでチェック）
2. コンフリクト箇所を手動で編集
3. <<<<<<<、=======、>>>>>>>の記号を削除
4. どちらの変更を採用するか決定（または両方を組み合わせ）
5. 修正後に git add → git commit（マージツールの活用も可能）
6. 解決後にテストを実行（動作確認）


[コンフリクト表示の見方]

  • <<<<<<< HEAD: 現在のブランチの内容
  • =======: 区切り線
  • >>>>>>> ブランチ名: マージ対象ブランチの内容
  • コンフリクトしている行数が表示される場合がある
  • 複数箇所でコンフリクトした場合、各箇所に同様の記号が表示される


Gitのワークフロー

[基本フロー]

1. 作業: ファイルを編集・作成
2. add: 変更をステージングエリアに追加（git add . ⇦ 全ての変更をステージング）
3. commit: 変更を記録（git commit -m 'メッセージ'）
4. push: リモートリポジトリに送信（git push origin [branch名]）


Git Flow（複雑なプロジェクト向け）

ブランチ構成（Git Flow方式）

ブランチ 説明 用途
master/main 本番環境にリリースするブランチ 常に安定した状態を保つ
develop 開発の統合ブランチ 新機能を統合するメインライン
feature 新機能開発用ブランチ（feature/ログイン機能など） 個別機能の開発
release リリース準備用ブランチ バグ修正とリリース作業
hotfix 緊急バグ修正用ブランチ 本番の緊急対応


[Git Flowの流れの簡易的な記載]

1. developから新機能用のfeatureブランチを作成
2. 機能開発完了後、featureをdevelopにマージ
3. リリース時にreleaseブランチを作成
4. テスト完了後、releaseをmasterとdevelopにマージ
5. 緊急時はmasterからhotfixブランチを作成


GitHubのワークフロー（GitHub Actionsについて）

[GitHub Actionsとは？]

  • GitHub上でコードのテスト・ビルド・デプロイなどを自動化する仕組み
  • イベント（push、pull requestなど）をトリガーに実行
  • .github/workflows/ のYAMLファイルで設定
  • 無料枠あり、CI/CDによく使われる


[GitHub Actionsの基本要素]

  • Workflow: 自動処理の設定ファイル（.github/workflows/配下のYAML）
  • Job: Workflow内の処理のまとまり
  • Step: Job内の実行手順
  • Action: 再利用可能な処理部品


[GitHub Actionsの流れ]

1. イベント（例: push）が発生
2. 対応するWorkflowが実行
3. Job → Stepの順に処理が進む
4. 自動テストやデプロイが完了


GitHub Actionsが記載される、Workflowファイル例
yaml
name: Run Tests

on:
  push:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Set up Ruby
        uses: actions/setup-ruby@v1
        with:
          ruby-version: 3.1
      - name: Install dependencies
        run: bundle install
      - name: Run tests
        run: bundle exec rspec


GitHub Flow

[ブランチ構成]

  • master/main: 常にデプロイ可能な状態
  • feature/作業用ブランチ: 機能追加・バグ修正用ブランチ など（ブランチの名前は自由）
作業用ブランチでよく使われる命名例

[命名例]

feature/login-function（機能別）

fix/header-bug（修正系）

update/readme（更新系）

add-user-profile（動作を表す）

issue-123（課題番号）

hotfix/security-patch（緊急修正）

refactor/code-cleanup（リファクタリング）

docs/api-documentation（ドキュメント）

test/unit-tests（テスト追加）

chore/dependency-update（保守作業）

style/css-improvements（スタイル修正）

perf/performance-optimization（パフォーマンス改善）

build/webpack-config（ビルド設定）

ci/github-actions（CI/CD設定）

experiment/new-algorithm（実験的機能）


[GitHub Flowの流れの簡易的な記載]

1. masterから新しいfeature/作業用ブランチを作成
2. ローカルで開発作業を実施
3. 作業完了後、プルリクエストを作成
4. コードレビュー実施
5. レビュー完了後、masterにマージ
6. 自動デプロイが実行される
7. 不要になったfeatureブランチを削除

Git関連ワークフローの比較

GitのワークフローとGitHubのワークフローの違い

項目 Gitのワークフロー GitHubのワークフロー
概要 ローカル〜リモート間でのコード管理手順 GitHub Actions による自動化処理の流れ
目的 変更の記録・共有・統合・バージョン管理 テスト・ビルド・デプロイ・品質チェックの自動化
対象 開発者の手動操作（add, commit, push等） サーバー上の自動処理（CI/CD、Lint等）
トリガー 開発者のコマンド実行 イベント（push、PR、スケジュール、手動実行等）
定義場所 チーム・プロジェクトの運用ルール .github/workflows/ 配下のYAMLファイル
実行環境 開発者のローカル環境・Gitリモートリポジトリ GitHubのクラウド環境（runner）
代表例 Git Flow、GitHub Flow、GitLab Flow CI/CDパイプライン、コード品質チェック、自動デプロイ

Git FlowとGitHub Flowの違い

項目 Git Flow GitHub Flow
適用規模 複雑・大規模・長期開発プロジェクト向け シンプル・小中規模・短期イテレーション向け
ブランチ構成 master、develop、feature、release、hotfix master、feature/*
運用方針 開発・本番環境を明確分離、段階的リリース管理 常にmasterをデプロイ可能状態に保持
リリース方法 releaseブランチで準備→masterにマージ featureから直接masterにマージ→即座にデプロイ
メリット 安定運用、厳密なリリース管理、品質担保 シンプルな流れ、素早いフィードバック、継続的デプロイ
デメリット ブランチ管理が複雑、リリースサイクルが長い 大規模開発には不向き、コンフリクト発生しやすい
適用場面 複数バージョン並行開発、パッケージソフトウェア アジャイル開発、頻繁デプロイのWebサービス
開発サイクル 計画的なリリースサイクル（週〜月単位） 継続的インテグレーション（日〜週単位）




以上です。






GitHubで編集を提案

Discussion