Git for Beginners: The Concepts and Commands You'll Actually Use
Git is one of the tools you'll almost certainly use in a software engineering job, whatever the language or framework. Unfortunately, many beginners put off learning Git because it looks complicated — full of terms like commit, branch, merge, and rebase.
The good news: for everyday work, you only need to understand a few core concepts and a handful of commands. This article covers both.
What is Git?
Git is a version control system — a system that records the history of changes to files over time. With Git you can:
- see what changed, when, and by whom,
- go back to a previous version if something breaks,
- work on several features in parallel without them interfering,
- collaborate with others on the same codebase.
GitHub is different from Git. GitHub is a service that hosts Git repositories online and provides collaboration features such as Pull Requests, issues, and code review.
Core concepts to understand
Repository
A repository (repo) is a project folder whose history is tracked by Git. Inside it is a hidden .git folder that stores the entire history.
Commit
A commit is a save point containing a set of changes along with a message explaining them. Think of it like a checkpoint in a game: you can view and return to any checkpoint.
Staging area
Before committing, changes are first selected into the staging area. This lets you choose which changes go into a single commit, so each commit stays focused.
Branch
A branch is a separate line of development. The main branch is usually called main. When working on a new feature, you create your own branch so main stays stable.
Merge
A merge combines changes from one branch into another — for example from a feature branch into main once the feature is done.
Remote
A remote is a copy of the repository somewhere else, usually on GitHub. You push to send commits to the remote and pull to fetch changes from it.
Basic commands for everyday use
Setting your identity (once)
git config --global user.name "Your Name"
git config --global user.email "email@example.com"
Starting or getting a repository
# create a new repository in the current folder
git init
# copy an existing repository from GitHub
git clone https://github.com/username/repo-name.git
Checking status
git status
This is the command you'll use most. It shows which files changed, which are staged, and which branch you're on. When in doubt, run git status.
Saving changes
# choose the file to commit
git add src/app.ts
# or choose all changes
git add .
# create a commit with a message
git commit -m "Add email validation to the signup form"
Working with branches
# create a new branch and switch to it
git switch -c feature/email-validation
# switch to another branch
git switch main
# list branches
git branch
Syncing with GitHub
# send the branch to GitHub
git push -u origin feature/email-validation
# fetch the latest changes from GitHub
git pull
Viewing history
git log --oneline
A simple workflow for one feature
Here's the flow many teams use, from start until a feature is ready for review:
- Make sure
mainis up to date:git switch mainthengit pull. - Create a feature branch:
git switch -c feature/feature-name. - Write code, then commit in small steps with clear messages.
- Push the branch to GitHub:
git push -u origin feature/feature-name. - Open a Pull Request on GitHub so your changes can be reviewed.
- Once approved, the Pull Request is merged into
main.
Steps 5 and 6 are covered in full in What Is a Pull Request?.
Writing good commit messages
Commit messages are documentation for your future self and your teammates. A few habits that help:
- Explain what changed and why, not just "update" or "fix".
- One commit, one purpose. Don't mix a bug fix with a new feature.
- Keep the first line short. Extra detail can go on the following lines.
Examples of unhelpful and better messages:
| Unhelpful | Better |
|---|---|
fix | Fix error when email is empty on the login form |
update code | Move validation logic into a separate function |
wip | Add order list endpoint (no pagination yet) |
Common beginner mistakes and how to fix them
Committing directly to main
Get into the habit of always creating a branch for every change. This trains the habit teams use and keeps main safe.
Commits that are too big
Hundreds of lines changed in one commit are hard to understand and hard to review. Commit more often with smaller changes.
Being afraid of conflicts
A conflict happens when two changes touch the same lines. Git marks the conflicting parts; your job is to choose the correct version, save the file, and commit. Conflicts are a normal part of teamwork, not a sign you did something wrong.
Committing secrets to the repository
Never commit files containing passwords, API keys, or tokens. Use a .gitignore file to exclude files such as .env.
The best way to learn Git: keep using it
Git is learned fastest through regular use. Keep every project — however small — in a Git repository, push it to GitHub, and get used to working with branches. Once the basic commands feel natural, you're ready for collaboration through Pull Requests and code review.
Conclusion
Git looks complicated because of all its terms, but everyday work only requires a few core concepts — repository, commit, branch, merge, remote — and a handful of commands. The key is building the right workflow habits from the start.
If you want to practice Git and Pull Requests in conditions close to real work, see the software engineer job simulation at KodingCamp, where every change goes in through a Pull Request and gets reviewed. An overview of the full workflow is in The Software Engineer Workflow.