Git & GitHub — Complete Developer Guide

Git Configuration

Before using Git for the first time, you must tell it who you are. These details are attached to every commit you make. The --global flag applies the setting to all repositories on your machine.

bash

# Set your username and email globally
git config --global user.name "Your GitHub Username"
git config --global user.email "your@email.com"

# Verify all current settings
git config --list

# Remove credentials if needed
git config --global --unset user.name
git config --global --unset user.email

Pro TipUse the same email address that is registered with your GitHub account so commits are linked to your profile correctly.

How to Push Code to GitHub

This is the foundational workflow for publishing a local project to a remote GitHub repository for the first time.

bash

# Step 1 — Initialize a local git repository
git init

# Step 2 — Stage all files for the first commit
git add .

# Step 3 — Create the first commit
git commit -m "Initial commit"

# Step 4 — Rename default branch to main (avoids conflicts)
git branch -M main

# Step 5 — Link local repo to the remote GitHub repo
git remote add origin "https://github.com/username/repo-name.git"

# Step 6 — Push and set the upstream tracking branch
git push -u origin main

NoteThe -u flag sets the upstream so that all future pushes from this branch only need git push — no need to specify the remote and branch again.

AuthenticationOn your first push, GitHub may open a browser window for authentication. Complete it using your GitHub credentials or a Personal Access Token (PAT).

Git Workflow

Understanding the four stages of Git is essential. Every file in your project lives in one of these states at any given time.

Working Directory

→

git add

→

Staging Area

→

git commit

→

Local Repo

→

git push

→

Remote Repo

Stage	Description
Untracked	New file Git has never seen before
Tracked (Modified)	Git knows the file but it has unsaved changes
Staged	Changes marked and ready to be committed
Committed	Snapshot saved permanently in local repo history

bash

# Check current state of your working directory
git status

Git Ignore

The .gitignore file tells Git which files and folders to never track — such as environment files, dependencies, build outputs, and secrets.

.gitignore

# Ignore all CSS files
*.css

# Ignore a specific file
app.js

# Ignore an entire folder and all its contents
passwords/

# Common real-world entries
node_modules/
.env
dist/
.DS_Store
*.log

TipVisit gitignore.io to auto-generate a .gitignore for any language, framework, or IDE.

Git Restore

Use git restore to discard changes in the working directory or to move files out of the staging area — all before making a commit.

bash

# Discard uncommitted changes in a specific file
git restore filename.js

# Discard all uncommitted changes in the working directory
git restore .

# Move a staged file back to the working directory (unstage it)
git add app.js # file is now staged
git restore --staged app.js # file is now back to modified/unstaged

WarningRestoring a file in the working directory is irreversible. The local changes will be permanently discarded.

Git Revert Command

When changes have already been committed or pushed to the remote repo, use git revert. It creates a new commit that undoes the target commit — keeping your history intact and safe.

bash

# View the full commit log
git log

# View compact one-line log to find the hash
git log --oneline

# Revert a specific commit by its hash code
git revert a1b2c3d

Why use Revert?Unlike git reset, revert is safe to use on public/shared branches because it does not rewrite history. It adds a new undo-commit on top.

Git Reset Command

Git reset moves the HEAD pointer back to a previous commit, erasing commit history after that point. Use with extreme caution — especially on shared branches.

bash

# Reset back to a specific commit (mixed mode by default)
git reset a1b2c3d

# Soft — moves HEAD back but keeps changes staged
git reset --soft HEAD~1

# Mixed (default) — unstages changes, keeps them in working dir
git reset --mixed HEAD~1

# Hard — destroys all changes in the commit completely
git reset --hard HEAD~1

Flag	Staged Area	Working Directory
--soft	Changes kept staged	Unchanged
--mixed	Changes unstaged	Unchanged
--hard	Cleared	Cleared — changes lost forever

Dangergit reset --hard permanently deletes working directory changes. Never use on a branch shared with teammates.

Git Aliases

Aliases let you define short custom commands for frequently used Git operations. Configure them globally in .gitconfig or locally inside a single repository.

~/.gitconfig

# Open .gitconfig in terminal editor
nano ~/.gitconfig

# Add aliases under [alias] section
[user]
name = "Your Name"
email = "your@email.com"

[alias]
st = status
lg = log --oneline
co = checkout
br = branch
cm = commit -m

bash

# Set a local alias for just the current repo
git config alias.b branch

# Now both of these do the same thing
git status
git st

Git Branches

Branches allow you to work on features, bug fixes, or experiments in isolation — keeping the main branch clean and stable until work is finalized and merged.

bash

# ── CREATE & SWITCH ──────────────────────────

# Method 1 — create then switch
git branch feature-login
git checkout feature-login

# Method 2 — create and switch in one command
git checkout -b feature-login

# Method 3 — modern syntax (Git 2.23+)
git switch -c feature-login

# ── LIST & NAVIGATE ───────────────────────────

# List all local branches
git branch

# Switch back to main
git switch main

# ── MERGE ─────────────────────────────────────

# Push feature branch to remote first
git push -u origin feature-login

# Switch to main and merge
git switch main
git merge feature-login

# ── DELETE ────────────────────────────────────

# Delete a branch (safe — won't delete if unmerged)
git branch -d feature-login

# Force delete a branch
git branch -D feature-login

Git Amend Command

Rather than creating a new commit every time you tweak the same feature, use --amend to fold the new changes into the most recent commit. Keeps your commit history clean and professional.

bash

# Step 1 — make changes to the file
# Step 2 — stage them
git add .

# Step 3 — amend the previous commit with new changes + updated message
git commit --amend -m "feat: add login form with validation"

# Amend commit message only (without changing any files)
git commit --amend --no-edit

ImportantNever amend a commit that has already been pushed to a shared remote branch. It rewrites history and will cause conflicts for other collaborators.

Git Clone Command

Always clone using the git clone command rather than downloading a ZIP. The ZIP strips out the .git folder, losing all commit history and branch information.

bash

# Clone a repo into a new folder (named after repo)
git clone https://github.com/username/repo-name.git

# Clone into the CURRENT directory (no extra folder created)
git clone https://github.com/username/repo-name.git .

# Clone a specific branch only
git clone --branch feature-login https://github.com/username/repo-name.git

# Clone using SSH (faster & no password prompts)
git clone git@github.com:username/repo-name.git

Git Pull vs Git Fetch

When collaborating, you need to bring remote changes into your local repository. Understanding the difference between these two commands prevents unexpected merge conflicts.

bash

# ── GIT FETCH (Safer approach) ────────────────

# Download all changes from remote — does NOT merge
git fetch origin

# Check status — you'll see "1 commit behind origin/main"
git status

# Review the incoming changes before merging
git log origin/main

# Merge after reviewing
git merge origin/main

# ── GIT PULL (Convenience approach) ───────────

# Fetches AND merges in one step — can cause conflicts
git pull origin main

Command	Downloads Changes	Auto-Merges	Safer For Teams
git fetch	Yes	No	✅ Yes
git pull	Yes	Yes	⚠️ With care

Deploy a Static Site on GitHub Pages

GitHub Pages lets you host HTML, CSS, and JS projects for free directly from a repository — no server required.

bash

# Inside your project directory
git init
git add .
git commit -m "Initial deploy"
git branch -M main
git remote add origin "https://github.com/username/repo-name.git"
git push -u origin main

After pushing, go to the GitHub repository → Settings → Pages → under Source, select Deploy from a branch → choose main → Save. GitHub will build and deploy your site automatically.

Live URLYour site will be live at https://username.github.io/repo-name/ within a minute or two.

Deploy a Vite React App to GitHub Pages

Vite React apps need a slightly different setup to deploy correctly since GitHub Pages serves from a subdirectory path.

bash

# Install the gh-pages deployment package
npm install --save-dev gh-pages

vite.config.js

import { defineConfig } from 'vite'

export default defineConfig({
base: '/repo-name/', // Must match your GitHub repo name exactly
})

package.json

{
"homepage": "https://username.github.io/repo-name",
"scripts": {
"dev": "vite",
"build": "vite build",
"deploy": "gh-pages -d dist"
}
}

bash

# Build the production-ready dist/ folder
npm run build

# Push the dist/ folder to the gh-pages branch
npm run deploy

Then go to Settings → Pages, select the gh-pages branch as the source. GitHub handles the CI/CD pipeline automatically.

Git Diff Command

Git diff lets you compare changes between your working directory, staging area, commits, and remote branches — a powerful tool for reviewing your work before committing.

bash

# Changes in working directory (not yet staged)
git diff

# Changes in the staging area (staged but not committed)
git diff --staged

# Compare local branch vs remote branch
git diff origin/main

# Compare two specific commits
git diff a1b2c3d e4f5g6h

# Show only the names of changed files
git diff --name-only

# Show changes highlighted word by word in color
git diff --color-words

Skip the Git Staging Area

If you are confident about your changes and want to skip the git add step, you can commit tracked files directly using the -a flag.

bash

# Stage AND commit all tracked modified files in one step
git commit -a -m "fix: update header styles"

# Commit a specific file directly (skip staging)
git commit ./src/index.js -m "refactor: clean up index file"

NoteThe -a flag only works on files Git is already tracking. Brand new (untracked) files still need to be staged with git add first.

Git Stash Command

Stash is a temporary storage area for work-in-progress changes when you need to switch context quickly — like jumping to another branch to fix a bug — without committing half-done work.

bash

# Save current working directory changes to the stash
git stash

# Save stash with a descriptive label
git stash push -m "WIP: login form validation"

# List all stashed entries
git stash list

# Apply the most recent stash (keeps it in the stash list)
git stash apply

# Apply a specific stash by index
git stash apply stash@{2}

# Apply the most recent stash AND remove it from the list
git stash pop

# Delete all stashed entries permanently
git stash clear

Real-World UseYou're halfway through a feature when a critical bug is reported. Run git stash, fix the bug on a new branch, then git stash pop to resume your work exactly where you left off.

How to Collaborate on a GitHub Repo

For private or team repositories where everyone is an invited collaborator:

bash

# ── TEAM LEADER ──────────────────────────────
# 1. Create remote repo on GitHub
# 2. Go to Settings → Collaborators → Add people

# ── TEAM MEMBER ──────────────────────────────
# 1. Accept email invite from GitHub
# 2. Clone the shared repo
git clone https://github.com/org/repo-name.git

# 3. Create a feature branch for your work
git switch -c feature/your-task

# 4. Make changes, stage and commit
git add .
git commit -m "feat: add user dashboard"

# 5. Push your branch to remote
git push -u origin feature/your-task

# ── TEAM LEADER (pulling updates) ────────────
git fetch origin # review changes first
git merge origin/feature/your-task # then merge
# OR simply:
git pull origin main

How to Create and Merge Pull Requests

For contributing to open-source projects or repos you are not a collaborator on, the workflow goes through a Fork instead of cloning directly.

bash

# ── CONTRIBUTOR ──────────────────────────────
# 1. Click "Fork" on GitHub — creates a copy under your account

# 2. Clone YOUR fork (not the original)
git clone https://github.com/your-username/repo-name.git

# 3. Create a dedicated branch for your changes
git checkout -b fix/broken-nav-link

# 4. Make your changes, then stage and commit
git add .
git commit -m "fix: correct broken navigation link in header"

# 5. Push branch to YOUR forked repo
git push -u origin fix/broken-nav-link

# 6. Go to GitHub → your fork → "Compare & pull request"
# Write a clear description of what you changed and why

The original project owner receives a notification and can Comment, Request Changes, or Approve and Merge the pull request through GitHub's UI.

Good PR EtiquetteKeep PRs focused on a single change. Write a clear title, explain the problem you solved, and reference any related issues (e.g., Fixes #42).

GitHub Actions Introduction

GitHub Actions is a built-in CI/CD (Continuous Integration / Continuous Deployment) platform inside GitHub. It automates everything from running tests when you push code, to building and deploying your application — all without leaving GitHub.

Feature	Description
Built-in CI/CD	No third-party tools needed
Event-driven	Triggered by push, pull request, schedule, etc.
Marketplace	Thousands of pre-built Actions to reuse
Scalable	Runs in isolated VMs (runners)
Secure	Secrets management built in

GitHub Actions Workflow

A workflow is an automated process defined in a YAML file stored in the .github/workflows/ directory. Indentation is critical in YAML — always use spaces, never tabs.

Event Occurs

→

Workflow Starts

→

Jobs Run (parallel)

→

Steps Execute

→

Done ✓

Component	Role
Event	The trigger — push, PR, schedule, manual, etc.
Job	A group of steps that run inside one runner
Step	A single task inside a job (run a command or use an Action)
Runner	Virtual Machine that executes the workflow

Create Your First GitHub Action

Create a new repo → go to Actions tab → click set up a workflow yourself. This creates a YAML file at .github/workflows/main.yml.

.github/workflows/main.yml

# Name of this workflow
name: My First Workflow

# Trigger: run on every push to the main branch
on:
push:
branches:
- main

# Define the jobs
jobs:
greet:
runs-on: ubuntu-latest # the runner VM image

steps:
- name: Print Hello World
run: echo "Hello from GitHub Actions!"

- name: Show current directory
run: pwd

- name: List files
run: ls -la

Marketplace ActionsInstead of writing every step yourself, use community Actions from the GitHub Marketplace via the uses: keyword — for example actions/checkout@v4 to check out your code.

Schedule GitHub Actions Workflow

Use the cron scheduler to run workflows automatically on a time-based schedule — useful for nightly builds, data syncs, or automated reports.

.github/workflows/scheduled.yml

name: Scheduled Job

on:
schedule:
# Cron format: minute hour day month weekday
# 0 0 * * * → runs at midnight every day
- cron: "0 0 * * *"

jobs:
run-script:
runs-on: ubuntu-latest

steps:
- name: Run scheduled task
run: echo "Automated task running on schedule"

Cron Expression	Meaning
0 0 * * *	Every day at midnight
0 9 * * 1-5	Every weekday at 9:00 AM
0 /6 * *	Every 6 hours
0 0 1 * *	First day of every month

Disable a WorkflowGo to Actions → your workflow → three-dot menu → Disable workflow to pause it without deleting the YAML file.

Automate Angular Build Process

Automatically build your Angular app on every push to main, ensuring the codebase always compiles without errors.

.github/workflows/angular-build.yml

name: Build Angular App

on:
push:
branches:
- main

jobs:
build-angular-app:
runs-on: ubuntu-latest

steps:
- name: Checkout repository code
uses: actions/checkout@v4

- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '22.x'

- name: Install dependencies
run: npm install

- name: Build Angular app
run: npm run build

Next StepAfter verifying the build works, add a deploy step using actions/deploy-pages@v4 or push the build output to a hosting platform automatically.

Artifacts and Caching for Next.js

Caching saves the node_modules folder between workflow runs so dependencies don't reinstall every time, dramatically speeding up builds. Artifacts save the build output files so you can download or deploy them later.

.github/workflows/nextjs-build.yml

name: Next.js Build with Caching and Artifacts

on:
push:
branches:
- main

jobs:
build:
runs-on: ubuntu-latest

steps:
- name: Checkout repository
uses: actions/checkout@v4

- name: Set up Node.js with npm cache
uses: actions/setup-node@v4
with:
node-version: '22.x'
cache: 'npm' # caches node_modules between runs

- name: Install dependencies
run: npm install

- name: Build Next.js app
run: npm run build

- name: Upload build as artifact
uses: actions/upload-artifact@v4
with:
name: nextjs-build
path: out/ # Next.js static export output folder

Why Cache?A cold install of node_modules can take 60–90 seconds. With caching enabled, repeat runs take under 5 seconds for the dependency step.

Generate SSH Keys for GitHub

SSH keys replace username/password authentication with a cryptographic key pair. It's faster, more secure, and lets you connect without entering credentials on every push. This is a one-time setup per machine.

bash

# Step 1 — Generate a new SSH key pair using ed25519 algorithm
ssh-keygen -t ed25519 -C "your@email.com"
# Press Enter to accept default file location and set an optional passphrase

# Step 2 — Display your public key (copy this output)
cat ~/.ssh/id_ed25519.pub

# Step 3 — Start the SSH agent in the background
eval "$(ssh-agent -s)"

# Step 4 — Add your private key to the SSH agent
ssh-add ~/.ssh/id_ed25519

# Step 5 — Go to GitHub → Settings → SSH and GPG Keys
# → New SSH Key → Paste the public key → Save

# Step 6 — Test the connection
ssh -T git@github.com

# Now clone and push using the SSH URL
git clone git@github.com:username/repo-name.git

Algorithm	Security	Recommendation
ed25519	Strongest, smallest key	✅ Use this
rsa 4096	Strong, widely supported	✅ If ed25519 unavailable
dsa	Outdated	❌ Avoid

Multiple GitHub AccountsGenerate a separate key pair for each account and configure ~/.ssh/config to route the correct key to each host automatically.

★

Bonus — Git Tags

Tags mark specific points in history as significant — typically used to mark release versions like v1.0.0. Unlike branches, tags don't move when new commits are made.

bash

# Create a lightweight tag at the current commit
git tag v1.0.0

# Create an annotated tag (recommended — includes metadata)
git tag -a v1.0.0 -m "Release version 1.0.0"

# List all tags
git tag

# Push a specific tag to remote
git push origin v1.0.0

# Push ALL tags to remote
git push --tags

# Delete a tag locally
git tag -d v1.0.0

# Delete a tag from remote
git push origin --delete v1.0.0

★

Bonus — Git Rebase

Rebase is an alternative to merge that rewrites commit history to create a linear, clean timeline. It moves your branch's commits on top of another branch as if they were written there from the beginning.

bash

# You're on feature/login and want to bring in latest main
git switch feature/login
git rebase main

# If conflicts occur: resolve them, then continue
git rebase --continue

# Abort the rebase and return to previous state
git rebase --abort

# Interactive rebase — edit, squash, or reorder last 3 commits
git rebase -i HEAD~3

	Merge	Rebase
History	Preserves all merges	Linear & clean
Safety	Safe on shared branches	Avoid on public branches
Best for	Team collaboration	Local cleanup before PR

Golden Rule of RebaseNever rebase commits that have been pushed to a shared remote branch. It rewrites history and causes serious conflicts for your team.

★

Bonus — Git Cherry-pick

Cherry-pick lets you pick a specific commit from one branch and apply it to another — without merging the entire branch. Extremely useful in DevOps and hotfix scenarios.

bash

# Find the commit hash you want to copy
git log --oneline feature/payments

# Switch to the branch that needs the fix
git switch main

# Apply the specific commit to this branch
git cherry-pick a1b2c3d

# Cherry-pick multiple commits
git cherry-pick a1b2c3d e4f5g6h

# Cherry-pick without committing (apply changes but don't auto-commit)
git cherry-pick --no-commit a1b2c3d

Common Use CaseA critical bug is fixed on a develop branch but the fix needs to go live on main immediately — without merging all of develop. Cherry-pick exactly that one commit onto main.