Git・GitHub入門ガイド|add・commit・pushからブランチ運用まで初心者向けに解説

テスト自動化のコードを書き始めたら、次に必要になるのが Git と GitHub の知識です。バージョン管理・チーム共有・CI/CD 連携のすべてが Git を中心に動きます。コマンドを1行ずつ確認しながら、最初に覚えるべき操作を整理します。

💡 コマンドが苦手な方へ
まずは GitHub Desktop(無料の GUI ツール)から始めてもOKです。操作を視覚的に確認しながら Git の概念を身につけられます。ただし、CI/CD のトラブル対応などでは最終的にコマンドが必要になるため、並行してコマンドにも慣れていきましょう。

📌 この記事の対象読者

✅ Git を使ったことがない、またはなんとなくしか分からない方
✅ テスト自動化コードをチームで共有したい方
✅ CI/CD(GitHub Actions)を使ってみたいが、まず Git を理解したい方
✅ 「add・commit・push の違いが分からない」という方

📖 この記事を読むとできること

✔ Git をインストールして初期設定できる
✔ add・commit・push の流れでコードを GitHub に保存できる
✔ .gitignore で venv などの不要ファイルを除外できる
✔ ブランチを使って安全に変更を加えられる
✔ GitHub Actions(CI/CD)への第一歩を踏み出せる

筆者は複数のプロジェクトで Python × Selenium・Playwright・pytest を使ったテスト自動化コードを Git で管理し、GitHub Actions と連携してきました。
本記事では、「コマンドは覚えたけど何をやっているか分からない」という初心者がつまずきやすいポイントを先回りして説明します。

✅ この記事のゴール

  • テスト自動化コードを GitHub に push できる状態
  • .gitignore で venv・__pycache__ を除外できる状態
  • ブランチを切って変更を加え、マージできる状態

Git と GitHub は何が違うのか

最初に混乱しやすい点を整理します。

GitGitHub
何かバージョン管理ツール(ソフトウェア)Git リポジトリのホスティングサービス
場所自分のPC(ローカル)インターネット上(クラウド)
役割変更履歴を記録・管理するコードをチームで共有・CI/CD を動かす
例え「文書の変更履歴を記録するしくみ」「その文書を保存・共有するクラウドフォルダ」

Git なしでは GitHub は使えません。
まず Git をインストールして、ローカルで履歴管理を覚えてから GitHub に接続する、という順番で進めます。

① Git をインストールする

Windows の場合

ブラウザで git-scm.com/download/win にアクセスしてインストーラーをダウンロード・実行します。
設定は基本的にデフォルトのままで問題ありません。「Choosing the default editor used by Git」では「Use Visual Studio Code」を選ぶと後で便利です。

Mac の場合

Mac には Git が最初から入っていることが多いです。ターミナルで以下を実行して確認します。

git --version

バージョンが表示されれば OK です。入っていない場合は Homebrew でインストールします。

brew install git

② Git の初期設定をする

Git をインストールしたら、最初に名前とメールアドレスを設定します。これは commit(変更の記録)に「誰が変更したか」を紐づけるための設定で、一度だけ行えばOKです。

# 名前の設定(GitHub のユーザー名と合わせると分かりやすい)
git config --global user.name "Your Name"

# メールアドレスの設定(GitHub に登録したアドレス)
git config --global user.email "your@email.com"

# 設定を確認する
git config --list

③ 基本ワークフロー:add → commit → push

Git の日常的な操作はこの3ステップで成り立っています。

コマンド意味例え
git add変更をステージング(記録の準備)する「封筒に入れる」
git commit変更をローカルに記録する「封筒を封をして保管する」
git pushGitHub にアップロードする「郵便ポストに投函する」

実際の手順

1. リポジトリを作成する(初回のみ)

# プロジェクトフォルダに移動
cd my-test-project

# Git リポジトリを初期化する
git init

git init を実行すると、フォルダ内に .git という隠しフォルダが作成されます。これが Git の履歴データベースです。

2. 現在の状態を確認する

git status

git status は「今何が変わっているか」を確認するコマンドです。迷ったらとりあえず git status 作業中に何度でも実行できます。

3. ファイルをステージングする(add)

# 個別ファイルを追加(最初は一つずつ確認しながらやると安心)
git add test_sample.py

# 全ファイルをまとめて追加(慣れてきたら)
git add .
💡 慣れるまでは個別ファイルの add がおすすめ
git add . は便利ですが、意図しないファイルも追加してしまいがちです。最初のうちは git add test_login.py のように個別に追加し、git status で確認してから commit する習慣をつけると事故を防げます。

4. 変更を記録する(commit)

# -m でコミットメッセージを書く
git commit -m "add: login test"
💡 コミットメッセージは「何をしたか」を分かりやすく書く
チームで作業するときにコミット履歴を見るのは「自分の未来」や「チームメンバー」です。
"fix""update" だけでは何をしたか分からなくなります。
以下のようなQA向けの具体的なメッセージを参考にしてください。

種別メッセージ例
addadd: login validation test for empty credentials
fixfix: flaky signup test due to implicit wait
refactorrefactor: extract common auth fixture to conftest.py
addadd: API test for 404 response on /users endpoint

5. GitHub に push する(初回)

GitHub でリポジトリを作成したあと(github.com でログインして「New repository」から作成)、以下のコマンドで接続します。

💡 push 前に必ず1回以上 commit が必要です
commit が1つもない状態で git push すると error: src refspec main does not match any というエラーが出ます。手順3〜4(add → commit)を先に実行してください。
# GitHub リポジトリを origin として登録(URL は自分のリポジトリに合わせる)
git remote add origin https://github.com/yourusername/my-test-project.git

# 現在のブランチ名を確認する
git branch
# → 「main」と表示されれば OK
# → 「master」と表示された場合は以下で main に変更する
git branch -M main

# main ブランチを GitHub に push
git push -u origin main
⚠️ GitHub ではパスワード認証が利用できません
2021年以降、GitHub への push にパスワードは使えません。以下のいずれかの方法で認証します。

  • ブラウザ認証:初回 push 時にブラウザが開いて GitHub ログインを求められる(最も簡単)
  • Personal Access Token(PAT):GitHub の設定画面でトークンを発行し、パスワード欄に入力する
  • GitHub CLI:GitHub 公式のコマンドラインツール(gh)です。gh auth login を実行するとブラウザが開いて認証を一括設定できます
  • SSH 鍵:鍵ペアを生成して GitHub に登録する(設定後は最も快適)

初心者にはブラウザ認証か GitHub CLI が最もスムーズです。

2回目以降は git push だけで OK です。

④ .gitignore で不要ファイルを除外する

.gitignore は「Git で管理しないファイル・フォルダ」を指定するファイルです。
テスト自動化プロジェクトで必ず除外すべきものがあります。

除外すべきもの理由
venv/環境ごとに再作成するもの。サイズが大きくなる
__pycache__/Python が自動生成するキャッシュ。不要
.pytest_cache/pytest が生成するキャッシュ。不要
.envAPI キーやパスワードが含まれる可能性がある。絶対に commit しない
*.logログファイル。環境ごとに異なり不要

プロジェクトのルートに .gitignore ファイルを作成して以下を貼り付けます。

# .gitignore(テスト自動化プロジェクト用)

# ⚠️ 環境変数・機密情報(最優先で除外)
.env
.env.*
*.secret

# 仮想環境
venv/
.venv/

# Python キャッシュ
__pycache__/
*.py[cod]
*.pyo

# pytest
.pytest_cache/
.coverage
htmlcov/

# ログ
*.log

# OS 生成ファイル
.DS_Store        # Mac
Thumbs.db        # Windows

# Allure レポート
allure-results/
allure-report/

# IDE 設定(チームで共有不要なもの)
.vscode/
.idea/
⚠️ .gitignore は最初に作ること
一度 commit してしまったファイルは .gitignore を後から追加しても Git の追跡が解除されません。
プロジェクト開始時に .gitignore を作って git add するのを最初の手順にしましょう。

⑤ ブランチを使って安全に変更を加える

ブランチとは、メインのコードを汚さずに変更を試せる「作業用コピー」です。
テスト自動化コードを追加・変更するときは、必ずブランチを切って作業します。

# 現在のブランチを確認する
git branch

# 新しいブランチを作成して移動する(Git 2.23以降の推奨方法)
git switch -c feature/add-login-test
# 古いバージョンの Git では以下を使う
# git checkout -b feature/add-login-test

# 作業・add・commit(通常の操作)
git add .
git commit -m "add: login validation test for valid credentials"

# GitHub にブランチを push する
git push -u origin feature/add-login-test

# 作業完了後、main に戻ってマージする(ローカルマージの場合)
git checkout main
git merge feature/add-login-test

ブランチ名は feature/(新機能)や fix/(バグ修正)のプレフィックスをつけると、何のための変更か分かりやすくなります。

💡 実務では Pull Request(PR)を使ってマージする
チーム開発では、ブランチを GitHub に push した後、GitHub 上で Pull Request を作成してレビューを受けてからマージするのが一般的な流れです。

① main から feature ブランチを切る
② add → commit → push(GitHub へ)
③ GitHub 上で Pull Request を作成
④ チームがレビュー・GitHub Actions が自動テスト実行
⑤ 承認後 main にマージ

⑥ よく使うコマンド早見表

コマンド意味
git status変更の状態を確認する(迷ったらこれ)
git log --onelinecommit 履歴を1行で確認する
git diff何が変わったかを確認する
git pullGitHub の最新変更をローカルに取り込む
git clone <URL>GitHub のリポジトリをローカルにコピーする
git stash変更を一時的に退避させる
git reset --soft HEAD~1直前の commit を取り消す(変更は残る)

⑦ 次のステップ:GitHub Actions で CI/CD を動かす

Git と GitHub の基本が身についたら、次は GitHub Actions を使って pytest を自動実行することができます。
コードを push するたびにテストが自動で走る環境は、テスト自動化の醍醐味の一つです。

# GitHub Actions の設定ファイルを置く場所
.github/
└── workflows/
    └── test.yml   ← この YAML ファイルで CI を定義する
🚀 次は GitHub Actions で pytest を自動実行してみましょう

push するたびにテストが自動で走る CI 環境を作ることが、テスト自動化の本来の姿です。
Git の基本が整ったら、ぜひ次の記事に進んでみてください。

👉 GitHub Actions + Playwright で CI/CD を構築する

実務でよくはまるポイント

⚠️ Git・GitHub ではまりやすいポイント

  1. user.name・user.email を設定していない
    設定なしで commit しようとするとエラーが出ます。git config --global user.namegit config --global user.email を最初に必ず設定しましょう。
  2. commit をせずに push しようとして src refspec main does not match any が出る
    git push は commit が1つもない状態では実行できません。git add → git commit を先に行ってから push してください。
  3. GitHub への push で認証エラーになる
    GitHub ではパスワード認証は廃止されています。ブラウザ認証・GitHub CLI(gh auth login)・Personal Access Token・SSH 鍵のいずれかで認証してください。
  4. venv を commit してしまった
    一度 commit したファイルは .gitignore を追加しても追跡が続きます。git rm -r --cached venv/ で追跡を解除してから commit し直す必要があります。
  5. .env ファイルを commit してしまった
    API キーやパスワードを含む .env を GitHub に push すると、公開リポジトリでは全世界に漏洩します。万一 push してしまったら、すぐにキーを無効化して再発行しましょう。
  6. git add . で意図しないファイルまで追加している
    commit 前に git status で追加されたファイルを確認する習慣をつけましょう。
  7. main ブランチで直接作業してしまう
    main に直接 commit・push すると、CI が壊れたりチームに影響が出たりします。作業前に必ずブランチを切る習慣をつけましょう。
  8. push 前に pull を忘れてコンフリクトが発生する
    チームで作業しているとき、push する前に git pull で最新状態を取り込む習慣が大切です。
  9. コミットメッセージが曖昧で後から追えない
    "fix""update" だけのメッセージは数週間後に何を直したか分かりません。"fix: flaky login test due to implicit wait" のように具体的に書きましょう。

よくある質問(FAQ)

Q. GitHub に push すると認証エラーになります

GitHub はパスワード認証を廃止しています。以下の方法で解決できます。

  • 最も簡単gh auth login(GitHub CLI)を実行してブラウザで認証
  • トークン認証:GitHub の Settings → Developer settings → Personal access tokens でトークンを発行し、push 時のパスワード欄に入力
  • SSH 認証ssh-keygen で鍵ペアを生成して GitHub に公開鍵を登録。設定後は最も快適
Q. main ブランチと master ブランチの違いは何ですか?

どちらもリポジトリの「主幹ブランチ」を指しますが、名前が異なります。master は以前の Git のデフォルト名でした。GitHub は2020年以降デフォルトを main に変更したため、新規リポジトリでは main が標準になっています。既存のリポジトリでは master のままの場合もあり、どちらも正しく動作します。チームやプロジェクトのルールに合わせてください。

Q. GitHub と GitLab は何が違いますか?

どちらも Git リポジトリのホスティングサービスで、CI/CD 機能も持っています。GitHub は世界最大のプラットフォームで、オープンソースプロジェクトが多く、GitHub Actions が CI/CD として広く使われています。GitLab はセルフホスト(自社サーバーにインストール)できるのが特徴で、企業の社内環境で利用されることが多いです。テスト自動化の学習には GitHub が情報量・コミュニティともに充実しています。

Q. SSH 認証と HTTPS 認証はどちらがおすすめですか?

最初は HTTPS(ブラウザ認証 or GitHub CLI)の方が設定が簡単です。SSH は鍵ペアの生成・登録が必要ですが、一度設定するとパスワード・トークン不要で快適に使えます。毎日 push する環境になったら SSH への移行を検討してください。

Q. Pull Request と Merge Request は同じですか?

機能的にはほぼ同じです。GitHub では「Pull Request(PR)」GitLab では「Merge Request(MR)」と呼びます。どちらも「このブランチの変更をメインブランチに取り込んでください」というリクエストを出し、レビューを受けてからマージするための仕組みです。

Q. GitHub アカウントは無料で使えますか?

はい、個人利用では無料プランで十分です。プライベートリポジトリ(非公開)も無制限で作成できます。GitHub Actions は無料枠でも利用できますが、無料利用枠はプランや OS によって異なり変更される場合があります。最新情報は GitHub 公式サイトでご確認ください。

Q. git add .git add -A の違いは何ですか?

git add . はカレントディレクトリ以下の変更を追加します。git add -A はリポジトリ全体(削除されたファイルも含む)の変更を追加します。プロジェクトルートから実行する場合は実質同じになります。どちらを使っても問題ありませんが、commit 前に git status で確認する習慣が大切です。

Q. commit を間違えた場合はどうすればいいですか?

メッセージだけ直したい場合は git commit --amend -m "新しいメッセージ" が最も安全です。
commit 自体を取り消したい場合は git reset --soft HEAD~1 で直前の commit を取り消せます(変更内容は残ります)。
いずれもまだ push していない commit のみ有効です。すでに push した commit の修正は、チーム開発では慎重に行う必要があります。

Q. ブランチはいつ削除すればいいですか?

main にマージ完了した後は削除して問題ありません。git branch -d feature/add-login-test(ローカル)と git push origin --delete feature/add-login-test(リモート)で削除できます。GitHub の Pull Request をマージするときに「Delete branch」ボタンが表示されるので、そこから削除するのが簡単です。

Q. GUI ツール(GitHub Desktop など)を使ってもいいですか?

使っても問題ありません。GitHub Desktop や VS Code の Git 統合機能は、視覚的に操作できて初心者には分かりやすいです。ただし、CI/CD のトラブルシューティングや、コマンドラインしか使えない環境(サーバーなど)では結局コマンドが必要になります。基本コマンドを一度覚えておくことを推奨します。

まとめ

操作コマンドポイント
初期設定git config --global名前とメールアドレスを設定(一度だけ)
状態確認git status迷ったらこれ。何度でも実行 OK
ステージングgit addcommit 前に status で確認する習慣を
記録git commit -mメッセージは具体的に書く
アップロードgit pushチーム開発では GitHub 側に新しい変更がないか確認してから push する習慣をつける
.gitignorevenv・.env は最初から除外する
ブランチgit checkout -b作業前に必ずブランチを切る

Git の操作を覚えると、テスト自動化コードの管理が格段に楽になります。次のステップとして、GitHub Actions で push のたびに pytest を自動実行する環境を作ってみてください。それがテスト自動化の本来の形です。

最初はコマンドが多くて大変に感じるかもしれませんが、status → add → commit → push の流れを毎日繰り返すうちに自然に身につきます。

タイトルとURLをコピーしました