Git and GitHub basics you need before a hackathon

You do not need to understand Git properly to survive a hackathon. You need about eight commands and one rule about not overwriting your teammate's work. Here is the minimum that actually gets you through a weekend.

Why this matters at a hackathon specifically

Two reasons beyond the obvious. First, judges check commit history to confirm the work happened during the event — a repository with one commit at hour 35 looks bad even when it is honest. Second, committing regularly is the only thing standing between you and losing six hours of work when something crashes at 3 AM.

The mental model, in one paragraph

Git saves snapshots of your project. A commit is one snapshot with a note attached. Your commits live on your machine until you push them to GitHub, which is just a server that holds a copy. When a teammate pushes their work, you pull to get it. That is 90% of it.

One-time setup

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Use the same email as your GitHub account, otherwise your commits will not be linked to your profile — which matters when you are showing this repository to someone later.

Starting a project

If you are creating it: make the repository on GitHub first (with a README ticked), then:

git clone https://github.com/yourname/your-repo.git
cd your-repo

If a teammate already made it: same git clone command with their URL. Ask them to add you under Settings → Collaborators first, or you will be able to read but not push.

The loop you will repeat all weekend

git add .
git commit -m "Add login form"
git push

That is it. Do this every hour or two, not once at the end.

Before you start working each session, and especially before you push:

git pull

This brings in whatever your teammates have pushed since you last looked.

The eight commands that cover almost everything

• git status — what has changed. Run this constantly; it is free and it tells you what state you are in.
• git add . — stage all your changes for the next commit.
• git commit -m "message" — save a snapshot with a note.
• git push — send your commits to GitHub.
• git pull — get your teammates' commits.
• git log --oneline — see the history compactly.
• git checkout -b feature-name — make a new branch and switch to it.
• git checkout main — switch back to the main branch.

The one rule about not destroying your teammate's work

Pull before you push. Always.

If you push without pulling, Git will refuse and print a wall of text. That refusal is Git protecting you, not Git being broken. The fix is almost always:

git pull
# fix any conflicts, then
git add .
git commit -m "Merge"
git push

Merge conflicts, without the panic

A conflict happens when you and a teammate changed the same lines. Git marks it in the file like this:

<<<<<<< HEAD
your version of the line
=======
their version of the line
>>>>>>> main

To fix it: open the file, delete the three marker lines, keep whichever version is correct (or combine them by hand), save, then git add . and commit. That is genuinely all a merge conflict is — Git asking you which version you meant.

The way to have fewer of them: work on different files where possible, and pull often.

Branches — do you need them?

For a two-person team over one weekend, honestly, you can work on main together and pull often. It is simpler and it works.

For three or more people, branches are worth it. Each person works on git checkout -b their-feature, pushes, and opens a pull request on GitHub to merge into main. It costs ten minutes to learn and saves you from stepping on each other.

Things that will bite you

• Committing secrets. API keys and passwords in a public repository get scraped by bots within minutes. Put them in a .env file and add .env to .gitignore before your first commit.
• Committing node_modules. Add it to .gitignore. Nobody wants a 400 MB repository.
• A private repository at submission time. Judges cannot see it. Make it public before you submit, and check in a logged-out browser.
• Force-pushing to fix something. git push --force can erase a teammate's commits permanently. If you are reaching for it during a hackathon, ask a mentor first.

If everything goes wrong

The nuclear option that has saved many hackathon projects: copy your entire project folder somewhere safe, delete the broken clone, re-clone fresh from GitHub, and copy your changed files back in. It is inelegant and it works, and at hour 32 elegance is not the priority.

What to have set up before the event

• Git installed, git --version returning something
• A GitHub account with authentication already working
• One test repository you have successfully pushed to

Getting authentication working for the first time during a hackathon is a genuinely miserable hour. Do it the week before.