Git and GitHub for Beginners: Learn add, commit, push, and Branch Workflows

Once you start writing test automation code, Git and GitHub become essential. Version control, team collaboration, and CI/CD integration all revolve around Git. This guide walks through each command one step at a time, focusing on exactly what test automation engineers need to know first.

💡 Not comfortable with the command line yet?
Starting with GitHub Desktop (free GUI tool) is completely fine. You can get comfortable with Git concepts visually. That said, you’ll eventually need the command line for CI/CD troubleshooting and server environments — so use both in parallel.

📌 Who This Article Is For

✅ Those who have never used Git, or only have a vague idea of how it works

✅ Anyone who wants to share test automation code with their team

✅ Those who want to try GitHub Actions but need to understand Git first

✅ Anyone confused about the difference between add, commit, and push

📖 What You’ll Be Able to Do After This Guide

✔ Install Git and complete the initial configuration

✔ Save your code to GitHub using the add → commit → push workflow

✔ Exclude venv and other unnecessary files using .gitignore

✔ Use branches to make changes safely

✔ Take your first step toward CI/CD with GitHub Actions

I have managed test automation code with Git across multiple projects using Python, Selenium, Playwright, and pytest — with GitHub Actions running CI on every push.
This guide proactively addresses the specific points where beginners get stuck, even when they already know the commands.

✅ Goal of This Guide

Push your test automation code to GitHub successfully
Use .gitignore to exclude venv and __pycache__
Create a branch, make changes, and merge them

Git vs GitHub — What’s the Difference?
① Install Git
1. Windows
2. Mac
② Initial Git Configuration
③ The Core Workflow: add → commit → push
1. Step-by-Step
④ Exclude Unnecessary Files with .gitignore
⑤ Use Branches to Make Changes Safely
⑥ Quick Command Reference
⑦ Next Step: Run CI/CD with GitHub Actions
Common Pitfalls in Git & GitHub
Frequently Asked Questions (FAQ)
Summary

Git vs GitHub — What’s the Difference?

This is the first thing that confuses most beginners. Let’s sort it out.

	Git	GitHub
What it is	A version control tool (software)	A hosting service for Git repositories
Where it lives	Your local machine	The internet (cloud)
Role	Records and manages change history	Shares code with your team and runs CI/CD
Analogy	“A system that tracks every revision of a document”	“A cloud folder where you store and share those documents”

You can’t use GitHub without Git.
The order is: install Git → learn local version control → then connect to GitHub.

① Install Git

Windows

Go to git-scm.com/download/win in your browser, download the installer, and run it.
The default settings are fine for everything. When you reach “Choosing the default editor used by Git,” selecting “Use Visual Studio Code” is handy later on.

Mac

Git is often pre-installed on Mac. Verify it in Terminal:

git --version

If a version number appears, you’re set. If not, install via Homebrew:

brew install git

② Initial Git Configuration

After installing Git, set your name and email address. This links every commit to “who made this change” — you only need to do it once.

# Set your name (matching your GitHub username is convenient)
git config --global user.name "Your Name"

# Set your email (use the address registered on GitHub)
git config --global user.email "your@email.com"

# Verify the settings
git config --list

③ The Core Workflow: add → commit → push

Day-to-day Git work comes down to these three steps.

Command	What it does	Analogy
`git add`	Stage changes (prepare to record)	“Put it in an envelope”
`git commit`	Record the changes locally	“Seal the envelope and file it”
`git push`	Upload to GitHub	“Drop it in the mailbox”

Step-by-Step

1. Initialize a repository (first time only)

# Navigate to your project folder
cd my-test-project

# Initialize a Git repository
git init

Running git init creates a hidden .git folder — Git’s history database.

2. Check the current state

git status

git status shows what’s changed. When in doubt, run this. You can run it as many times as you like.

3. Stage files (add)

# Add a specific file (recommended when you're just starting out)
git add test_sample.py

# Add everything in the current directory (once you're more comfortable)
git add .

💡 Add files individually until you’re comfortable with git add .
git add . is convenient but can accidentally stage files you didn’t mean to include. Start by adding files one at a time like git add test_login.py, and verify with git status before committing.

4. Record the changes (commit)

# Write a commit message with -m
git commit -m "add: login test"

💡 Write commit messages that describe what you actually did
The person reading your commit history next week might be you — or a teammate. "fix" or "update" alone tells nobody anything.

Type	Example message
`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. Push to GitHub (first time)

Create a repository on GitHub (log in at github.com → “New repository”), then connect with these commands:

💡 You need at least one commit before you can push
Running git push with no commits produces error: src refspec main does not match any. Complete steps 3–4 (add → commit) first.

# Register the GitHub repository as "origin" (replace URL with yours)
git remote add origin https://github.com/yourusername/my-test-project.git

# Check your current branch name
git branch
# → "main" displayed: you're good
# → "master" displayed: rename it with the next command
git branch -M main

# Push the main branch to GitHub
git push -u origin main

⚠️ Password authentication is not supported on GitHub
Since 2021, passwords no longer work for GitHub pushes. Use one of these methods:

Browser auth: A browser window opens on the first push asking you to log in to GitHub — the easiest option
Personal Access Token (PAT): Generate a token in GitHub Settings → Developer settings → Personal access tokens, then enter it in the password field
GitHub CLI: GitHub’s official command-line tool (gh). Run gh auth login and a browser window handles authentication automatically
SSH key: Generate a key pair and register the public key in GitHub — the most comfortable option once set up

Browser auth or GitHub CLI is the smoothest starting point for beginners.

From the second push onward, just git push is enough.

④ Exclude Unnecessary Files with .gitignore

.gitignore tells Git which files and folders to leave untracked.
There are certain things you should always exclude in a test automation project.

What to exclude	Why
`venv/`	Recreated per environment; becomes large quickly
`__pycache__/`	Python auto-generated cache; not needed
`.pytest_cache/`	pytest-generated cache; not needed
`.env`	May contain API keys and passwords — never commit this
`*.log`	Log files vary per environment; not needed

Create a .gitignore file in your project root and paste the following:

# .gitignore (for test automation projects)

# ⚠️ Secrets and environment variables (highest priority)
.env
.env.*
*.secret

# Virtual environment
venv/
.venv/

# Python cache
__pycache__/
*.py[cod]
*.pyo

# pytest
.pytest_cache/
.coverage
htmlcov/

# Logs
*.log

# OS-generated files
.DS_Store        # Mac
Thumbs.db        # Windows

# Allure reports
allure-results/
allure-report/

# IDE settings (no need to share with team)
.vscode/
.idea/

⚠️ Create .gitignore before your first commit
Once a file has been committed, adding it to .gitignore does not stop Git from tracking it.
Make creating .gitignore your very first step in any new project.

⑤ Use Branches to Make Changes Safely

A branch is a working copy of your code where you can make changes without touching the main codebase.
Always create a branch before adding or modifying test automation code.

# Check the current branch
git branch

# Create and switch to a new branch (recommended — Git 2.23+)
git switch -c feature/add-login-test
# Older Git versions: git checkout -b feature/add-login-test

# Work, add, commit (normal workflow)
git add .
git commit -m "add: login validation test for valid credentials"

# Push the branch to GitHub
git push -u origin feature/add-login-test

# After finishing, return to main and merge (local merge)
git checkout main
git merge feature/add-login-test

Use prefixes like feature/ (new functionality) and fix/ (bug fix) in branch names so the purpose of the branch is immediately clear.

💡 In real projects, you merge through a Pull Request (PR)
In team development, the standard flow is to create a Pull Request on GitHub after pushing your branch — not merge locally.

① Create a feature branch from main

↓

② add → commit → push (to GitHub)

↓

③ Open a Pull Request on GitHub

↓

④ Team reviews — GitHub Actions runs automated tests

↓

⑤ Approved → merge into main

⑥ Quick Command Reference

Command	What it does
`git status`	Check current state (run this whenever you’re unsure)
`git log --oneline`	View commit history in a compact format
`git diff`	See exactly what changed
`git pull`	Pull the latest changes from GitHub into your local repo
`git clone <URL>`	Copy a GitHub repository to your local machine
`git stash`	Temporarily shelve uncommitted changes
`git reset --soft HEAD~1`	Undo the last commit (keeps your changes)

⑦ Next Step: Run CI/CD with GitHub Actions

Once you’re comfortable with Git and GitHub, the next milestone is using GitHub Actions to run pytest automatically on every push.
Having tests run automatically whenever you push code is one of the best parts of test automation.

# Where to put your GitHub Actions config file
.github/
└── workflows/
    └── test.yml   ← Define your CI pipeline in this YAML file

🚀 Try running pytest automatically with GitHub Actions

Building a CI environment where tests run automatically on every push is what test automation is really about.
Once your Git foundation is solid, head to the next article.

👉 GitHub Actions + Playwright — Building a CI/CD Pipeline

📎 Related Articles

Common Pitfalls in Git & GitHub

⚠️ Watch out for these

user.name and user.email not configured
Attempting to commit without these set produces an error. Run git config --global user.name and git config --global user.email before anything else.
Trying to push before making a commit → src refspec main does not match any
git push requires at least one commit. Run git add → git commit first.
Authentication error when pushing to GitHub
Password authentication is disabled on GitHub. Use browser auth, GitHub CLI (gh auth login), Personal Access Token, or SSH key.
Accidentally committed the venv folder
Once committed, adding venv to .gitignore doesn’t stop tracking. Use git rm -r --cached venv/ to untrack it, then commit again.
Accidentally committed the .env file
Pushing API keys or passwords to a public GitHub repository exposes them to the world. If you push it, invalidate and reissue the keys immediately.
Staging unintended files with git add .
Always run git status before committing to verify what’s been staged.
Working directly on the main branch
Committing and pushing directly to main can break CI or affect your teammates. Always create a branch before starting work.
Forgetting to pull before pushing in team development
In team environments, check whether GitHub has new changes before you push — otherwise the push will be rejected.
Vague commit messages that can’t be traced later
"fix" or "update" alone tells nobody anything. Write something specific like "fix: flaky login test due to implicit wait".

Frequently Asked Questions (FAQ)

Q. I get an authentication error when I try to push to GitHub

GitHub no longer accepts password authentication. Here’s how to fix it:

Easiest: Run gh auth login (GitHub CLI) — a browser window handles authentication
Token auth: GitHub Settings → Developer settings → Personal access tokens → generate a token → enter it in the password field when prompted
SSH: Run ssh-keygen to generate a key pair, then register the public key in GitHub. The most comfortable option once set up

Q. What’s the difference between the main and master branches?

Both refer to the primary branch of a repository — they just have different names. master was Git’s original default. GitHub changed its default to main in 2020, so new repositories use main as standard. Older repositories may still use master — both work fine. Follow your team or project’s convention.

Q. What’s the difference between GitHub and GitLab?

Both are Git repository hosting services with built-in CI/CD. GitHub is the world’s largest platform — home to most open-source projects and widely used with GitHub Actions for CI/CD. GitLab’s standout feature is self-hosting (installing on your own servers), making it popular for corporate on-premises environments. For learning test automation, GitHub has the richer ecosystem and community resources.

Q. Should I use SSH or HTTPS authentication?

Start with HTTPS (browser auth or GitHub CLI) — it’s much easier to set up. SSH requires generating a key pair and registering it with GitHub, but once that’s done it’s the most comfortable long-term option since you never need to enter tokens or passwords. Switch to SSH when you’re pushing daily and want a smoother experience.

Q. Are Pull Requests and Merge Requests the same thing?

Functionally, yes. GitHub calls them “Pull Requests (PR)” while GitLab calls them “Merge Requests (MR)”. Both are a way to say “please review this branch and merge it into the main branch,” with a review process before the merge.

Q. Is GitHub free to use?

Yes — the free plan is more than enough for individual use, including unlimited private repositories. GitHub Actions also has a free tier, but the limits depend on your plan and OS and may change over time. Check the official GitHub site for current pricing.

Q. What’s the difference between git add . and git add -A?

git add . stages changes in the current directory and below. git add -A stages all changes in the entire repository, including deleted files. When run from the project root, they’re effectively the same. Either works fine — the important habit is running git status to verify what’s staged before committing.

Q. How do I fix a commit I just made?

To fix the message only, use git commit --amend -m "corrected message" — the safest approach.
To undo the commit entirely (while keeping your changes), use git reset --soft HEAD~1.
Both only work on commits that haven’t been pushed yet. Editing a pushed commit in a team environment requires care.

Q. When should I delete a branch?

Once a branch is merged into main, it’s safe to delete. Use git branch -d feature/add-login-test (local) and git push origin --delete feature/add-login-test (remote). The easiest way is clicking the “Delete branch” button shown after merging a Pull Request on GitHub.

Q. Can I use a GUI tool like GitHub Desktop?

Absolutely. GitHub Desktop and VS Code’s built-in Git integration are great for visualizing what’s happening. That said, CI/CD troubleshooting and server environments will eventually require the command line. Learning the basic commands once is recommended — then use whatever feels right day to day.

Summary

Operation	Command	Key point
Initial config	`git config --global`	Set name and email — do this once before anything else
Check state	`git status`	Run this whenever you’re unsure. Safe to run anytime
Stage	`git add`	Verify with status before committing
Record	`git commit -m`	Write specific, descriptive messages
Upload	`git push`	In team development, check GitHub for new changes before pushing
.gitignore	—	Exclude venv and .env from the very start
Branch	`git switch -c`	Always create a branch before starting work

Learning Git makes managing your test automation code dramatically easier. The natural next step is building a GitHub Actions environment where pytest runs automatically on every push — that’s what test automation is really about.

The commands may feel like a lot at first, but status → add → commit → push becomes second nature quickly with daily practice.