Git basics for beginners: commits, branches, merging and undoing mistakes

TUREFF• •0

Git keeps the history of your project, lets you try ideas without fear of breaking what works, and makes working with others possible. Most of its power comes from a dozen commands, and once you understand the ideas behind them the rest makes sense. This guide covers those ideas and a simple routine for daily use.

Repositories

A repository (repo) is a project folder that Git is tracking. It contains your files plus a hidden folder that stores the full history. You create one by running git init inside a folder, or copy an existing one with git clone followed by its address.

The three places your changes live

Working directory: the files as you are editing them.
Staging area: the changes you have chosen to include in your next snapshot. You add them with git add followed by the file name (or a dot for everything).
Commits: saved snapshots in the history, created with git commit.

Run git status often. It tells you which files have changed, which are staged and what to do next. Run git diff to see exactly what changed in each line.

Commits

A commit is a snapshot of the project with a message describing it. Make commits small and focused: one fix, one feature step, one clean-up. Small commits are easier to understand, review and undo. View the history with git log (add the oneline option for a compact view).

Writing good commit messages

Start with a short summary line, around 50 characters, in the imperative: "Fix login redirect loop", not "fixed stuff".
If needed, leave a blank line and explain why the change was made, not just what. The code already shows what.
Avoid messages like "update", "wip" or "changes"; you will not know what they meant in a month.

Branches

A branch is a separate line of work. The main branch (usually called main) holds the stable version. When you start something new, create a branch with git switch and the create option followed by a name, such as fix-login-redirect. You can then commit freely without affecting main. Switch between branches with git switch and the branch name. See them all with git branch. Branches are cheap in Git, so use one for every piece of work, however small.

Merging

When the work is ready, switch back to main and run git merge followed by your branch name. Git combines the histories. If both branches changed the same lines differently, you get a merge conflict: Git marks the clashing sections in the file with arrow-like markers. Open the file, keep the right version (or combine them), delete the markers, then add and commit the result. Conflicts look alarming at first but are just Git asking you to choose.

Remotes: sharing your work

A remote is a copy of the repository on a server such as GitHub, GitLab or Bitbucket. The default one is usually called origin.

git push sends your commits to the remote.
git pull fetches others' commits and merges them into your branch.
git fetch downloads changes without merging, so you can look first.

On teams, branches are usually merged through a pull request (or merge request), where others review the changes before they reach main.

A simple daily workflow

Start on main and run git pull to get the latest changes.
Create a branch for your task.
Edit, check git status, add and commit in small steps.
Push your branch and open a pull request.
After it is merged, switch back to main, pull, and delete the old branch.

Undoing mistakes safely

Discard changes to a file you have not staged: git restore followed by the file name. This throws away your edits, so be sure.
Unstage a file: git restore with the staged option and the file name. Your edits stay.
Fix the last commit message or add a forgotten file: stage the file and run git commit with the amend option. Only do this before pushing.
Undo a commit that is already pushed: git revert followed by the commit's ID creates a new commit that reverses it. This is the safe choice on shared branches because it does not rewrite history.
Find something you thought you lost: git reflog lists where your branches have pointed recently, so you can often recover "deleted" commits.

Be careful with git reset using the hard option and with force-pushing: both can throw away work, and force-pushing a shared branch can overwrite your teammates' commits.

Keep these out of Git

Add a .gitignore file listing things that should not be tracked: dependencies, build output, log files and, above all, passwords, API keys and other secrets. Once a secret is committed, it stays in the history even after you delete the file. Ask about a Git error you keep hitting or share the command that finally made Git click for you in the comments.