In this post I will explain how to set up and use the git. We’ll explore how to get started with Git, from setup to making your first commit.
Table of contents
Open Table of contents
Introduction to Git
In the world of modern software development, Git
is the backbone of collaboration and version control. Created by Linus Torvalds in 2005, Git is a distributed version control system
that lets you track changes to your code, collaborate with teammates, roll back to previous versions, and maintain clean, organized histories of your projects.
Whether you’re a solo developer working on side projects or part of a large engineering team, Git helps you:
-
Track
every change made to your codebase -
Collaborate
without overwriting others’ work -
Revert
to earlier versions if something breaks -
Experiment
safely with new features using branches
It’s fast, efficient, and works locally, giving you full control even without internet access. Once you’re familiar with Git, pushing your changes to platforms like GitHub
, GitLab
, or Azure DevOps
becomes second nature.
Set Up Git in Your Local System
Before you can start version-controlling your projects with Git, you need to set it up on your local machine. This step ensures your commits are properly attributed and that your local environment is ready to push and pull code from remote repositories like GitHub, GitLab, or Azure DevOps.
Step 1: Install Git
Depending on your operating system:
Windows: Download the installer from git-scm.com and follow the setup wizard. It’s recommended to select “Git from the command line and also from 3rd-party software” when prompted.
macOS: Run the following command in Terminal:
xcode-select --install
Alternatively, use Homebrew:
brew install git
Linux (Ubuntu/Debian):
sudo apt update
sudo apt install git
Step 2: Configure Git User Details
Run the following commands in your terminal to set your name and email — this is what gets attached to each commit:
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
You can verify your settings using:
git config --global --list
Step 3: Set Up Default Branch Name (Optional but Recommended)
Since Git 2.28, you can customize your default branch name (e.g., main instead of master):
git config --global init.defaultBranch main
Cloning a Repository
Once Git is set up on your local system, the next step is to clone a repository. Cloning means you’re making a local copy of a remote Git repository (hosted on platforms like GitHub, GitLab, or Azure DevOps), so you can start working on it locally.
🔹 What Does “Cloning” Do?
When you clone a repository, Git:
-
Downloads all files, folders, and commit history
-
Sets up a link to the remote repository (usually named origin)
-
Creates a working directory where you can edit files, commit changes, and push updates
🔹 Syntax
git clone <repository-url>
For example:
git clone https://github.com/your-username/your-repo-name.git
This will create a folder named your-repo-name in your current directory.
🔹 Steps to Clone a Repository
-
Go to the GitHub/Azure DevOps repo you want to clone.
-
Click on the “Code” button and copy the HTTPS or SSH link.
-
Open your terminal or Git Bash.
-
Navigate to the directory where you want to clone the project:
cd path/to/your/folder
Run the git clone command with the copied URL:
git clone https://github.com/your-username/your-repo-name.git
Working with Git – Add, Commit & Push
Once you’ve cloned the repository and made some changes locally — like adding new files or modifying existing ones — it’s time to track those changes, commit them, and push
them to your remote repository. Before that, let’s also learn how to create a branch
to safely work on your changes without affecting the main codebase.
Creating & Switching to a New Branch
It’s a best practice to create a new branch for any feature or bug fix instead of working on the main branch directly.
git checkout -b your-branch-name
This command does two things:
-
Creates a new branch called your-branch-name
-
Switches to it immediately
To verify you’re on the right branch:
git branch
The active branch will have an asterisk (*) next to it.
Stage Files to Be Committed
Git tracks changes in three stages:
-
Working Directory – where you edit files
-
Staging Area – where you prepare files for commit
-
Repository – where committed files are stored
After making changes or adding new files, stage them with:
git add filename
Or to stage all changed files:
git add .
Commit the Changes
Now that the files are staged, you need to save a snapshot using a commit:
git commit -m "Your descriptive commit message"
Your message should explain what and why you changed something. For example:
git commit -m "Add login form with validation"
Push the Changes to Remote Repository
Finally, push your branch and commits to the remote repository:
git push origin your-branch-name
This sends your code to the remote repo under the branch your-branch-name. On platforms like GitHub or Azure DevOps, you can now raise a Pull Request (PR) to merge it into the main branch after review.
Switching Between Branches
To switch to an existing branch:
git checkout branch-name
To see a list of all branches:
git branch
Handling Merge Conflicts and Force Push
Once your code is pushed to a remote branch and you’re ready to merge it into the main branch (or any target branch), you might encounter something called a merge conflict. This typically happens when:
-
Two people have modified the same part of a file on different branches
-
You’re merging branches that have diverged significantly
-
You have made local changes that conflict with the remote
Let’s understand how to handle it gracefully.
What is a Merge Conflict?
Git tries to auto-merge changes when you run:
git merge branch-name
But if Git can’t decide which change to keep, it raises a merge conflict and marks the file. You’ll see something like this inside the file:
<<<<<<<<<<<< HEAD
This is your local version
=======
This is the version from the other branch
>>>>>>> branch-name
You need to manually edit the file, resolve the differences, and remove the <<<<<<<, =======, and >>>>>>> markers. Then:
git add conflicted-file
git commit
That commit completes the merge.
Common Merge Commands 1. Merge a Feature Branch into main
git checkout main
git pull origin main
git merge your-feature-branch
If there are conflicts, resolve them as mentioned above.
2. Abort a Merge (if needed)
git merge --abort
This cancels the merge and brings you back to the last stable state.
When to Use —force Push
Normally, when you push to a remote branch:
git push origin branch-name
Git checks that your local history is compatible with the remote. If you rebase or reset your branch, Git might reject your push due to divergent histories.
You’ll see an error like:
! [rejected] branch-name -> branch-name (non-fast-forward)
To override this, you can use:
git push --force origin branch-name
This forces
your local branch to replace the remote version.
⚠️ Use —force with extreme caution
— it rewrites history and can erase other contributors’ changes if you’re not careful.
Safer Alternative: —force-with-lease
If you must force push, consider this safer command:
git push --force-with-lease origin branch-name
It force-pushes only if the remote branch hasn't changed
since your last pull — reducing the risk of overwriting someone else’s work.
Reverting Changes from a Git Repository
Mistakes happen — maybe you committed a wrong file or deployed something prematurely. Thankfully, Git offers several ways to revert changes, depending on what you want to undo:
- Undo Last Commit (Keep the changes locally)
If you accidentally committed something and want to uncommit but keep your changes in the working directory:
git reset --soft HEAD~1
- Undo Last Commit (Discard everything)
This will remove the last commit and discard all changes:
git reset --hard HEAD~1
- Revert a Commit (Safe for shared branches)
This creates a new commit that undoes the changes from a specific commit:
git revert <commit-hash>
Use this if the commit has already been pushed to a remote branch and you’re working with others.
- Remove a File from Git but Keep Locally
If you want Git to forget a file but not delete it:
git rm --cached <filename>
Merge vs Rebase: What’s the Difference?
Both merge and rebase are used to integrate changes from one branch into another — but how they do it is what sets them apart.
Merge
git merge brings the changes from one branch into another with a merge commit. It preserves the history of both branches.
git checkout main
git merge feature-branch
-
Easy and safe for teams.
-
History stays intact.
-
May create extra merge commits.
Rebase
git rebase moves or “replays” your changes onto another branch, creating a linear history.
git checkout feature-branch
git rebase main
-
Cleaner history.
-
Ideal for solo feature branches before merging.
-
Risky on shared branches (can rewrite history).
When to Use What?
Scenario | Use Merge | Use Rebase |
---|---|---|
Working on a shared team branch | Yes | No |
Want clean linear history | No | Yes |
Undo or squash messy commits | No | Yes |
Preserve full commit timeline | Yes | No |
Wrapping It Up
Git is much more than just a version control tool — it’s the backbone of modern software collaboration. From setting it up on your local system to branching, committing, pushing, resolving conflicts, and even reverting changes, mastering Git empowers you to work smarter and safer.
Whether you’re a solo developer or part of a team, understanding how Git works under the hood helps you manage your codebase with confidence. Don’t be afraid to make mistakes — Git has your back, and now, so do you!