Git for Beginners: The Handful of Commands You Actually Need

Imagine writing a long document and saving copies as final.docx, final_v2.docx and final_REAL_final.docx. Now imagine ten people doing that to the same document at once.

Git solves exactly that problem for code. It records the history of your project, lets many people work in parallel, and makes it safe to experiment. Once you understand the model, the commands stop being magic.

• A repository (repo) is your project folder plus its full history.
• A commit is a snapshot of your files at a moment, with a message describing the change.
• A branch is a separate line of work. The main one is usually called main.
• A remote is a copy of the repo hosted elsewhere, such as GitHub. Git and GitHub are not the same: Git is the tool, GitHub is a website that hosts Git repos.

Think of commits as save points in a game. You can always return to one.

Tell Git who you are. These details appear in every commit.

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

Either start a new repo in a folder:

git init

or copy an existing one:

git clone https://github.com/owner/project.git

This is 90% of Git.

git status                 # what changed?git add file.js            # stage a file for the next commitgit add .                  # or stage everything that changedgit commit -m "Add login form validation"git push                   # send commits to the remote

Git has a middle step called the staging area. git add puts changes into it, and git commit saves only what is staged. This lets you commit related changes together, even if you've edited several things.

To see what you're about to commit:

git diff            # unstaged changesgit diff --staged   # staged changes

A commit message is a note for your future self and your team.

• Write in the imperative: "Fix crash when cart is empty", not "fixed stuff".
• Keep the first line under about 70 characters.
• Make one logical change per commit.

Small, frequent commits make problems easier to find. This pairs well with the process in how to debug any bug, where git bisect relies on a clean history.

git log --oneline          # a short list of commitsgit log --oneline --graph  # with branch structuregit show a1b2c3d           # what one commit changed

A branch lets you build a feature without affecting main.

git switch -c add-search      # create and move to a new branch# ...edit, add, commit...git switch main               # go back to maingit merge add-search          # bring the work into maingit branch -d add-search      # delete the finished branch

Why this matters: main stays working, while the feature grows on its own branch. If the feature goes badly, you throw the branch away.

1. Pull the latest main.
2. Create a branch for your task.
3. Commit as you go.
4. Push the branch.
5. Open a pull request (PR) on GitHub so teammates can review.
6. After approval, merge it.

git switch maingit pullgit switch -c fix-checkout-bug# work and commitgit push -u origin fix-checkout-bug

A conflict happens when two branches changed the same lines. Git can't decide which is right, so it asks you.

Open the file and you'll see markers:

<<<<<<< HEADconst price = base + tax;=======const price = base + tax + shipping;>>>>>>> add-shipping

1. Decide what the final code should be.
2. Delete the markers and keep the correct code.
3. Run git add file.js, then git commit.

Conflicts are normal in team work. Smaller, more frequent merges reduce them.

Some files should never go into Git: dependencies, build output, local settings and, above all, secrets.

Create a .gitignore file:

node_modules/.envdist/.DS_Store

If you commit a password or API key by mistake, deleting it in the next commit does not remove it from history. Treat it as compromised and rotate it.

Most Git panic comes from not knowing which undo to use.

Be careful with git reset --hard and git push --force. They can destroy work. If you aren't sure, make a backup branch first:

git branch backup-before-reset

• Run git status before and after anything unusual.
• Pull before you start work each day.
• Don't commit large files or generated files.
• Keep branches short-lived.
• Review your own diff before pushing.

AI assistants can explain Git errors well, but never run a destructive command you don't understand. Paste the error text and ask what it means, then check against the Git docs. Guidance on using assistants well is in using AI at work.

Git is the version control tool on your computer. GitHub is a hosting service and collaboration platform for Git repositories. GitLab and Bitbucket are alternatives.

Merge keeps history as it happened. Rebase rewrites your branch to sit on top of the latest main, giving a straighter history. As a beginner, use merge. Learn rebase later, and never rebase commits others have pulled.

You've checked out a specific commit instead of a branch. You can look around, but new commits might be lost. Run git switch main to return, or create a branch to keep your work.

GUIs, including those in VS Code, are fine. But learning the basic commands helps you understand what the GUI does and fix problems.

Create a small repo, make commits, branch, deliberately create a conflict and resolve it. An hour of this beats a day of reading.

Commands shown work with current versions of Git. Check git help <command> for details.