Git and GitHub Complete Tutorial

Git and GitHub are the backbone of modern software collaboration — nearly every professional developer uses them daily. This complete tutorial takes you from the core idea of version control through the everyday commands and collaborative workflows you need to work confidently on any team.

Git vs GitHub: Clearing Up the Confusion

Beginners often use these terms interchangeably, but they are different things.

• Git is a version control system — a tool that runs on your computer and tracks changes to your files over time. It works entirely offline.
• GitHub is a cloud platform for hosting Git repositories, collaborating with others, reviewing code, and managing projects. It is one of several such platforms alongside GitLab and Bitbucket.

Git is the engine; GitHub is a place to park and share what the engine produces. You can use Git without GitHub, but not the other way around.

Why Version Control Matters

Without version control, developers resort to folders named “final,” “final_v2,” and “final_actually_final.” Git replaces that chaos with a complete, navigable history of every change. It lets you experiment safely, revert mistakes, and understand exactly who changed what and why.

For teams, Git is indispensable. Multiple people can work on the same codebase simultaneously, and Git intelligently merges their work together while flagging genuine conflicts for a human to resolve.

Initial Setup

After installing Git, configure your identity once so your commits are properly attributed:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

To start tracking a project, navigate to its folder and initialize a repository:

git init

This creates a hidden .git folder where Git stores the entire history. Your ordinary files are unchanged; Git simply begins watching them.

The Core Workflow: Add, Commit, Push

Git works in three conceptual areas: your working directory (files you edit), the staging area (changes you have marked for the next snapshot), and the repository (committed history). The everyday cycle looks like this:

git status              # see what has changed
git add file.txt        # stage a specific file
git add .               # stage everything
git commit -m "Add login feature"   # save a snapshot
git push                # send commits to GitHub

A commit is a permanent snapshot with a message describing the change. Write clear, meaningful commit messages — your future self and teammates will thank you. “Fix bug” is useless; “Fix crash when email field is empty” is helpful.

Branching: Work Without Fear

Branches are Git’s superpower. A branch is an independent line of development where you can build a feature or fix a bug without touching the stable main code. When your work is ready, you merge it back.

git branch feature-login      # create a branch
git checkout feature-login    # switch to it
# or do both at once:
git checkout -b feature-login

# after making commits, merge back:
git checkout main
git merge feature-login

Branching lets teams work in parallel. Each person develops on their own branch, and the main branch stays clean and deployable at all times.

Connecting to GitHub

To collaborate, you push your local repository to GitHub. Create an empty repository on GitHub, then connect and push:

git remote add origin https://github.com/username/repo.git
git branch -M main
git push -u origin main

To work on an existing project, you clone it — downloading the full repository with its entire history:

git clone https://github.com/username/repo.git

Once connected, git push uploads your commits and git pull downloads changes others have made.

Pull Requests and Collaboration

The heart of GitHub collaboration is the pull request (PR). Instead of merging your branch directly, you open a PR proposing your changes. Teammates review the code, leave comments, request changes, and approve. Only then is the branch merged.

The typical team workflow looks like this:

1. Create a feature branch from main.
2. Make commits and push the branch to GitHub.
3. Open a pull request describing what you changed and why.
4. Teammates review; you address feedback with more commits.
5. Once approved, merge the PR and delete the branch.

This process catches bugs early, spreads knowledge across the team, and keeps the main branch trustworthy.

Handling Merge Conflicts

When two people change the same lines of a file, Git cannot decide automatically and reports a merge conflict. This sounds scary but is routine. Git marks the conflicting sections in the file:

<<<<<<< HEAD
your version of the line
=======
their version of the line
>>>>>>> feature-branch

You edit the file to keep the correct result, remove the marker lines, then stage and commit. The key is to stay calm, read both versions, and choose the right combination.

Undoing Mistakes Safely

One of Git’s greatest gifts is that almost nothing is truly permanent — if you know the right command, you can recover from most mistakes. Knowing your options reduces the fear that makes beginners hesitant.

• Discard uncommitted changes — git restore file.txt reverts a file to its last committed state.
• Unstage a file — git restore --staged file.txt removes it from the staging area without losing your edits.
• Undo a pushed commit safely — git revert <commit> creates a new commit that reverses a previous one, preserving history.
• Amend the last commit — git commit --amend lets you fix a commit message or add a forgotten file before pushing.

Be cautious with commands that rewrite history, like git reset --hard, especially on branches others share. As a rule, prefer revert for anything already pushed, and save history-rewriting commands for local, unpushed work. When in doubt, commit your current state first — a commit is a safety net you can always return to.

Popular Team Workflows

As teams grow, they adopt conventions for how branches and merges are organized. You do not need to master all of them, but recognizing the common patterns helps you fit into any team.

• Feature branch workflow — every change happens on its own branch and merges via a pull request. Simple and widely used.
• GitHub Flow — a lightweight model where the main branch is always deployable and short-lived branches merge frequently. Ideal for continuous deployment.
• Git Flow — a more structured model with dedicated branches for features, releases, and hotfixes. Suited to projects with scheduled releases.

Most modern teams favor simpler workflows like GitHub Flow because they encourage small, frequent merges and reduce the pain of long-lived branches. Whatever your team chooses, the underlying Git commands are the same — the workflow is just an agreement about how to use them consistently.

How Git Thinks: Snapshots, Not Differences

A surprising number of Git’s confusing behaviours become obvious once you understand its core mental model. Many tools track changes as a series of differences — the edits made to each file over time. Git works differently: each commit is a complete snapshot of your entire project at that moment, not a list of changes. When a file has not changed between commits, Git simply points to the previous identical version rather than storing it again, which keeps this approach remarkably efficient.

This snapshot model explains why branching is so cheap and fast in Git. A branch is nothing more than a lightweight, movable pointer to one particular commit. Creating a branch does not copy your files; it just creates a new pointer. Switching branches simply moves you to a different snapshot. Once you internalize that commits are snapshots and branches are pointers to them, operations like merging and rebasing stop feeling like magic and start feeling logical.

git log --oneline --graph --all

That single command draws your commit history as a graph, showing how branches diverge and merge. Running it regularly builds an intuition for the shape of your project’s history, which is one of the fastest ways to become genuinely comfortable with Git rather than just memorizing commands.

Stashing, Tagging, and Everyday Power Tools

Beyond the core add-commit-push cycle, a few extra commands smooth over common real-world situations. Stashing lets you temporarily shelve uncommitted work when you need to switch context quickly — for example, to fix an urgent bug on another branch — without making a messy half-finished commit.

git stash            # shelve your current changes
git checkout main    # switch away and do other work
git stash pop        # come back and restore your changes

Tags mark specific commits as significant, most often to label released versions. Unlike branches, tags do not move; they permanently point at one commit, making them ideal for marking milestones you may need to return to.

git tag v1.0.0
git push origin v1.0.0

Two more everyday tools are worth adding to your vocabulary. git diff shows exactly what you have changed before you stage or commit it, which is a great habit to build so you never commit something by accident. And git blame reveals who last changed each line of a file and in which commit — invaluable when you are trying to understand why a piece of code exists. None of these are advanced or intimidating, but knowing they exist means you reach for the right tool instead of working around Git awkwardly.

Best Practices and Common Commands

• Commit often, in small logical chunks — small commits are easier to review and revert.
• Write descriptive commit messages — explain the “why,” not just the “what.”
• Use a .gitignore file — keep secrets, dependencies, and build artifacts out of the repository.
• Pull before you push — integrate others’ changes to avoid unnecessary conflicts.
• Never commit passwords or API keys — once pushed, they are effectively public.

Other commands worth knowing: git log to view history, git diff to see changes, and git revert to safely undo a commit.

Frequently Asked Questions

Do I need to learn command-line Git or is a GUI enough? GUIs are helpful, but knowing the command line makes you far more capable and unblocks you when a GUI falls short. Learn the core commands even if you use a GUI daily.

What is the difference between fetch and pull? git fetch downloads changes without applying them; git pull fetches and merges them into your current branch in one step.

Is GitHub free? Yes, GitHub offers free public and private repositories, with paid plans for advanced team and security features.

Can I undo a commit? Yes. Use git revert to safely create a new commit that undoes a previous one, or git reset for local history changes before you have pushed.

Start Committing Today

Git and GitHub feel awkward for a few days and then become second nature. The best way to learn is to use them on a real project: initialize a repo, make commits, push to GitHub, and open a pull request. Within a week the workflow will feel automatic and you will never want to code without it.

Ready to build something worth versioning? Explore our guides on the Python roadmap, Docker, and launching a SaaS product — and subscribe to the free AmritSparsha newsletter for weekly, practical lessons on coding and collaboration.