Version control with git for beginners

TL;DR:

• Git records snapshots of your project called commits, so you can see what changed and go back.

• A branch is a separate line of work. You make changes on it, then merge it back into the main line.

• A good commit message is short, in the imperative, and says what the change does.

You edit an essay, save it as essay_final.doc, then essay_final2.doc, then essay_really_final.doc, and a week later you cannot remember which one has the paragraph you deleted. Version control solves exactly this problem for code. Git is the most widely used tool for it, and it works on any folder of text files.

The idea in plain words

Git keeps a history of your project. Each time you reach a good point, you save a commit, a snapshot of the files plus a short message about what changed. Because every commit is stored, you can see what changed, when, and go back to an earlier version.

A branch is a separate line of commits. You can try something on a branch without disturbing the main line, and when you are happy with it you merge the branch back. Git also works well with other people: each person works on a branch, and merges bring the work together.

Why the staging step exists

Git has an in-between step called staging. git add chooses which changes go into the next snapshot, and git commit records them. This lets you change five files and commit only the two that belong to one idea, so each commit tells a clear story.

Worked example: one change on a branch, then a merge

These commands are for a terminal with git installed. Your default branch may be called main or master, depending on your setup; this example uses main.

git init
echo "Line one" > notes.txt
git add notes.txt
git commit -m "Add notes file"

git switch -c add-line-two
echo "Line two" >> notes.txt
git commit -am "Add second line"

git switch main
git merge add-line-two
git log --oneline

Step by step.

1. git init turns the current folder into a git repository. (If your git defaults to another branch name, run git branch -m main after your first commit.)

2. echo "Line one" > notes.txt creates a file. git add notes.txt stages it, and git commit -m saves the first snapshot with a message.

3. git switch -c add-line-two creates a new branch and moves onto it. From now on, commits go on this branch.

4. echo "Line two" >> notes.txt adds a line to the file. git commit -am stages every change to files that git already tracks and commits them in one go.

5. git switch main returns to the main branch. If you look at notes.txt now, it has only Line one, because the second line lives on the other branch.

6. git merge add-line-two brings the branch's commits into main. Because main had no new commits of its own, git simply moves main forward, which it reports as a fast-forward.

7. git log --oneline lists the commits: the newest, Add second line, then Add notes file.

Now notes.txt on main holds both lines. If main had also changed while you worked on the branch, git would create a new merge commit joining the two lines of work. If both changed the same lines, git would stop and ask you to resolve the conflict by choosing what the text should say.

Writing a good commit message

• Say what the commit does, in the imperative: 'Add second line', not 'Added' or 'stuff'.

• Keep the first line short, about 50 characters is a common guide.

• One idea per commit. If you need the word 'and', you may want two commits.

• Explain why, if it is not obvious, on a following line.

Do not commit secrets: Passwords, access keys and private files should never go into a repository. Once committed, they stay in the history even if you delete the file later, and anyone who can see the history can read them.

Undoing safely: look before you leap

Before you do anything drastic, read the status. git status tells you which branch you are on, which files changed and which are staged. It is the command to run when you are unsure what state things are in, and it never changes anything.

If you edited a file and want to see exactly what changed before committing, git diff prints the lines added and removed. Commit small and often: a small commit is easy to understand and easy to undo, while a huge one that mixes five ideas is hard to review. The git switch command needs a reasonably recent version of git. On older versions, git checkout does the same job.

How to check your answer

• git status shows what is changed, staged, and which branch you are on.

• git log --oneline lists the commits so you can check that yours are there.

• git diff shows what has changed since the last commit.

• After a merge, look at the file itself to confirm it has the content you expect.

Common mistakes

• Forgetting to commit before switching branches, which can carry changes to the wrong place or cause a conflict.

• Committing with a message like 'fix' or 'update' that tells you nothing a month later.

• Working directly on main for everything, so every experiment is mixed with finished work.

• Using git commit -a and expecting it to add new files. It only stages files git already tracks.

• Panicking at a merge conflict. It only means two changes touched the same lines, and you choose the result.

Where you will use it next

Git is how teams share code, how open-source projects take contributions, and how you can recover from an experiment gone wrong. It pairs naturally with writing small functions, as in writing your first function, and with reading what went wrong when something breaks, as in how to read an error message.

Frequently asked questions

Is git the same as GitHub?

No. Git is the tool on your computer. GitHub is a website that hosts git repositories so people can share them.

Can I undo a commit?

Yes, in several ways, depending on whether you have shared it. A beginner-safe option is git revert, which adds a new commit that undoes an earlier one.