Learning Path

Git & GitHub

A complete guide to version control with Git and collaboration with GitHub. From your first commit to advanced branching strategies, pull requests, and team workflows used by millions of developers worldwide.

9 modules.Beginner to Advanced

Module 1: What is Git?

Understanding version control and why every developer needs it

Git is a distributed version control system created by Linus Torvalds in 2005 to manage Linux kernel development. It tracks changes to files over time, allowing you to recall any previous version, see who changed what, and collaborate with others without overwriting each other's work.

Unlike centralized systems (SVN, Perforce), every developer has a complete copy of the repository history on their local machine. This means you can commit, branch, and merge entirely offline, and synchronize with others when ready.

Git Architecture: Three Areas

Module 2: Essential Commands

The commands you will use every day

git init

Create a new Git repository in the current directory. This creates a hidden .git folder that stores all version history.

git clone <url>

Download a complete copy of a remote repository to your local machine, including all history and branches.

git add <file>

Move changes from the working directory to the staging area. Use git add . to stage all changed files.

git commit -m "message"

Save staged changes as a permanent snapshot in the repository history. Each commit gets a unique SHA hash.

git status

Show which files are modified, staged, or untracked. The most frequently used command for understanding your current state.

git log --oneline

View the commit history. The --oneline flag shows each commit on a single line for a compact overview.

git diff

Show the exact changes between your working directory and the last commit. Use git diff --staged to see staged changes.

git push origin main

Upload your local commits to a remote repository (like GitHub). origin is the remote name, main is the branch.

git pull

Download changes from the remote repository and merge them into your current branch. Combines fetch + merge.

Module 3: Branching and Merging

Work on features independently without affecting the main codebase

Branches let you diverge from the main line of development to work on features, fixes, or experiments in isolation. When your work is ready, you merge it back. Git branches are lightweight, just a pointer to a commit, so creating them is nearly instantaneous.

Branching Workflow

git branch feature/login

Create a new branch named feature/login. This does not switch to it.

git checkout -b feature/login

Create and immediately switch to a new branch. Shorthand for branch + checkout.

git merge feature/login

Merge the specified branch into your current branch. First checkout main, then merge.

git branch -d feature/login

Delete a branch after merging. Use -D to force-delete an unmerged branch.

Module 4: GitHub Collaboration

Pull requests, code review, issues, and team workflows

GitHub is a platform built on top of Git that adds collaboration features: pull requests for code review, issues for tracking work, actions for automation, and a web interface for browsing code and history. With over 100 million developers (GitHub, 2024), it is the standard platform for open-source and commercial software development.

Pull Request Workflow

Pull Requests

A pull request proposes changes from one branch to another. Team members review the code, leave comments, request changes, and approve before merging. PRs create a documented history of every change and the reasoning behind it.

Issues

Issues track bugs, feature requests, and tasks. They can be assigned to team members, labeled by category, linked to PRs, and organized into milestones and projects. Every issue gets a unique number for reference in commits.

GitHub Actions

Automate workflows triggered by events (push, PR, schedule). Common uses include running tests on every push, building and deploying on merge to main, linting code, and publishing packages. Defined in YAML files in .github/workflows/.

Forks and Open Source

Forking creates your own copy of someone else's repository. You make changes in your fork, then submit a pull request back to the original. This is how open-source contributions work on GitHub.

Module 5: Branching Strategies

How teams organize branches for different release workflows

Simple

GitHub Flow

One long-lived branch (main). Create feature branches, open PRs, merge after review. Every merge to main is deployable. Best for continuous deployment and small teams.

1 branchFeature PRsContinuous deploy

Structured

Git Flow

Two long-lived branches (main and develop). Feature branches merge to develop. Release branches cut from develop, merge to both main and develop. Hotfix branches for urgent production fixes. Best for scheduled releases.

main + developRelease branchesVersioned releases

Module 6: Advanced Git

Power user techniques for complex workflows

git rebase main

Replay your branch's commits on top of the latest main. Creates a linear history instead of merge commits. Never rebase commits that have been pushed and shared with others.

git stash

Temporarily save uncommitted changes and revert to a clean working directory. Use git stash pop to restore them later. Useful when you need to switch branches mid-work.

git cherry-pick <hash>

Apply a single commit from another branch to your current branch. Useful for backporting a specific fix without merging an entire branch.

git bisect

Binary search through commit history to find which commit introduced a bug. Git checks out commits for you to test, narrowing down the culprit in O(log n) steps.

git reset --soft HEAD~1

Undo the last commit but keep the changes staged. --mixed unstages them too. --hard discards changes entirely (dangerous).

git reflog

View the log of every position HEAD has been at. Your safety net for recovering "lost" commits after a bad reset or rebase. Git keeps everything for at least 30 days.

Module 7: Configuration and Best Practices

Setting up Git properly and writing good commit messages

The .gitignore File

The .gitignore file tells Git which files and directories to ignore. Common entries include build outputs (dist/, build/), dependencies (node_modules/, venv/), environment files (.env), and OS files (.DS_Store). GitHub provides template .gitignore files for every language and framework.

Commit Message Convention

Good commit messages follow a consistent format. The most common convention uses a type prefix: feat: for new features, fix: for bug fixes, docs: for documentation, refactor: for code restructuring. The subject line should be under 72 characters, written in imperative mood ("Add login page" not "Added login page"). A blank line followed by a body provides additional context when needed.

SSH vs HTTPS Authentication

HTTPS uses a personal access token for authentication. SSH uses a key pair (public + private key) stored on your machine. SSH is generally preferred because it does not require entering credentials for every push. Generate a key with ssh-keygen, add the public key to your GitHub account under Settings > SSH Keys.

Module 8: Resolving Merge Conflicts

What happens when two branches change the same code, and how to fix it

Merge conflicts occur when two branches modify the same lines in a file. Git cannot automatically decide which version to keep, so it marks the conflict in the file and asks you to resolve it manually.

Conflict Resolution Flow

Key Takeaway

Conflicts are normal and expected in team collaboration. The best way to minimize them is to keep branches short-lived, pull from main frequently, and communicate with teammates about which files you are working on. Modern editors (VS Code, IntelliJ) provide visual conflict resolution tools that make the process much easier than editing conflict markers by hand.

Module 9: CI/CD with GitHub Actions

Automate testing, building, and deployment on every push

Continuous Integration (CI) automatically builds and tests your code every time you push. Continuous Deployment (CD) automatically deploys successful builds to production. Together, CI/CD eliminates manual, error-prone release processes and gives teams confidence that every merge is production-ready.

GitHub Actions is GitHub's built-in CI/CD platform. Workflows are defined in YAML files stored in .github/workflows/. Each workflow is triggered by events (push, pull request, schedule) and runs on GitHub-hosted runners (Linux, macOS, Windows) or self-hosted machines.

CI/CD Pipeline Flow

Workflow triggers

Events that start a pipeline: push, pull_request, schedule (cron), workflow_dispatch (manual), or release.

Jobs and steps

A workflow contains jobs that run in parallel by default. Each job has sequential steps that run commands or use pre-built actions from the marketplace.

GitHub Actions Marketplace

Thousands of reusable actions: actions/checkout, actions/setup-node, docker/build-push-action. Compose them into custom pipelines.

Secrets and environments

Store API keys and credentials as encrypted secrets. Environments add approval gates and deployment protection rules for production.

Matrix builds

Test across multiple versions simultaneously (Node 18, 20, 22 or Python 3.10, 3.11, 3.12). Catches compatibility issues early.

Artifacts and caching

Cache dependencies (actions/cache) to speed up builds. Upload artifacts (test reports, binaries) for download or use by later jobs.