テスト自動化のコードを書き始めたら、次に必要になるのが 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 は何が違うのか
最初に混乱しやすい点を整理します。
| Git | GitHub | |
|---|---|---|
| 何か | バージョン管理ツール(ソフトウェア) | 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 push | GitHub にアップロードする | 「郵便ポストに投函する」 |
実際の手順
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 .
git add . は便利ですが、意図しないファイルも追加してしまいがちです。最初のうちは git add test_login.py のように個別に追加し、git status で確認してから commit する習慣をつけると事故を防げます。4. 変更を記録する(commit)
# -m でコミットメッセージを書く
git commit -m "add: login test"
チームで作業するときにコミット履歴を見るのは「自分の未来」や「チームメンバー」です。
"fix" や "update" だけでは何をしたか分からなくなります。以下のようなQA向けの具体的なメッセージを参考にしてください。
| 種別 | メッセージ例 |
|---|---|
add | add: login validation test for empty credentials |
fix | fix: flaky signup test due to implicit wait |
refactor | refactor: extract common auth fixture to conftest.py |
add | add: API test for 404 response on /users endpoint |
5. GitHub に push する(初回)
GitHub でリポジトリを作成したあと(github.com でログインして「New repository」から作成)、以下のコマンドで接続します。
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
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 が生成するキャッシュ。不要 |
.env | API キーやパスワードが含まれる可能性がある。絶対に 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/
一度 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/(バグ修正)のプレフィックスをつけると、何のための変更か分かりやすくなります。
チーム開発では、ブランチを GitHub に push した後、GitHub 上で Pull Request を作成してレビューを受けてからマージするのが一般的な流れです。
| ① main から feature ブランチを切る |
| ↓ |
| ② add → commit → push(GitHub へ) |
| ↓ |
| ③ GitHub 上で Pull Request を作成 |
| ↓ |
| ④ チームがレビュー・GitHub Actions が自動テスト実行 |
| ↓ |
| ⑤ 承認後 main にマージ |
⑥ よく使うコマンド早見表
| コマンド | 意味 |
|---|---|
git status | 変更の状態を確認する(迷ったらこれ) |
git log --oneline | commit 履歴を1行で確認する |
git diff | 何が変わったかを確認する |
git pull | GitHub の最新変更をローカルに取り込む |
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 を定義する
push するたびにテストが自動で走る CI 環境を作ることが、テスト自動化の本来の姿です。
Git の基本が整ったら、ぜひ次の記事に進んでみてください。
実務でよくはまるポイント
⚠️ Git・GitHub ではまりやすいポイント
- user.name・user.email を設定していない
設定なしで commit しようとするとエラーが出ます。git config --global user.nameとgit config --global user.emailを最初に必ず設定しましょう。 - commit をせずに push しようとして
src refspec main does not match anyが出る
git pushは commit が1つもない状態では実行できません。git add → git commitを先に行ってから push してください。 - GitHub への push で認証エラーになる
GitHub ではパスワード認証は廃止されています。ブラウザ認証・GitHub CLI(gh auth login)・Personal Access Token・SSH 鍵のいずれかで認証してください。 - venv を commit してしまった
一度 commit したファイルは .gitignore を追加しても追跡が続きます。git rm -r --cached venv/で追跡を解除してから commit し直す必要があります。 - .env ファイルを commit してしまった
API キーやパスワードを含む .env を GitHub に push すると、公開リポジトリでは全世界に漏洩します。万一 push してしまったら、すぐにキーを無効化して再発行しましょう。 git add .で意図しないファイルまで追加している
commit 前にgit statusで追加されたファイルを確認する習慣をつけましょう。- main ブランチで直接作業してしまう
main に直接 commit・push すると、CI が壊れたりチームに影響が出たりします。作業前に必ずブランチを切る習慣をつけましょう。 - push 前に pull を忘れてコンフリクトが発生する
チームで作業しているとき、push する前にgit pullで最新状態を取り込む習慣が大切です。 - コミットメッセージが曖昧で後から追えない
"fix"や"update"だけのメッセージは数週間後に何を直したか分かりません。"fix: flaky login test due to implicit wait"のように具体的に書きましょう。
よくある質問(FAQ)
GitHub はパスワード認証を廃止しています。以下の方法で解決できます。
- 最も簡単:
gh auth login(GitHub CLI)を実行してブラウザで認証 - トークン認証:GitHub の Settings → Developer settings → Personal access tokens でトークンを発行し、push 時のパスワード欄に入力
- SSH 認証:
ssh-keygenで鍵ペアを生成して GitHub に公開鍵を登録。設定後は最も快適
どちらもリポジトリの「主幹ブランチ」を指しますが、名前が異なります。master は以前の Git のデフォルト名でした。GitHub は2020年以降デフォルトを main に変更したため、新規リポジトリでは main が標準になっています。既存のリポジトリでは master のままの場合もあり、どちらも正しく動作します。チームやプロジェクトのルールに合わせてください。
どちらも Git リポジトリのホスティングサービスで、CI/CD 機能も持っています。GitHub は世界最大のプラットフォームで、オープンソースプロジェクトが多く、GitHub Actions が CI/CD として広く使われています。GitLab はセルフホスト(自社サーバーにインストール)できるのが特徴で、企業の社内環境で利用されることが多いです。テスト自動化の学習には GitHub が情報量・コミュニティともに充実しています。
最初は HTTPS(ブラウザ認証 or GitHub CLI)の方が設定が簡単です。SSH は鍵ペアの生成・登録が必要ですが、一度設定するとパスワード・トークン不要で快適に使えます。毎日 push する環境になったら SSH への移行を検討してください。
機能的にはほぼ同じです。GitHub では「Pull Request(PR)」、GitLab では「Merge Request(MR)」と呼びます。どちらも「このブランチの変更をメインブランチに取り込んでください」というリクエストを出し、レビューを受けてからマージするための仕組みです。
はい、個人利用では無料プランで十分です。プライベートリポジトリ(非公開)も無制限で作成できます。GitHub Actions は無料枠でも利用できますが、無料利用枠はプランや OS によって異なり変更される場合があります。最新情報は GitHub 公式サイトでご確認ください。
git add . と git add -A の違いは何ですか? git add . はカレントディレクトリ以下の変更を追加します。git add -A はリポジトリ全体(削除されたファイルも含む)の変更を追加します。プロジェクトルートから実行する場合は実質同じになります。どちらを使っても問題ありませんが、commit 前に git status で確認する習慣が大切です。
メッセージだけ直したい場合は git commit --amend -m "新しいメッセージ" が最も安全です。
commit 自体を取り消したい場合は git reset --soft HEAD~1 で直前の commit を取り消せます(変更内容は残ります)。
いずれもまだ push していない commit のみ有効です。すでに push した commit の修正は、チーム開発では慎重に行う必要があります。
main にマージ完了した後は削除して問題ありません。git branch -d feature/add-login-test(ローカル)と git push origin --delete feature/add-login-test(リモート)で削除できます。GitHub の Pull Request をマージするときに「Delete branch」ボタンが表示されるので、そこから削除するのが簡単です。
使っても問題ありません。GitHub Desktop や VS Code の Git 統合機能は、視覚的に操作できて初心者には分かりやすいです。ただし、CI/CD のトラブルシューティングや、コマンドラインしか使えない環境(サーバーなど)では結局コマンドが必要になります。基本コマンドを一度覚えておくことを推奨します。
まとめ
| 操作 | コマンド | ポイント |
|---|---|---|
| 初期設定 | git config --global | 名前とメールアドレスを設定(一度だけ) |
| 状態確認 | git status | 迷ったらこれ。何度でも実行 OK |
| ステージング | git add | commit 前に status で確認する習慣を |
| 記録 | git commit -m | メッセージは具体的に書く |
| アップロード | git push | チーム開発では GitHub 側に新しい変更がないか確認してから push する習慣をつける |
| .gitignore | — | venv・.env は最初から除外する |
| ブランチ | git checkout -b | 作業前に必ずブランチを切る |
Git の操作を覚えると、テスト自動化コードの管理が格段に楽になります。次のステップとして、GitHub Actions で push のたびに pytest を自動実行する環境を作ってみてください。それがテスト自動化の本来の形です。
最初はコマンドが多くて大変に感じるかもしれませんが、status → add → commit → push の流れを毎日繰り返すうちに自然に身につきます。

