Learn the model first: commits are snapshots, branches are pointers, and remotes are copies. Then use Git daily on your own projects, practise a team workflow with branches and pull requests, and break things on purpose, such as merge conflicts, so you learn to recover calmly.
What people tell me
I use Git, but honestly I only know add, commit and push, and I copy other commands from the internet when something goes wrong. When I get a merge conflict or my branch is behind, I panic and sometimes delete the folder and clone again. I know I will need Git in any job and that working in a team is different, but tutorials either stay too basic or throw dozens of commands at me. How do I actually learn it properly?
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Git makes sense once you understand the model: commits are snapshots, branches are pointers, remotes are other copies.
- Use Git on every project, with small commits and clear messages, until the basics are automatic.
- Practise a team workflow alone: branches, pull requests, reviews and merges.
- Create merge conflicts on purpose so they stop being scary.
- Learn the few recovery commands that undo mistakes safely.
Why copying commands never feels solid
Git feels confusing when you learn it as a list of commands, because the commands only make sense in terms of what they do to the underlying model. Once you understand that model, most commands become obvious, and you can reason your way out of problems instead of searching for a magic fix.
The model in five ideas
- A commit is a snapshot of your whole project at a moment, plus a message and a pointer to the previous commit.
- History is a chain of commits. Each one points back to its parent.
- A branch is just a named pointer to one commit. Creating a branch is cheap because nothing is copied.
- HEAD is where you are right now, usually pointing to a branch.
- A remote, such as GitHub, is another copy of the repository. Push sends your commits there; fetch and pull bring theirs to you.
With these five ideas, a merge is "combine two lines of history", a rebase is "replay my commits on top of another point", and a detached HEAD is "you are looking at a commit, not a branch". Git, properly: the model behind the commands goes deeper and is worth reading slowly.
The commands that matter, grouped by job
| Job | Commands to know well |
|---|---|
| Save work | status, add, commit, diff |
| See history | log --oneline --graph, show |
| Work on something new | switch -c (or checkout -b), branch |
| Combine work | merge, rebase (once you are comfortable) |
| Share work | push, fetch, pull |
| Undo safely | restore, revert, reset --soft, stash |
| Find lost work | reflog |
You do not need more than this for your first year at work. Learn these properly and look the rest up when you need it.
A learning order that works
- Use Git on every project, even solo ones. Commit small, coherent changes several times a day.
- Write proper commit messages. A short summary line saying what and why. How to Write a Git Commit Message explains the widely used conventions.
- Read your history. Run
git log --oneline --graphoften, so you see the chain of commits in your head. - Use branches for every feature, even when you are the only developer.
- Open pull requests to yourself on GitHub. Write a description, review your own diff, then merge.
- Break things on purpose in a practice repository: create conflicts, reset commits, lose work and recover it with reflog.
- Contribute to someone else's project. Forking, syncing with upstream and responding to review comments is the real team workflow.
How to create and fix a merge conflict on purpose
This exercise removes most of the fear:
- Create a new repository with a file containing a few lines.
- Create a branch, change line 2, commit.
- Switch back to the main branch, change the same line 2 differently, commit.
- Merge your branch into main. Git reports a conflict.
- Open the file, read the conflict markers, decide the correct final text and remove the markers.
- Add the file and commit the merge.
Do this three or four times with slightly different situations. Next time it happens on a real project, you will recognise it as a normal, fixable event.
A four-week plan
| Week | Focus | Output |
|---|---|---|
| 1 | The model and daily basics on your current project | 20 or more small commits with clear messages |
| 2 | Branches and pull requests on GitHub, even solo | Three features, each merged through a pull request with a description |
| 3 | Conflicts, undoing and recovery in a practice repository | You have resolved conflicts and recovered "lost" commits using reflog |
| 4 | A small contribution to an open-source project or a friend's repository | One pull request opened, reviewed and updated after feedback |
For a first outside contribution, Contributing to a Project (GitHub Docs) walks through forking and pull requests step by step, and the free Open source roadmap shows how to find good first issues.
Git versus GitHub
These are easy to mix up. Git is the version control tool that runs on your machine. GitHub is a hosting service built around Git, adding pull requests, reviews, issues and actions. Learn Git first, because the concepts are the same whichever hosting service your future team uses.
Common mistakes
- Giant commits named "update" or "final". They make history useless to you and to reviewers.
- Working directly on main for everything. Branches are free; use them.
- Deleting and recloning after a problem. You lose the chance to learn, and sometimes you lose work. Try
git statusand reflog first. - Using force push without understanding it. On shared branches it can overwrite other people's work.
- Committing secrets. Keep keys in environment files that are ignored by Git.
If you are still stuck
For how Git fits into the wider journey from pull request to live code, read What actually happens between your pull request and production. If you want help setting up a real workflow for your projects, join Sefism: learning is free, joining gives you credits and your first roadmap is free. As a member you can ask your own question whenever Git gets you stuck.
Was this answer helpful?
Read next
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.