Git & GitHub for Beginners: From Basics to Real DevOps Workflow (Part-1)

Why I Learned Git as a DevOps Engineer

When I started my journey into DevOps, I thought I would be spending most of my time learning cloud platforms, Docker, Kubernetes, and automation tools. And yes, those are important. But very early on, I noticed something interesting — every single tool, every workflow, and almost every real-world project had one thing in common:

Everything revolved around Git.

At first, I underestimated it. I thought Git was just a tool developers use to store code. But as I went deeper into DevOps, I realized Git is not just a tool — it’s the foundation of how modern software is built, managed, and deployed.

The First Realization: DevOps Starts with Code

In DevOps, you are not just managing servers. You are managing code, infrastructure, and automation pipelines.

And all of that lives in Git.

• Application code → Git
• Infrastructure as Code (Terraform, CloudFormation) → Git
• CI/CD pipelines → Git
• Configuration files → Git

So before you even deploy anything, everything begins with a Git repository.

That’s when it clicked for me:
If I don’t understand Git properly, I can’t truly understand DevOps.

Git is the Backbone of CI/CD

One of the biggest reasons I learned Git deeply was CI/CD.

In theory, CI/CD sounds simple:

• Push code
• Run tests
• Deploy automatically

But in practice, everything depends on Git events.

Whenever you:

• Push code
• Create a pull request
• Merge a branch

These actions trigger pipelines.

That means Git is not just storing code — it is actually driving automation.

Without Git:

• No automation triggers
• No version-based deployments
• No rollback strategy

And rollback is critical. In production, things break. When they do, Git allows you to instantly revert to a stable version. That’s not just convenient — that’s survival in real systems.

Learning Branching Changed My Mindset

Before Git, my workflow was simple:
Write code → save → overwrite → repeat.

After learning Git, I started thinking differently.

Branches allowed me to:

• Work on features independently
• Experiment without fear
• Keep the main codebase stable

This is exactly how real companies work.

Instead of one messy codebase, you have:

• main (stable production code)
• feature/* branches (new work)
• bugfix/* branches (fixes)

And everything gets merged in a controlled way.

This is not just a technical concept — it’s a discipline.

Git Gave Me Confidence to Experiment

One of the biggest psychological shifts for me was this:

I stopped being afraid of breaking things.

Because now:

• I can always go back to a previous commit
• I can compare changes
• I can undo mistakes

This freedom is powerful.

It allowed me to:

• Try new ideas
• Refactor code
• Learn faster

Without Git, mistakes feel permanent. With Git, mistakes become part of the learning process.

Collaboration Became Clear

Even though I was working mostly on personal projects, I knew that in real jobs, teamwork is everything.

Git showed me how developers actually collaborate:

• Multiple people working on the same project
• Code reviews through pull requests
• Controlled merging instead of chaos

It’s not just about writing code — it’s about working together without conflicts.

And DevOps sits right in the middle of this collaboration.

Git is Not Optional in DevOps

At some point, I realized something very important:

Git is not a “nice-to-have” skill. It’s mandatory.

Every DevOps tool integrates with Git:

• CI/CD tools listen to Git events
• Deployment systems pull code from Git
• Monitoring setups track versions from Git

Even infrastructure changes are tracked using Git.

If you remove Git from the equation, the entire DevOps workflow collapses.

Final Thought

Learning Git was not just about learning commands like add, commit, or push.

It was about understanding:

• How software evolves
• How teams collaborate
• How automation works
• How production systems stay reliable

If you are starting your DevOps journey, don’t rush past Git.

Spend time on it.

Because once you master Git, you’re not just managing code —
you’re managing the entire lifecycle of software.

What You’ll Learn

• What is Version Control System (VCS)
• File System vs VCS
• What is Git & GitHub
• History of Git
• Installation (Local + EC2)
• Git Lifecycle
• Basic Git Commands

What is a Version Control System (VCS)?

Let me explain this the way I actually understood it — not from a textbook, but from a real problem.

The Problem We All Face

Imagine you’re building a project.

At the beginning, everything is simple. You write some code and save it as:

• project_v1
• Then you make changes → project_v2
• Then more changes → project_final
• Then a bug appears → project_final_latest
• Then one more fix → project_final_latest_v3_real_final

At this point, even you don’t know:

• Which file is correct
• Which one has the latest changes
• What exactly changed between versions

And if something breaks?
You’re just stuck guessing.

That’s Where VCS Comes In

A Version Control System (VCS) solves this exact problem.

Instead of creating multiple messy files, VCS manages everything in a clean and structured way.

It automatically:

• Tracks every change you make
• Saves versions of your code (like checkpoints)
• Lets you go back to any previous version anytime

So instead of 10 different files ( like file_v1.txt, file_v2.txt,……….,file_final.txt ) , you have one project with a complete history.

What It Actually Does

Think of VCS like a timeline of your project.

At any moment, you can:

• See what changes were made
• See who made them (in teams)
• Compare versions
• Undo mistakes instantly

It’s like having a “time machine for your code” — and honestly, that’s the best way to think about it.

Why It Matters Even More in DevOps

When you move into DevOps, things get more serious.

Now you’re not just managing code, you’re managing:

• Deployments
• Infrastructure
• Automation pipelines

And all of this needs:

• Version tracking
• Stability
• Rollback capability

Without a VCS, handling production systems would be chaos.

A Version Control System is a tool that helps you to track, manage, and control changes in your code without the mess.

File System vs Version Control System (VCS)

When I first started, I didn’t even realize I was already “managing versions” — just in a very messy way using my file system. Understanding the difference between a normal file system and a Version Control System completely changed how I handle projects.

Here’s a clear comparison:

My Realization

Before learning VCS, I was just saving files again and again, hoping I wouldn’t lose anything.

After learning it, I understood:
It’s not about storing files — it’s about managing change in a structured way.

And that’s exactly why tools like Git are so powerful in real-world development and DevOps.

What is Git ?

Git is a distributed version control system designed to track changes in source code during software development, allowing developers to maintain a complete history of their project, manage different versions efficiently, and collaborate with others in a structured and conflict-free manner.

It enables users to record changes through commits, revert to previous versions when needed, and work on multiple features simultaneously using branching. Since Git is distributed, every user has a full copy of the repository along with its entire history, which allows working offline and ensures better performance and reliability.

Git is widely used in modern development and DevOps workflows because it provides speed, data integrity, powerful branching and merging capabilities, and seamless integration with platforms like GitHub for collaboration and automation.

History of Git

The Story Behind Git: How It All Started

Back in the early 2000s, the development of the Linux kernel was growing rapidly. Thousands of developers from around the world were contributing to it, and managing all those changes was becoming a serious challenge.

At the center of it all was Linus Torvalds, the creator of Linux.

The Problem That Started Everything

Initially, the Linux community used a proprietary version control system called BitKeeper. It worked well for a while, but there was one big issue: It wasn’t open source.

In 2005, due to licensing conflicts, the Linux community lost access to BitKeeper.

Suddenly, they were stuck.

• No proper tool to manage code
• Thousands of contributors
• Massive codebase

For a project as large as Linux, this was a crisis.

Linus Decides to Build His Own Tool

Instead of searching for alternatives, Linus Torvalds made a bold decision:

“I’ll build my own version control system.”

But he had very clear goals in mind. He didn’t just want any tool — he wanted something better than what already existed.

He focused on a few key principles:

• Speed → It should be extremely fast
• Distributed system → No dependency on a central server
• Data integrity → No data corruption
• Support for large projects → Must handle the Linux kernel efficiently

Building Git (In Just a Few Weeks)

What’s surprising is how quickly it happened.

Linus started working on Git in April 2005, and within weeks, the first version was ready.

It was simple at first, but incredibly powerful.

Instead of storing just file changes, Git stored snapshots of the entire project. This made operations faster and more reliable.

The Name “Git”

Interestingly, the name “Git” has a funny origin. In British slang, “git” is a mildly insulting word. Linus jokingly named it that way, keeping his usual humor in mind.

He even described it as: “the stupid content tracker”

From Personal Tool to Global Standard

What started as a solution for the Linux kernel quickly became something much bigger.

Developers around the world started adopting Git because:

• It was fast
• It worked offline
• It handled branching beautifully

Later, platforms like GitHub made Git even more powerful by enabling easy collaboration.

Today, Git is used everywhere:

• Startups
• Big tech companies
• Open-source projects
• DevOps pipelines

For me, this story is not just about a tool. It’s about solving a real problem.

Linus didn’t create Git to learn something new or build a side project.
He built it because there was a real need, and existing solutions failed. And that’s exactly why Git became so successful.

Git Installation: Local Machine & EC2 (Ubuntu)

When I started using Git, the first step was getting it installed properly — both on my local system and on a cloud server like an EC2 instance. This is something every DevOps beginner ends up doing, so here’s how I approached it.

Installing Git on Local Machine

For Windows

Most beginners (including me) start with Windows, so this is straightforward:

Git Bash image

• Go to the official Git website
• Download Git for Windows
• Run the installer and keep most settings as default
• It installs Git Bash, which lets you run Git commands

After installation, open Git Bash and verify:

git --version

If it shows a version, you’re good to go.

For macOS

• Open Terminal
• Run:

git --version

If Git is not installed, macOS will prompt you to install it automatically using Xcode Command Line Tools.

For Linux (Local)

While Git was created by Linus Torvalds to manage the Linux kernel, it is not always pre-installed on most of the Linux distribution or cloud instance by default. Furthermore, even if Git is present, it may be an outdated version.

To ensure you have the latest stable version and security patches, you should update your package manager index and install or upgrade Git using the following commands:

# Update the local package index to fetch the latest metadata
sudo apt-get update

# Install or upgrade Git to the latest available version (-y auto-approves the prompt)
sudo apt-get install git -y

Verify:

git --version

Installing Git on EC2 (Ubuntu)

Now this is where things start feeling like real DevOps work.

Step 1: Connect to EC2

ssh -i your-key.pem ubuntu@your-ec2-public-ip

Step 2: Update Packages

sudo apt update

Step 3: Install Git

sudo apt install git -y

Step 4: Verify Installation

git --version

Step 5: Configure Git (Important)

The git config command is used to configure Git settings, such as your name, email address, default editor, aliases, and other preferences. One of its most important uses is setting the author information that Git records with every commit.

Whenever you create a commit, Git automatically stores:

• Author Name
• Author Email
• Commit Date
• Commit Message

This information helps identify who made each change in the project’s history.

Set Author Details Globally

The following commands configure your name and email for all Git repositories on your system.

git config --global user.name "Nikhil Kumar"

git config --global user.email "nikhil@example.com"

Set Author Details for a Specific Repository

If you want different author details for just one project, navigate to that repository and run:

git config user.name "Nikhil Kumar"

git config user.email "nikhil@example.com"

These settings apply only to the current repository.

View Current Configuration

To display all Git configuration settings:

git config --list

Change Author Details

Simply run the same commands again with the new values.

git config --global user.name "New Name"

git config --global user.email "newemail@example.com"

Git updates the configuration with the new author information.

Understanding the Git Lifecycle: From a Normal Folder to a Git Repository

Git lifecycle

When I first started learning Git, I memorized commands like git add, git commit, and git status without really understanding what was happening behind the scenes.

I knew the commands, but I didn’t know why I was using them.

Everything became much clearer once I understood the Git lifecycle — the journey every file goes through before it becomes part of a project’s history.

In this article, I’ll explain the Git lifecycle in the simplest way possible.

Every Folder is Just a Normal Folder

When you create a new directory on your computer, it is simply a collection of files. For example:

mkdir git-demo
cd git-demo

At this point, this folder has no idea what Git is.

You cannot create commits, track changes, or view project history because Git has not been initialized.

By default, every directory on your system is just a normal directory — not a Git repository.

Converting a Normal Folder into a Git Repository

To tell Git that you want to track everything inside this folder, you initialize Git.

git init

After running this command, Git creates all the necessary files required to manage version history. The folder is now officially a Git repository. You’ll see a message similar to:

Initialized empty Git repository in /path/to/project/.git/

How to Verify the Folder is Now a Git Repository

Since Git creates hidden files, you won’t see them using the normal ls command. Instead, run:

ls -a

Output:

.
..
.git

The .git folder is the heart of every Git repository.

Get Nikhil-Devops’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

It contains everything Git needs to function, including:

• Commit history
• Branch information
• Configuration
• References
• Logs
• Objects
• Metadata
• Hooks
• Info

You generally never modify anything inside this folder manually.

As long as the .git directory exists, Git recognizes the folder as a repository.

Git Lifecycle Process

Now comes the most important concept. Every file inside Git moves through different stages before it becomes part of your project’s history.

The lifecycle looks like this:

Create File
      │
      ▼
 Untracked
      │
 git add
      ▼
 Staging Area
      │
 git commit
      ▼
 Tracked (Committed)
      │
 Modify File
      ▼
 Modified
      │
 git add
      ▼
 Staging Area
      │
 git commit
      ▼
 Updated Commit

Understanding these stages makes Git much easier to use.

Untracked Files

Suppose you create a file.

touch app.py

Now check its status.

git status

Git shows something like:

Untracked files:
  app.py

This means Git has noticed the file exists, but it is not managing it yet.

Think of it as saying:

“I can see this file, but you haven’t told me whether you want me to keep track of it.”

Until you explicitly tell Git, the file remains untracked.

Staging Area

The next step is to tell Git that this file should become part of the next commit. This is done using:

git add app.py

Now the file moves into the Staging Area. You can think of the staging area as a preparation zone. Git is basically asking:

“Are you sure these are the changes you want to save?”

Nothing has been permanently stored yet. You’re simply preparing the snapshot. This is why the staging area is sometimes called the Index.

Commit: Saving a Snapshot

Once everything is staged, you permanently record those changes.

git commit -m "Add app.py"

A commit is a snapshot of your project at a particular point in time.

Unlike manually creating folders like:

project_v1
project_v2
project_final

Git stores these versions automatically.

Every commit has:

• A unique ID
• Author information
• Timestamp
• Commit message
• Snapshot of the project

This allows you to revisit any point in your project’s history whenever needed.

A commit hash (also called a commit ID or SHA) is a unique 40-character hexadecimal identifier that Git automatically generates for every commit. It acts like a fingerprint, allowing Git to uniquely identify and reference a specific snapshot of your project’s history.

Example:

a7c9f2d8b4e6f1234567890abcdef1234567890ab

Since the full hash is long, Git usually displays a shortened version, such as:

a7c9f2d

This short hash is typically enough to uniquely identify a commit within a repository.

Why is a commit hash important?

• It uniquely identifies every commit.
• It allows you to view a specific commit.
• It helps you revert or reset to a previous version.
• It is used when comparing changes between commits.

How to Move a Tracked File to Untracked

Sometimes you may want Git to stop tracking a file.

Keep the file but stop tracking it (Recommended)

This removes the file from Git’s tracking but keeps it on your local system.

git rm --cached demo.txt

After committing this change, demo.txt becomes an untracked file.

Remove the file from both Git and your local system

This removes the file from the repository and deletes it from your working directory.

git rm demo.txt

After committing, the file is deleted completely.

Best Practices for Writing Git Commit Message

When you are fixing a small bug or adding a minor feature, the golden rule is to keep the commit message concise, imperative, and clear.

The industry standard for organizing these is the Conventional Commits specification. It makes your git history incredibly easy to read and automates changelog generation.

1. Small Bug Fixes

Use the prefix fix:. Describe what was fixed, not how you fixed it.

• fix: resolve typo in landing page navbar
• fix: correct padding on mobile submit button
• fix: handle null values in user profile API
• fix: update broken login redirect URL

2. Small Additions or Features

Use the prefix feat: (short for feature). Even if it's tiny, if it adds new functionality, it's a feature.

• feat: add dark mode toggle to settings
• feat: implement email validation on signup
• feat: add loading spinner to checkout button

3. Routine Tweaks, Refactors, or Maintenance

If you didn’t fix a bug or add a feature, but just cleaned things up:

• refactor: (Code changes that neither fix a bug nor add a feature)
• refactor: simplify user authentication logic
• style: (Changes that do not affect the meaning of the code—white-space, formatting, missing semi-colons, etc.)
• style: run prettier formatter on index.js
• docs: (Documentation only changes)
• docs: update installation steps in README

Tracked Files

After committing, the file becomes a tracked file. Git now continuously monitors it. If you modify it:

print("Hello Git")

and run:

git status

Git will report:

modified: app.py

Git already knows about this file because it is now part of the repository history.

What Happens After Modification?

Once a tracked file changes, Git detects that the working copy is different from the last committed version.

To save the new changes:

git add app.py

The modified file moves back into the staging area.

Then:

git commit -m "Update app.py"

A brand-new snapshot is created.

This process repeats throughout the life of every project.

Why Doesn’t Git Commit Automatically?

This is one of the smartest design decisions in Git. Imagine editing ten files. Maybe only three are ready. If Git automatically committed every change, your project history would become messy. Instead, Git lets you carefully choose exactly what should become part of the next commit. This gives developers complete control over project history.

The Three Main Areas of Git

Whenever you work with Git, you’re constantly moving files between three locations.

Working Directory:- Where you create and edit files

Staging Area:- Where changes are prepared for the next commit

Git Repository:- Where commits are permanently stored

Almost every Git command simply moves changes from one area to another.

My Biggest Learning

Initially, I thought git add simply meant "add the file." Later I realized it actually means: Prepare this version of the file for the next commit.

Similarly, I thought git commit saved the file. In reality: A commit saves an entire snapshot of the project, not just a single file.

The Git lifecycle is one of the most important concepts every developer and DevOps engineer should understand.

Once you know how files move from Untracked → Staging → Commit → Tracked, Git commands stop feeling like magic and start making perfect sense. Instead of memorizing commands, you’ll understand the reasoning behind them.

Git History and Commit Logs

In Git, the log is essentially your project's diary or audit trail. It is a chronological record of every single snapshot (commit) that has ever been saved in your repository.

When you type git log into your terminal, Git pulls up this history so you can see exactly who changed the code, when they changed it, and why (via their commit messages).

By default, running git log displays entries moving backward in time (newest commits at the top). A standard entry looks like this:

commit c2f7a9d4b3e8f1a0c9b8a7f6e5d4c3b2a1f0e9d8
Author: Jane Doe <jane.doe@example.com>
Date:   Sun Jul 19 10:30:00 2026 +0530

Fix broken login validation button

Every standard log entry contains four vital pieces of information:

The Commit Hash: A unique, 40-character fingerprint (like c2f7a9d...) that identifies that exact change. You use this hash if you ever need to roll back or investigate that specific point in time.

The Author: The name and email of the person who made the change (configured via those user.name and user.email settings we just talked about!).

The Date: Exactly when the commit was saved.

The Commit Message: The summary written by the developer explaining what they changed and why.

Depending on how much detail you need or what you are looking for, you can customize the log output using various flags:

View standard history:

git log

Shows the full history. Press q to exit the log view.

View a condensed, single-line summary:

git log --oneline

Highly recommended for a quick overview. It shrinks the 40-character hash to 7 characters and shows only the commit message.

Limit the number of commits shown:

git log -n 5

Replaces 5 with whatever number of recent commits you want to view (e.g., -n 3 or just -3).

Filter by a specific author:

git log --author="John Doe"

Filter commits by a specific file:

git log -- app.py

Shows only the commits that modified app.py.

Search for commits by keywords in the commit message:

git log --grep="fix bug"

View the changes (diffs) introduced in each commit:

git log -p

• Shows the actual code additions and deletions line-by-line for each commit.

See a visual text-based graph of your branches and merges:

git log --graph --oneline --all

Draws a helpful ASCII network graph showing how branches diverge and merge together.

Git Branching Explained: Work on New Features Without Breaking Your Main Code

Imagine you’re writing a novel. Your publisher has already approved the current version, but suddenly you get an idea for an exciting new ending. Would you directly edit the published manuscript? Probably not. Instead, you’d make a copy, experiment with different endings, and only replace the original if you’re happy with the result.

Git branching works in exactly the same way.

A Git branch is an independent line of development that lets developers work on new features, bug fixes, experiments, or refactoring without affecting the main project. Rather than modifying the stable codebase directly, developers create a separate branch where they can safely make changes. Once those changes are tested and reviewed, they are merged back into the main branch. This simple concept is one of the biggest reasons Git has become the most popular version control system in the world, as it enables multiple developers to collaborate on the same project simultaneously without constantly overwriting each other’s work.

Consider another real-world example. Imagine a team of architects designing a new shopping mall. The approved blueprint is stored safely in the office. One architect is responsible for designing a larger parking area, another redesigns the food court, while a third experiments with a rooftop garden. Instead of drawing over the original blueprint, each architect works on a copy. After their designs are approved, the best changes are merged into the final blueprint. Git branches work exactly the same way — they allow multiple ideas to be developed independently while keeping the original project stable.

Let’s see how this works in software development. Suppose your application’s main branch contains a stable e-commerce website that customers use every day. Your manager asks you to add a "Dark Mode" feature. If you start coding directly on main, a half-finished implementation could accidentally reach production and affect users. Instead, you create a new branch named feature/dark-mode. Inside this branch, you modify files, commit changes, and test the feature without impacting the production version. Even while you're working, your teammates can continue fixing bugs or adding other features on their own branches. Once your work is complete and passes code review, your branch is merged into main, making the feature available without disrupting anyone else's work.

Branches are lightweight in Git because they don’t create an entirely new copy of your project. Internally, a branch is simply a movable pointer that references the latest commit. When you create a new branch, Git doesn’t duplicate thousands of files. Instead, both branches initially point to the same commit. As new commits are made on the feature branch, only that branch’s pointer moves forward while the main branch continues pointing to the stable version. This design makes branch creation almost instantaneous, even for very large repositories.

One of the greatest strengths of branching is collaboration. In a team environment, every developer typically creates a separate branch for each task. For example, one developer may work on feature/login, another on feature/payment, while someone else fixes a production issue in bugfix/cart-calculation. Since each branch is isolated, developers can work independently without interfering with one another. After review and testing, the branches are merged into the main branch, creating a clean and organized development workflow.

Another advantage of branching is experimentation. Sometimes developers want to test a new technology, optimize performance, or rewrite a module without knowing whether the changes will succeed. Instead of risking the stable application, they create an experimental branch. If the idea works, the branch is merged; if not, the branch can simply be deleted without affecting the original project. This makes Git branching a safe playground for innovation.

In modern DevOps and software engineering practices, branches are closely integrated with Continuous Integration and Continuous Deployment (CI/CD) pipelines. Whenever developers push a branch to GitHub, automated workflows can compile the project, execute tests, perform security scans, and verify code quality before allowing the branch to be merged. This ensures that only tested and reliable code reaches production.

Important Git Commands for Managing Branches

View all local branches

git branch

Lists every branch in your local repository. The currently active branch is marked with an asterisk (*).

Create a new branch

git branch feature/login

Creates a new branch but keeps you on your current branch.

Create and switch to a new branch (older syntax)

git checkout -b feature/login

Creates a new branch and immediately switches to it.

Create and switch to a new branch (recommended)

git switch -c feature/login

Modern Git command that performs the same action with clearer intent.

Switch to an existing branch

git switch main

or

git checkout main

Moves your working directory to another branch.

Rename the current branch

git branch -m new-branch-name

Changes the name of the current branch.

Delete a merged branch

git branch -d feature/login

Safely deletes a branch after it has been merged.

Force delete a branch

git branch -D feature/login

Deletes a branch even if it contains unmerged commits.

Merge a branch

git switch main
git merge feature/login

Brings the commits from the feature branch into the current branch.

Check the current branch

git branch --show-current

Displays the name of the branch you’re currently working on.

What is a Remote Code Repository?

A Remote Code Repository is a version-controlled hosting environment located on a cloud-based or external server (like GitHub, GitLab, or BitBucket). While Git runs locally on your machine to track changes, the remote repository acts as a centralized, single source of truth where your team can store, share, sync, and back up the codebase.

The Missing Piece After Git

Learning Git without GitHub felt incomplete.

With Git, I could:

• Track changes
• Maintain history
• Create branches

But with Remote code repository like Github, I could:

• Share my code
• Collaborate with others
• Access my project from any device

It basically turned my local work into something real and shareable.

Why Do We Use Remote Repositories?

Without remote platforms, Git would only live on your local machine. We use remote repositories for several critical engineering reasons:

• Seamless Collaboration: It allows multiple developers to work on the exact same codebase simultaneously without overwriting each other’s work via features like branches and Pull/Merge Requests.
• Centralized Source of Truth: It provides a reliable backup. If your local computer crashes or gets damaged, the entire history of the project remains safe in the cloud.
• Automation & DevOps: Modern remote platforms act as the execution engines for CI/CD (Continuous Integration/Continuous Deployment). They detect when code is pushed or merged and automatically trigger test suites and production deployments.
• Code Quality Control: They facilitate built-in code reviews, discussion threads, and mandatory approval workflows before changes hit production.

Top Remote Repository Platforms: Features & Specifications

While all these platforms host Git repositories, each has evolved to serve different engineering strengths and organizational needs.

1. GitHub

GitHub is the most popular code-hosting platform in the world, heavily favored by the open-source community and fast-growing tech companies.

• Key Specifications: Owned by Microsoft, features GitHub Actions (CI/CD), Advanced Security scanning, and GitHub Copilot integration.

Primary Benefits:

• Unmatched Community & Ecosystem: It is the undisputed home of open-source software, making collaboration on public projects seamless.
• Extensive Marketplace: Thousands of third-party integrations and native automation workflows via GitHub Actions.
• Developer Experience: Superior UI/UX for code reviews, discussions, and project tracking (GitHub Projects).

2. GitLab

GitLab is built as a single, comprehensive DevSecOps platform, meaning it aims to handle everything from planning and coding to security testing and deployment in one application.

Key Specifications: Available as both a cloud service and a robust self-hosted solution; natively includes container registries and comprehensive security orchestration.

Primary Benefits:

• All-in-One Architecture: You don’t need to piece together external tools for project management, CI/CD, and monitoring; GitLab covers the full lifecycle natively.
• Industry-Leading CI/CD: Its integrated pipeline engine is incredibly mature, flexible, and powerful for complex enterprise setups.
• Deep Security Integration: Natively runs Static Application Security Testing (SAST), Dynamic Testing (DAST), and dependency scanning right inside your merge requests.

3. Bitbucket

Bitbucket is Atlassian’s Git hosting solution, custom-built to sit deeply inside enterprise ecosystems that run on Jira and Confluence.

Key Specifications: Owned by Atlassian, features Bitbucket Pipelines, and offers strict deployment permissions tailored for enterprise governance.

Primary Benefits:

• Native Jira Integration: If your organization tracks engineering tasks in Jira, Bitbucket offers unparalleled synchronization (e.g., automatically updating Jira issues based on Git branches or commit states).
• Granular Permissions: Excellent control over branch permissions, preventing unauthorized deployment merges at a highly precise team level.
• Cost-Efficient for Teams: Historically offers flexible pricing models for small teams needing private repositories within the Atlassian suite.

Remote Branch

In Git, a remote branch is a reference (or pointer) to the state of branches on a remote repository (like GitHub, GitLab, or Bitbucket) at the last time you connected with it.

Here is a breakdown of what they are and how they work compared to local branches:

1. They Are “Read-Only” Bookmarks

Remote branches function like local bookmarks that point to the exact commit history on the server. You cannot directly work on, commit to, or modify a remote branch locally.

Instead, they only update when you explicitly communicate with the network using commands like git fetch, git pull, or git push.

2. Naming Convention

Remote branches are easily identifiable because they are always prefixed with the remote’s name (which is usually origin by default) followed by a forward slash and the branch name.

• main :- Your local copy of the main branch that you can change.
• origin/main :- The remote branch tracking the state of main on the server named origin.

In some versions main branch is named as master.

How Local and Remote Branches Interact

[ Local Machine ]                      [ Remote Server (origin) ]
 
  main (You make commits here)              main
   │                                         ▲
   ▼                                         │
 origin/main ────────────────────────────────┘
 (Only updates when you fetch/push)

• Working Locally: You make changes and commits on your local main branch. At this point, your local branch moves ahead, but origin/main stays where it is.
• Syncing: When you run git push, Git updates the remote server's main branch and moves your local origin/main pointer forward to match it.
• Fetching: If a teammate pushes code to the server, your local main won't change automatically. When you run git fetch, Git updates your origin/main pointer so you can see what they did before deciding to merge it into your local code.

View remote branches

git branch -r

Displays branches available on the remote repository.

View both local and remote branches

git branch -a

Shows every branch that exists locally and remotely.

Push a new branch to GitHub

git push -u origin feature/login

Uploads the branch to the remote repository and sets the upstream tracking branch.

Delete a remote branch

git push origin --delete feature/login

Removes a branch from the remote repository.