Git and GitHub Basics for Beginners

Git and GitHub Are Not the Same Thing

This is the single most common confusion for students starting their first group project or final year project: Git is the version control tool — software that runs on your computer and tracks every change to your files over time. GitHub is a website that hosts Git repositories online, adding collaboration features (pull requests, issue tracking, project boards) on top of what Git itself does. You could use Git without ever touching GitHub; GitHub without Git underneath it wouldn't exist. GitLab and Bitbucket are competing hosts built the same way, on the same underlying Git.

What Version Control Actually Solves

Before Git, the standard student workaround was a folder full of project_final.zip, project_final_v2.zip, project_ACTUALLY_final.zip. That approach breaks the moment two people edit the same file, or you need to find which change introduced a bug from three days ago. Git solves both: it tracks every change as a distinct, recoverable snapshot, and it has a defined process for merging changes from multiple people without one person's work silently overwriting another's.

The Core Workflow, Command by Command

1. Turn a folder into a Git repository:

git init

2. Check what's changed:

git status

3. Stage the files you want to save:

git add filename.py
git add .          # stage everything changed

4. Commit — save a snapshot with a message describing the change:

git commit -m "Add login validation function"

5. Push your commits to GitHub:

git push origin main

6. Pull down changes others have made:

git pull origin main

That six-command loop — status, add, commit, push, pull — covers the vast majority of a student's day-to-day Git use.

Branches: Working Without Breaking Main

A branch is an independent line of development — changes made on a branch don't affect main (the primary line, usually what's graded or deployed) until you explicitly merge them:

git checkout -b feature/user-authentication

This creates and switches to a new branch in one command. Work, commit as usual, and when the feature is ready:

git checkout main
git merge feature/user-authentication

For group projects, the practical benefit is real: each teammate works on their own branch without their half-finished code breaking the version everyone else is building on.

Merge Conflicts: What They Actually Mean

A merge conflict happens when Git can't automatically decide how to combine two changes to the same lines of a file — it is not an error you did something wrong, it's Git correctly refusing to guess. A conflicted file looks like this:

<<<<<<< HEAD
def calculate_total(items):
    return sum(item.price for item in items)
=======
def calculate_total(items):
    return sum(item.price * item.quantity for item in items)
>>>>>>> feature/user-authentication

Everything between <<<<<<< HEAD and ======= is your current branch's version; everything between ======= and >>>>>>> is the incoming branch's version. Resolving it means editing the file to keep the correct logic (here, likely the quantity-aware version), deleting the conflict markers themselves, then committing the resolved file.

Mistakes That Cost Students Real Work

• Committing directly to main on a group project without pulling first. This is the single most common source of "someone's work disappeared" — always git pull before starting new work on a shared branch.
• Never committing until the project is "done." One giant commit at the deadline has no history to fall back on if something breaks. Commit in small, working increments — each one a recoverable checkpoint.
• Committing files that shouldn't be tracked — build artifacts, node_modules/, IDE config, credentials. A .gitignore file listing these patterns prevents them from ever being staged in the first place.
• Force-pushing (git push --force) on a shared branch. This overwrites teammates' history on the remote — it has legitimate uses on your own private branch, but on a shared branch it can silently erase someone else's committed work.

A Realistic Vocabulary Checklist

When Git Problems Become the Actual Blocker

Version control mistakes have a specific failure signature: the code itself might be fine, but a bad merge, a lost branch, or a commit history that's genuinely tangled can stall a project for hours in a way that has nothing to do with programming skill. If a group project's Git history is in a state nobody on the team can untangle, or a final year project needs its repository structured properly before a supervisor reviews it, the programming help service and project development service both work with developers who can recover a broken repository state or set one up correctly from the start.