Skip to content
Go back

Git Commands

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:

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:

🔹 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

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:

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:

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:

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:

  1. 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
  1. Undo Last Commit (Discard everything)

This will remove the last commit and discard all changes:

git reset --hard HEAD~1
  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.

  1. 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

Rebase

git rebase moves or “replays” your changes onto another branch, creating a linear history.

git checkout feature-branch
git rebase main

When to Use What?

ScenarioUse MergeUse Rebase
Working on a shared team branchYesNo
Want clean linear historyNoYes
Undo or squash messy commitsNoYes
Preserve full commit timelineYesNo

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!


Share this post on:

Next Post
SSAS Cube migration into fabric semantic model