Git basics are one of the most important skills in modern software development, because Git is a distributed version control system that records every change you make to your code. Whether you work alone or in a team, Git gives you the power to undo mistakes, see who changed what and when, and work in parallel on the same files. In this article we will clearly explain the concepts of repository, staging area, commit and branch, and show each step with real commands.
Core concepts: repository, staging area, commit
When learning Git basics, you first need to settle the vocabulary. Three concepts often get confused:
- Repository: the database that stores your project's entire history, kept in the hidden
.gitfolder. - Working directory: the actual files you are editing right now.
- Staging area (index): an intermediate layer where you choose exactly which changes go into the next commit.
- Commit: a permanently saved snapshot of the staged changes, tagged with a message and a unique identifier (hash).
The flow is: you edit a file → you stage it with git add → you write it to the repository with git commit.
Initializing a new repository and the first commit
When starting a new project, you initialize Git inside the folder. Your first task is to set your identity and create the repository:
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
mkdir myproject
cd myproject
git init
The git init command creates an empty .git repository in the folder. Now let's add a file and check the state:
git status
git add index.html
git add .
git commit -m "Initial commit: project skeleton"
git status shows which files changed and which are staged, and it is the command you will use most. git add . stages all changes; git commit -m finalizes the record with a one-line message. Write meaningful, short messages in the imperative mood (e.g. "Add login form validation").
Reading the history: git log and git status
To see the commits you have made, use git log:
git log
git log --oneline --graph --decorate
--oneline condenses each commit to a single line, while --graph visually draws the branch structure. The short string at the start of each line is that commit's unique identifier (hash), and you can return to any point with it. git status is always the answer to the question "where am I right now?".
Branch and merge: the foundation of parallel work
A branch is a movable pointer that lets you split off from the main code and work independently. When trying a new feature, you work on a separate branch without breaking the main one (usually main):
git branch feature-login
git switch feature-login
# The same thing in older Git versions:
git checkout -b feature-login
Here git switch is the modern, easy-to-read command; git checkout -b both creates the branch and switches to it in one step. After making a few commits on the branch, once you are done you bring the changes back to the main branch with a merge:
git switch main
git merge feature-login
# Clean up the merged branch:
git branch -d feature-login
If two branches change the same lines of the same file in different ways, Git reports a conflict. In that case you open the file, manually fix the sections between the <<<<<<< and >>>>>>> markers, then complete the merge with git add + git commit.
Working with remote repositories: clone, pull, push
Because Git is distributed, code is usually shared on a remote repository such as GitHub or GitLab. To download an existing project:
git clone https://github.com/user/project.git
To connect your own local repository to an existing remote and send it:
git remote add origin https://github.com/user/project.git
git push -u origin main
The daily cycle is simple: use git pull to fetch your teammates' changes, and git push to upload your own commits:
git pull
git push
The -u in the first git push -u origin main links the local branch to the remote branch; after that, a plain git push is enough.
Excluding unwanted files with .gitignore
Dependency folders, build output and secret keys should never enter the repository. You create a .gitignore file in the project root to declare which files should be ignored:
node_modules/
vendor/
.env
*.log
/dist
.DS_Store
An important rule: .gitignore only works for files that are not yet tracked. If you have already committed a file by mistake, you must first untrack it with git rm --cached file.
Frequently Asked Questions
What is the difference between git add and git commit?
git add moves changes into the staging area, effectively saying "I want to save these"; git commit then permanently writes those staged changes to the repository with a message. Without add, a commit records nothing.
Is there a difference between git checkout and git switch?
Both can change branches. git switch is a newer, clearer command designed only for branch operations; git checkout both switches branches and restores files, so it is more complex. Beginners are advised to use git switch.
How do I fix my last commit message?
If you have not pushed yet, you can rewrite the last commit with git commit --amend -m "New message". After pushing, changing history affects your teammates, so be careful.
Want to set up a solid Git and deployment workflow for your project? If you need help with version control, code quality and automation, get in touch with me — let's design a workflow that fits your project together.