DEV Community: Benjamin Tetteh

Real-World Git Branching Strategies: How Teams Manage Code in Practical Dev Environments

Benjamin Tetteh — Wed, 08 Jul 2026 02:48:21 +0000

You've learned Git commands. Now let's see how real development teams actually use Git day to day — from branching strategies to deployments, code reviews, and fixing production bugs at speed.

Introduction

Git commands are one thing. Using Git properly in a real development team is another.

You can know git commit, git push, and git merge perfectly and still feel lost the first time a senior developer says:

"Create a feature branch off develop, open a PR when it's ready, and don't push directly to main."

This article bridges that gap.

Whether you are a beginner trying to understand how teams work, or an intermediate developer looking to sharpen your workflow, this guide covers the branching strategies, environments, and team practices that show up in real projects — from small startups to large engineering organisations.

A Note on Real-World Workflows

Every engineering team has its own workflow.

A startup with five engineers may work very differently from a bank with hundreds of developers. The strategies in this article are the most common patterns you will encounter, but do not be surprised if your future team combines ideas from several of them — or has invented their own hybrid entirely.

The goal is not to memorise a strategy. The goal is to understand the reasoning behind each one so you can adapt to any team confidently.

Why Branching Matters in Real Projects
The Common Environments
How Code Moves Between Environments
Common Branch Types
GitHub Flow
Git Flow
Trunk-Based Development
Environment-Based Branching
Feature Flags
Pull Requests and Code Reviews
What Happens After a Merge?
How This Looks on GitHub
CI/CD and Branch Protection Rules
Where Does DevOps Fit?
A Security Perspective
Hotfix Scenario: Fixing Production Quickly
Which Strategy Do Real Companies Use?
Which Branching Strategy Should Beginners Learn First?
Common Mistakes Teams Make
Final Thoughts

1. Why Branching Matters in Real Projects

In a solo project, branching is a good habit.

In a team project, branching is essential.

Without a clear branching strategy, teams run into problems like:

Two developers overwriting each other's work
Untested code being deployed directly to users
A bug fix accidentally breaking an unrelated feature
No clear way to roll back a bad deployment
Confusion over which branch is the "source of truth"

A branching strategy is simply an agreed set of rules for how your team creates, names, and merges branches. It answers questions like:

Where does new feature work start?
How does code get reviewed before merging?
How do we push code to production safely?
What do we do when there is a bug in production right now?

Why `main` exists

Most tutorials say: "main is production." But why does it exist as a special branch?

The main branch represents the source of truth for your project. In most organisations, every commit on main should be deployable at any moment. That means if someone triggers a deployment of main right now, the application should work correctly for users.

This concept — a deployable branch — is fundamental to understanding why teams protect main so carefully.

💡 Many organisations configure GitHub so that nobody — not even senior engineers — can push directly to main. All changes must go through a pull request. Do not assume you will always be able to push directly; on most professional teams, you will not.

2. The Common Environments

Before understanding branching strategies, it helps to understand the environments that code typically passes through on its way to users.

Laptop → Sandbox → Dev → QA/Test → Staging → Production

Local Development (Your Laptop)

This is your machine. You write code here, run it, test it, and break things freely. Nothing here affects anyone else.

Sandbox Environment

A personal or isolated environment where a developer can test their work independently before sharing it with the team. Sandboxes are often spun up on demand and torn down afterwards. They are useful for experimenting with infrastructure changes, testing integrations, or working on something that is not ready for the shared dev environment yet.

Development Environment (Dev)

A shared server where developers see each other's work integrated together. Often automatically updated when code is merged into a develop branch. It is not stable and changes frequently throughout the day.

QA / Test Environment

Used by QA engineers or testers to verify that features work correctly and that nothing is broken. More controlled than the dev environment, but still not user-facing.

Staging Environment

A near-identical copy of production. Staging is used for final checks before a release goes live. Stakeholders often review features here. It should behave exactly like production — same data structure, same configuration, same infrastructure where possible.

Production Environment

The live environment that real users interact with. Code here must be stable, tested, and approved. Changes to production are treated with the highest level of care.

Each environment has a higher bar for stability than the last. Code earns its way to production by passing through every gate before it.

3. How Code Moves Between Environments

In most teams, code does not jump directly from a developer's laptop to production. It moves through a deliberate pipeline.

Your laptop
     ↓
Feature branch (your work in progress)
     ↓
Pull Request (code review + automated tests)
     ↓
develop / main (integration)
     ↓
Sandbox / Dev environment (integration testing)
     ↓
QA / Test environment (quality assurance)
     ↓
Staging environment (final review)
     ↓
Production (live for users)

Each step acts as a quality gate. The further along the pipeline the code moves, the more confidence the team has that it is safe to ship.

In many teams, this movement is automated. When you merge a PR into develop, a CI/CD pipeline may automatically deploy that code to the dev environment. When code reaches main, it may automatically deploy to staging or production.

Understanding this pipeline is just as important as understanding Git commands.

4. Common Branch Types

Most teams use a consistent naming convention for branches. Here are the types you will encounter in real projects:

Branch	Purpose
`main`	Production-ready code. Always stable and deployable.
`develop`	Integration branch where completed features are merged before release.
`feature/*`	New feature work. Created from `develop` or `main`.
`bugfix/*`	Fixing a non-urgent bug found in development or testing.
`hotfix/*`	Urgent fix for a bug in production. Bypasses the normal flow.
`release/*`	Preparing a release. Used for final tweaks before merging to `main`.

Naming conventions in practice

Teams often include a ticket or issue number in the branch name for traceability:

feature/AUTH-42-add-oauth-login
bugfix/UI-17-fix-mobile-nav-overlap
hotfix/PROD-99-fix-payment-timeout
release/v2.4.0

This makes it immediately clear what the branch is for, which ticket it relates to, and what kind of change it contains — even months later when someone is reading through the history.

5. GitHub Flow

GitHub Flow is a lightweight, simple branching strategy suited for teams that deploy frequently — sometimes many times a day.

main ──────────────────────────────────────► (always deployable)
  │                                  ▲
  └──► feature/login                 │
           │                         │
           │  commits                │
           ▼                         │
        Pull Request                 │
           │                         │
        Code Review                  │
           │                         │
        CI Checks                    │
           │                         │
        Approved ────────────────────┘
                        Merge
                           │
                       Production

The rules

main is always deployable
All new work happens on a feature branch created from main
Open a pull request early, even before the work is finished
Get the branch reviewed and tested via CI
Merge into main and deploy

In practice

git switch main
git pull
git switch -c feature/add-dark-mode

# do your work

git add .
git commit -m "Add dark mode toggle to settings page"
git push -u origin feature/add-dark-mode

# open a pull request on GitHub
# get it reviewed and approved
# merge and deploy

Who should use it

GitHub Flow works well for small to medium teams, web applications with continuous deployment, open source projects, and teams that want simplicity over ceremony. It is the ideal starting point for beginners joining a real team.

6. Git Flow

Git Flow is a more structured strategy designed for teams with scheduled releases. It was introduced by Vincent Driessen in 2010 and became very influential in enterprise and product teams.

main      ──────────────────────────────────► (tagged releases)
               ▲                    ▲
               │                    │
hotfix/fix ────┘           release/v2.1 ──► develop
                                               │
                              ┌────────────────┤
                              │                │
                         feature/login   feature/dashboard

The key branches

main — production-ready code only. Tagged with version numbers.

develop — the integration branch. All features merge here first.

feature/* — individual feature branches, created from develop.

release/* — created from develop when preparing a release. Only bug fixes and release prep happen here, no new features.

hotfix/* — created from main for urgent production fixes.

A typical Git Flow lifecycle

# Start a new feature
git switch develop
git switch -c feature/user-profile
git commit -m "Add user profile page"

# Merge back into develop via pull request
git switch develop
git merge feature/user-profile
git branch -d feature/user-profile

# When ready to release
git switch -c release/v2.1.0
git commit -m "Bump version to 2.1.0"

# Merge into main and tag
git switch main
git merge release/v2.1.0
git tag -a v2.1.0 -m "Release version 2.1.0"

# Merge back into develop
git switch develop
git merge release/v2.1.0

Who should use it

Git Flow works well for teams with scheduled versioned releases, mobile or desktop apps going through an approval process, and projects that maintain multiple versions simultaneously. It can feel heavy for small teams or fast-moving web projects, but it provides clear structure for complex release cycles.

7. Trunk-Based Development

Trunk-based development (TBD) is a strategy where all developers commit to a single branch — the trunk, usually main — as frequently as possible, often multiple times a day.

main (trunk)
  ▲    ▲    ▲    ▲    ▲
  │    │    │    │    │
 Dev1 Dev2 Dev1 Dev3 Dev2
(short-lived branches merged within hours, not days)

The core principles

Branches are short-lived — hours or a day at most
Commits to main are small and frequent
Broken builds are fixed immediately — they are the team's top priority
Feature flags control what users see (more on this below)

Why teams use it

Trunk-based development avoids the painful merge conflicts that come from long-lived branches. When everyone integrates constantly, there is never a large divergence to reconcile at the end of a sprint.

It is the approach favoured by high-performing engineering organisations and is closely tied to mature CI/CD pipelines.

Who should use it

Teams with strong automated test coverage, mature CI/CD tooling, and experience with feature flags. It can be challenging for beginners without these foundations in place.

8. Environment-Based Branching

Some teams structure their branches to directly mirror their deployment environments.

feature/* ──► develop ──► staging ──► main
                │             │          │
              Dev env    Staging env   Production

Each branch maps directly to an environment:

Branch	Environment
`develop`	Development server
`staging`	Staging server
`main`	Production

Merging a PR into develop automatically deploys to the dev server. Merging into staging deploys to staging. Merging staging into main goes to production.

This gives every environment a clear, always-current state. Developers, QA, and stakeholders know exactly what is deployed where at all times. The trade-off is that code must move through each environment sequentially, which can slow fast-moving teams down.

9. Feature Flags

Feature flags (also called feature toggles) let you deploy code to production without making it visible or active for users.

The code is live in production. The feature is switched off. When the team is ready, they flip the flag — no new deployment needed.

A simple example

if (featureFlags.newDashboard === true) {
  renderNewDashboard();
} else {
  renderOldDashboard();
}

Why teams use feature flags

Deploy incomplete features safely — they are hidden from users
Roll out features to a percentage of users first (gradual rollout)
Instantly disable a feature if something goes wrong, without a full rollback deployment
Enable trunk-based development — unfinished work can be merged to main without affecting users

The trade-off

Feature flags add complexity. Old flags that are never cleaned up become permanent dead code. Teams often track flag debt the same way they track technical debt, and schedule regular cleanup cycles.

10. Pull Requests and Code Reviews

A pull request (PR) — called a merge request (MR) on GitLab — is a formal request to merge one branch into another.

In real teams, almost no code goes directly into main or develop without a pull request. PRs are how teams maintain quality, catch mistakes, and share knowledge across the codebase.

What a good pull request looks like

Small — focuses on one change. Easier to review and easier to revert.
Well described — explains what changed, why it changed, and how to test it.
Linked to a ticket — connects the change to a task in the project tracker.
Tested — includes or references relevant tests.

A poor PR is large, vague, touches many unrelated files, and is hard to review meaningfully.

The code review process

Developer opens a PR and assigns reviewers
Reviewers read the code and leave comments
Developer addresses feedback and pushes updates
Reviewers approve when satisfied
PR is merged

PR etiquette for beginners

Do not take review comments personally — the goal is better code, not criticism of you
Respond to every comment, even if just to confirm you have addressed it
Keep PRs small. A 50-line PR gets reviewed properly. A 2,000-line PR gets rubber-stamped.
Write a clear description — reviewers should not have to guess what you changed or why

11. What Happens After a Merge?

Many beginners ask: "Okay, I merged. Now what?"

Here is what typically happens after a PR is merged:

✅ Your feature branch is deleted (either automatically or manually)

✅ The CI/CD pipeline triggers automatically

✅ Automated tests run against the merged code

✅ If tests pass, the application is deployed to the appropriate environment (Dev, Staging, or Production — depending on which branch was merged into)

✅ Your teammates pull the latest changes before starting new work

✅ The ticket is marked as done in the project tracker

✅ Development continues on the next task

The merge is not the end of the story — it is the handoff point between development and delivery.

12. How This Looks on GitHub

Many beginners are comfortable with Git in the terminal but are not sure what to do on the GitHub interface. Here is a quick orientation:

Branches — visible under the repository's branch dropdown or the Branches tab. Every branch you push appears here.

Pull Requests — opened from the Pull Requests tab. Once you push a branch, GitHub often shows a prompt to open a PR directly.

Review comments — reviewers leave inline comments on specific lines of code inside the PR. You can reply, resolve, and push new commits to address them — all visible in the PR thread.

CI/CD status — automated test results appear directly in the PR as green checkmarks or red crosses. A PR with failing checks should not be merged until the issues are resolved.

Merge button — once reviews are approved and checks pass, the merge button becomes available. On protected branches, it may be restricted to certain team members.

Branch deletion — after merging, GitHub offers a one-click option to delete the feature branch. Use it. Stale branches are clutter.

Understanding the GitHub interface alongside your terminal workflow is what makes the full Git loop feel complete.

13. CI/CD and Branch Protection Rules

Continuous Integration and Continuous Delivery (CI/CD)

Continuous Integration (CI) — every push triggers an automated pipeline that runs tests, checks code style, and builds the project. If something fails, the team knows immediately.

Continuous Delivery/Deployment (CD) — after tests pass, the code is automatically deployed to an environment.

How CI/CD connects to branching

Event	Pipeline action
Push to any branch	Run tests
PR opened	Run tests + linting + security checks
Merge to `develop`	Deploy to dev/sandbox environment
Merge to `staging`	Deploy to staging environment
Merge to `main`	Deploy to production

Branch Protection Rules

On GitHub, these are configured under Settings → Branches. Common rules for main:

Require pull request before merging — no direct pushes allowed
Require approvals — at least one reviewer must approve
Require status checks to pass — CI tests must pass before merging
Require branches to be up to date — branch must be current with main
Restrict who can merge — only certain roles can merge to main

As a beginner joining a team, you may find that you cannot push to main directly. This is standard practice that protects everyone, including senior developers.

14. Where Does DevOps Fit?

Git is the starting point of the entire modern software delivery pipeline. Here is how a single git push can trigger a full deployment flow in a DevOps environment:

Developer writes code
        │
    git push
        │
      GitHub
        │
   CI Pipeline triggers
        │
   ┌────┴─────────────┐
   │                  │
 Tests run       Linting / SAST
   │                  │
   └────────┬─────────┘
            │
     Security scan
            │
     Build Docker image
            │
     Push to container registry
            │
     Deploy to Dev / Sandbox
            │
     Deploy to Staging
            │
     Manual approval (optional)
            │
     Deploy to Production

Every step in this pipeline is triggered by a Git event — a push, a merge, a tag. This is why branching strategy and DevOps pipeline design are inseparable. The branches you define determine what gets built, tested, and deployed, and when.

Understanding this flow is what takes a developer from "I know Git commands" to "I understand how software ships."

15. A Security Perspective

Git workflows are not just about code quality — they are part of your security posture. These are the practices that security-conscious teams implement:

Protect main — enforce branch protection rules so that no single person, however senior, can push directly to production.

Require pull request reviews — every change to a critical branch should have at least one other set of eyes on it.

Require signed commits — Git allows commits to be cryptographically signed, proving they came from a verified author. This matters in regulated industries.

Enable secret scanning — GitHub's secret scanning automatically detects accidentally committed credentials and alerts you before they are exposed.

Restrict force pushes — git push --force can rewrite history and erase evidence of changes. Disable it on protected branches.

Use least privilege for repository access — not everyone needs write access to every repository. Give team members the minimum permissions they need to do their work.

Audit logs — platforms like GitHub Enterprise provide audit logs of who did what and when. In regulated environments, this is a compliance requirement.

These practices apply whether you are a developer, a DevOps engineer, or a security professional. Git is infrastructure, and infrastructure needs to be secured.

16. Hotfix Scenario: Fixing Production Quickly

A hotfix is an urgent bug fix applied directly to the production codebase, bypassing the normal development flow.

When do you need a hotfix?

A critical bug is causing errors for live users
A security vulnerability has been discovered
A payment or data process is failing

You cannot wait for the next release cycle. You need to fix it now.

The hotfix workflow (Git Flow)

# Start from main (production code)
git switch main
git pull
git switch -c hotfix/fix-payment-timeout

# Make the minimal fix
git add .
git commit -m "Fix payment gateway timeout handling"

# Merge into main and tag
git switch main
git merge hotfix/fix-payment-timeout
git tag -a v2.1.1 -m "Hotfix: payment timeout"
git push origin main --tags

# Merge back into develop so the fix is not lost
git switch develop
git merge hotfix/fix-payment-timeout
git push origin develop

# Clean up
git branch -d hotfix/fix-payment-timeout

The hotfix workflow (GitHub Flow)

git switch main
git pull
git switch -c hotfix/fix-payment-timeout

# make the fix

git push -u origin hotfix/fix-payment-timeout
# open a PR directly into main
# get fast approval from a senior developer
# merge and deploy

Key principles for hotfixes

Keep the fix minimal — only change what is strictly necessary
Get a second pair of eyes even under pressure — a rushed fix can introduce a new problem
Merge the hotfix back into develop immediately, or it will be lost in the next release
Document what happened — production incidents should be reviewed and learned from

17. Which Strategy Do Real Companies Use?

Theory is useful, but it helps to see how these strategies map to real environments.

Organisation type	Common strategy
Early-stage startup	GitHub Flow
SaaS / web product	GitHub Flow or Trunk-Based Development
Open source project	GitHub Flow
Bank or financial institution	Git Flow or environment-based branching
Enterprise software	Git Flow
Large tech companies (FAANG)	Trunk-Based Development with feature flags
Regulated industry (healthcare, fintech)	Environment-based branching with strict approval gates

Most mature organisations have evolved their own hybrid. They take the core ideas from these strategies and adapt them to their team size, release cadence, compliance requirements, and tooling.

18. Which Branching Strategy Should Beginners Learn First?

Start with GitHub Flow

GitHub Flow is the most beginner-friendly strategy. It has minimal complexity, maps directly to how GitHub works, and teaches the core loop that underpins all other strategies:

branch → commit → pull request → review → merge → deploy

Once that loop feels natural, everything else is a variation on it.

A simple decision guide

Your situation	Recommended strategy
Solo project or learning	Simple branching or GitHub Flow
Small team, deploying often	GitHub Flow
Team with scheduled releases	Git Flow
Mature team, strong CI/CD	Trunk-Based Development
Team with distinct environments	Environment-based branching
Regulated or compliance-heavy environment	Git Flow + environment-based branching

19. Common Mistakes Teams Make

Long-lived feature branches — a branch that lives for two weeks accumulates painful merge conflicts. Keep branches short-lived. Break large features into smaller, mergeable pieces.

Pushing directly to main — without branch protection rules, this can and does happen. Even a small accidental push to main can break production for real users.

Skipping code review under pressure — "We're in a hurry, just merge it." Rushed merges are where most production incidents are born. A 10-minute review often prevents an hour of debugging.

Not merging hotfixes back to develop — the fix goes to production but is overwritten in the next release. Always merge hotfixes back to your integration branch immediately.

Inconsistent branch naming — without conventions, branches become impossible to track. Establish naming standards early and enforce them.

Letting feature flags pile up — flags that are never cleaned up become permanent dead code. Schedule regular flag cleanup as part of your development cycle.

Treating CI failures as optional — a red pipeline that nobody fixes is a pipeline nobody trusts. A failing build should be the team's top priority, not a notification to dismiss.

Ignoring the security basics — no branch protection, no secret scanning, no access controls. These are not optional extras — they are part of a professional Git workflow.

20. Final Thoughts

Branching strategies are not about following rules for their own sake. They exist to answer one practical question: how do we ship good code, safely, as a team?

The specifics will vary. But the underlying principles are consistent across every team and every strategy:

Protect your production environment
Review code before it merges
Keep changes small and frequent
Automate testing and deployment
Have a clear plan for when things go wrong
Treat security as part of the workflow, not an afterthought

Git is not just version control. It is the foundation of modern software delivery. Every pull request, code review, automated test, deployment pipeline, infrastructure change, and production release begins with a Git commit. Understanding Git workflows means understanding how modern software teams build, ship, and maintain reliable systems.

When you join a team and they say "we use trunk-based development with feature flags and deploy to production ten times a day," you will not just nod along. You will understand exactly what they mean, why it works, and how you fit into it.

In the next article, we'll build a complete CI/CD pipeline around these branching strategies using GitHub Actions — so you'll see exactly what happens after you push your code.

Missed the first article? Read Git for Beginners: A Complete Practical Guide to start from the beginning.

Found this helpful? Drop a ❤️ or leave a comment below.

Git for Beginners: A Complete Practical Guide to Version Control

Benjamin Tetteh — Wed, 08 Jul 2026 01:33:36 +0000

Whether you're writing your first line of code, learning DevOps, cybersecurity, cloud, data, or simply revising your notes — this guide will help you understand Git from the ground up.

Introduction

If you are new to tech, one tool you will meet again and again is Git.

At first, Git can feel confusing because it introduces terms like commits, branches, staging, pushing, pulling, merging, and remote repositories.

But once you understand the basics, Git becomes one of the most useful tools in your workflow. It helps you track changes, collaborate with others, recover from mistakes, and manage your projects professionally.

This article is written for beginners and for anyone who wants a clear revision guide.

What is Git?
Why Git Matters
Git vs GitHub
Key Git Concepts
Installing Git
Configuring Git
Creating Your First Repository
The Basic Git Workflow
Working with Branches
Merging and Rebasing
Working with Remote Repositories
Understanding git push origin main
The .gitignore File
Git Security: Do Not Commit Secrets
Undoing Mistakes
A Simple Daily Git Workflow
What Is a Pull Request?
Useful Git Commands Cheat Sheet
Common Beginner Mistakes
Next Steps

1. What is Git?

Git is a distributed version control system — a tool that tracks changes to your files over time so you can save different versions of your project and return to them when needed.

Think of Git like a detailed save system for your project. Without it, you may end up with files like:

project_final.js
project_final_v2.js
project_final_real_final.js
project_ACTUALLY_final.js

Git helps you avoid that mess by keeping a clean history of every change.

Git was created by Linus Torvalds in 2005 — the same person who created the Linux kernel. Today, it is one of the most widely used tools in software development and modern technology work.

2. Why Git Matters

Git is important because it gives you:

History — See what changed, when it changed, and who made the change.

Collaboration — Multiple people can work on the same project without overwriting each other's work.

Backup — Push your work to platforms like GitHub or GitLab so it is not only stored on your computer.

Experimentation — Create a separate branch to test a new idea without breaking your main project.

Accountability — Understand why a change was made, not just what changed.

Whether you are a solo developer, DevOps engineer, cloud engineer, cybersecurity analyst, or part of a large engineering team, Git is an essential skill.

3. Git vs GitHub

Many beginners confuse Git and GitHub. They are related, but they are not the same thing.

Git is the tool installed on your computer. It tracks changes in your project locally.

GitHub is an online platform where you can store Git repositories, collaborate with others, and share your code publicly or privately.

A helpful way to think about it:

Git is the tool that tracks your project history. GitHub is the online home where you can upload and collaborate on that project.

Other platforms similar to GitHub include GitLab, Bitbucket, and Azure DevOps.

4. Key Git Concepts

Before using Git commands, it helps to understand the vocabulary.

Term	Meaning
Repository	A project folder tracked by Git
Commit	A saved snapshot of your changes
Branch	A separate line of development
Merge	Combining changes from one branch into another
Remote	A version of your repository hosted online
Clone	Downloading a remote repository to your computer
Push	Uploading your local commits to a remote repository
Pull	Downloading remote changes into your local repository
Staging Area	A holding area where you prepare changes before committing
HEAD	A pointer to your current commit or branch

5. Installing Git

To check if Git is already installed, open your terminal and run:

git --version
# Example output: git version 2.43.0

macOS

Git is often pre-installed on macOS. You can also install it via Homebrew:

brew install git

Windows

Download the installer from git-scm.com. The installer also includes Git Bash, a terminal you can use to run Git commands.

Linux (Ubuntu/Debian)

sudo apt update
sudo apt install git

6. Configuring Git

Before making your first commit, tell Git who you are. This information is attached to every commit you make.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

To check your configuration:

git config --global --list

You can also set your preferred text editor. For VS Code:

git config --global core.editor "code --wait"

7. Creating Your First Repository

There are two common ways to start working with Git.

Option 1: Start a New Project

mkdir my-first-git-project
cd my-first-git-project
git init

git init creates a hidden .git folder inside your project. That folder stores all of Git's tracking information — do not delete it unless you intentionally want to remove Git tracking from the project.

Option 2: Clone an Existing Repository

If a project already exists on GitHub or another platform:

git clone https://github.com/username/repository-name.git
cd repository-name

8. The Basic Git Workflow

The core Git workflow has three stages:

Working Directory  →  Staging Area  →  Repository
   (edit files)        (git add)        (git commit)

Step 1: Make changes

Create, edit, or delete files in your project as normal.

Step 2: Check the status

git status

This shows which files have changed, which are untracked, and which are staged and ready to commit.

Step 3: Stage your changes

# Stage a specific file
git add filename.txt

# Stage all changes at once
git add .

Staging lets you choose exactly which changes to include in your next commit.

Step 4: Commit your changes

git commit -m "Add README file"

A commit is a saved checkpoint. Write clear, specific messages so your history is useful later.

Good commit messages:

git commit -m "Add login page"
git commit -m "Fix broken navigation link"
git commit -m "Update project documentation"

Avoid vague messages like "stuff", "changes", or "update".

Step 5: View your history

git log

# For a cleaner, one-line view
git log --oneline

9. Working with Branches

Branches allow you to work on features, bug fixes, or experiments without affecting your main project.

main:     A --- B --- C
                      \
feature:               D --- E

The main branch holds the stable version of your project. The feature branch holds work in progress, completely isolated.

Create and switch to a branch

# Create a branch
git branch feature/add-login

# Switch to it
git checkout feature/add-login

# Or create and switch in one step
git checkout -b feature/add-login

# With newer Git versions (2.23+)
git switch -c feature/add-login

List branches

git branch        # local branches only
git branch -a     # local and remote branches

Delete a branch after merging

git branch -d feature/add-login

10. Merging and Rebasing

Once your branch is ready, you need to bring those changes back into main.

Merging

Switch to the branch you want to merge into, then merge:

git switch main
git merge feature/add-login

Handling Merge Conflicts

A merge conflict happens when Git cannot automatically combine changes — for example, when two people edit the same line in the same file. Git will mark the conflicting section:

<<<<<<< HEAD
This is the version from main
=======
This is the version from your feature branch
>>>>>>> feature/add-login

To resolve it:

Open the file and choose the correct final version
Remove the conflict markers (<<<<<<<, =======, >>>>>>>)
Stage the resolved file
Commit the result

git add filename.txt
git commit -m "Resolve merge conflict"

Merge conflicts are normal. They are not a sign that you have done something wrong.

Rebasing

Rebasing is an alternative to merging that replays your branch's commits on top of another branch, producing a cleaner, linear history.

git switch feature/add-login
git rebase main

As a beginner, do not worry about mastering rebase immediately. Also avoid rebasing branches that other people are already working on, since it rewrites commit history and can cause problems for collaborators.

11. Working with Remote Repositories

A remote repository is an online version of your project, hosted on GitHub, GitLab, Bitbucket, Azure DevOps, or similar platforms.

Connect your local project to a remote

git remote add origin https://github.com/yourusername/your-repo.git

Check your remotes:

git remote -v

Push your code

# First push
git push -u origin main

# Subsequent pushes
git push

Pull and fetch

# Download and apply remote changes to your current branch
git pull

# Download remote updates without applying them
git fetch

Think of it this way: git fetch checks what is new online. git pull checks what is new and brings it into your current branch.

12. Understanding `git push origin main`

Many beginners see this command and wonder what each part means.

git push origin main

Here is the breakdown:

git push — upload your local commits to a remote repository.

origin — the name of the remote. By default, Git uses origin when you clone a repo or add a remote, but it is just a name, not something special. You could name it anything:

git remote add github https://github.com/yourusername/your-repo.git
git push github main

main — the branch you are pushing. Most modern repos use main as the default, but some use master, dev, or staging.

So git push origin main simply means: "Push my local main branch to the remote called origin."

The -u flag sets an upstream link:

git push -u origin main

After this, Git remembers the connection between your local main and the remote main, so future pushes and pulls can be run without specifying the remote and branch each time.

To check your current branch:

git branch

To check your remote names:

git remote -v

13. The `.gitignore` File

Not everything in your project should be tracked by Git. Common files to exclude include dependency folders, environment files, logs, build outputs, and OS-generated files.

Create a .gitignore file in your project root:

touch .gitignore

A practical example:

# Dependencies
node_modules/

# Environment variables
.env
.env.local

# Logs
*.log

# macOS files
.DS_Store

# Windows files
Thumbs.db

# Build output
dist/
build/

Git will ignore everything listed here. You can find ready-made templates for different languages and frameworks at gitignore.io.

Set up your .gitignore before your first commit — not after.

14. Git Security: Do Not Commit Secrets

This is one of the most important habits to build early.

Never commit sensitive information such as:

Passwords
API keys
Access tokens
Private keys
Database credentials
Cloud credentials
.env files

Example of what not to commit:

DATABASE_PASSWORD=mysecretpassword
AWS_SECRET_ACCESS_KEY=examplekey
GITHUB_TOKEN=exampletoken

If you accidentally commit a secret, simply deleting the file later is not enough. Git keeps the full history, so the secret remains visible in past commits. You should immediately rotate or revoke the exposed credential.

Add these to your .gitignore as standard practice:

.env
*.pem
*.key

This is especially relevant if you are learning cloud, DevOps, or cybersecurity — exposed credentials are one of the most common causes of security incidents.

15. Undoing Mistakes

Everyone makes mistakes. Git gives you several ways to recover.

Unstage a file

git restore --staged filename.txt

Discard changes in your working directory

# Careful: this permanently removes uncommitted changes
git restore filename.txt

Fix the last commit message

git commit --amend -m "Corrected commit message"

Only use this if you have not already pushed the commit.

Undo the last commit but keep the changes

git reset --soft HEAD~1

Undo the last commit and discard the changes

# ⚠️ Destructive — your work will be lost
git reset --hard HEAD~1

Safely undo a pushed commit

git revert commit-id

git revert creates a new commit that reverses the target commit. This is the safe option for shared repositories because it does not rewrite history.

16. A Simple Daily Git Workflow

Here is a practical workflow you can use on real projects right now.

Get the latest changes:

git pull

Create a new branch for your work:

git switch -c feature/update-readme

Make your changes, then check status:

git status

Stage and commit:

git add .
git commit -m "Update README documentation"

Push your branch:

git push -u origin feature/update-readme

Then open a pull request on GitHub or your preferred platform for review before merging.

17. What Is a Pull Request?

A pull request (PR) is a request to merge your branch into another branch, usually main.

Pull requests help teams:

Review code before it is merged
Discuss proposed changes
Run automated tests
Catch mistakes early
Keep the main branch stable and deployable

Even if you work alone, pull requests are a good habit. They give you a chance to review your own work before it becomes part of the project history.

18. Useful Git Commands Cheat Sheet

# Setup
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

# Starting out
git init
git clone <url>

# Core workflow
git status
git add <file>
git add .
git commit -m "message"
git log --oneline

# Branching
git branch
git checkout -b <branch-name>
git switch -c <branch-name>
git switch main
git merge <branch-name>
git branch -d <branch-name>

# Remote repositories
git remote -v
git remote add origin <url>
git push -u origin main
git push
git pull
git fetch

# Inspecting changes
git diff
git diff --staged
git show <commit-id>

# Undoing changes
git restore --staged <file>
git restore <file>
git reset --soft HEAD~1
git reset --hard HEAD~1
git revert <commit-id>

19. Common Beginner Mistakes

Committing directly to main — In team projects, always work on a separate branch and merge through a pull request. Keep main stable.

Writing vague commit messages — "stuff" and "changes" tell future-you nothing. Write messages like "Fix login form validation" instead.

Forgetting .gitignore — Set it up before your first commit to avoid accidentally tracking node_modules/, .env files, or build folders.

Using git reset --hard carelessly — This can permanently remove your work. When in doubt, use --soft or git stash to park your changes safely.

Force-pushing to shared branches — git push --force can overwrite your teammates' commits. Only use it on private branches when you fully understand the risk.

Not pulling before starting work — Always run git pull before beginning new work on a shared project to reduce merge conflicts.

Committing secrets — As covered above, never commit passwords, API keys, or credentials. Set up .gitignore and get into this habit from day one.

20. Next Steps

You now have a solid foundation in Git. Here is where to go from here:

Practice — Use Git on a small personal project. Even solo work benefits from Git habits.
GitHub — Create an account at github.com and push your first repository.
Interactive learning — Try Learn Git Branching, a free visual tool that makes branching and rebasing click.
Advanced commands — Explore git stash, git cherry-pick, git bisect, and Git hooks when you are ready.
Conventional commits — A standard for writing consistent, meaningful commit messages: conventionalcommits.org.

The goal is not to memorise every Git command. The goal is to understand the workflow:

Make changes. Review changes. Stage changes. Commit changes. Push changes. Collaborate safely.

Once that clicks, Git stops being intimidating and starts being one of your most reliable tools.

In the next article, we'll explore how teams manage code in practical dev environments using real-world git branching strategies.

Found this helpful? Drop a ❤️ or leave a comment below with any questions. Your feedback is always welcome.

Your AI Writes Code Fast. Here’s How to Check It Before Shipping

Benjamin Tetteh — Sat, 23 May 2026 14:55:54 +0000

A beginner-friendly guide to building an automated security pipeline with GitHub Actions — from zero, in under an hour.

Here is a scenario that plays out constantly in the world of AI-assisted development.

You build something. It works. You are excited. It is late. You run through a mental checklist — or most of it — and you push to production. Three items got checked. Two did not. You tell yourself you will fix it tomorrow.

Tomorrow, you are already building the next thing.

This is not a discipline problem. This is a systems problem. Checklists depend on human memory and human energy, and both of those fail under shipping pressure. Automation does not forget. It does not get tired. It does not skip the last two items because it is midnight and the feature finally works.

That is the entire argument for automated security gates. Not that you are careless — but that no human is perfectly consistent, and consistency is exactly what security requires.

If you read the first article in this series about vibe coding and security, you saw the Moltbook breach — a weekend-built app that exposed 1.5 million API tokens and 35,000 emails because a few security defaults were never configured. The checklist at the end of that article is a good start. This article is about making that checklist run automatically, every single time you push code, without you having to think about it.

One of the tools that makes this possible is GitHub Actions.

What Is GitHub Actions, Really?

If you have a GitHub repository — a place where your code lives online — GitHub Actions is a system that lets you run automatic tasks whenever something happens in that repository.

Something happens could mean:

You push new code
You open a pull request
You merge into your main branch
You create a new release

When that trigger fires, GitHub spins up a temporary computer in the cloud, runs whatever instructions you give it, and reports back whether everything passed or failed. You do not manage that computer. You do not pay for it beyond GitHub's free tier limits. It just runs.

Those instructions live in a file called a workflow — a plain text file written in a format called YAML that lives inside your repository at .github/workflows/. You can have as many workflow files as you want, each doing different things.

Here is the simplest possible workflow to make this concrete:

# .github/workflows/hello.yml
name: My First Workflow

on:
  push:              # Run this whenever code is pushed
    branches: [main]

jobs:
  say-hello:
    runs-on: ubuntu-latest    # Use a fresh Linux computer

    steps:
      - name: Print a message
        run: echo "Code was pushed. The pipeline is running."

That is it. A name, a trigger, a machine to run on, and steps to execute. Everything we build in this article follows exactly that same structure — we are just swapping echo "hello" for real security tools.

Why This Matters More for Vibe Coders

Traditional developers have something vibe coders are still building: years of conditioned habits. The reflex to check for exposed secrets before pushing. The instinct to verify that a new endpoint requires authentication. The muscle memory of running a linter before committing.

Those habits took years to form. AI-assisted development is compressing timelines so fast that many people are shipping production apps before those habits exist.

Automated security gates close that gap. They are not a replacement for understanding security — but they are a safety net that catches common mistakes before they reach production. Think of it less like a replacement for a trained developer and more like spell-check. Spell-check does not make you a better writer, but it catches the embarrassing errors while you focus on the ideas.

The goal of this article is to give you a working security pipeline by the end. Not a theoretical one. An actual .yml file you can drop into any project today.

How to Set It Up: From Zero

You need two things before anything else:

A GitHub repository. If your project is not on GitHub yet, create a free account at github.com and push your code there. GitHub has a beginner guide for this if you have never done it.

A .github/workflows/ folder in your repository. You can create this directly on GitHub by clicking "Add file" inside your repository, or in your code editor locally. GitHub Actions picks up any .yml file inside that folder automatically.

That is genuinely all the setup required. No servers, no accounts, no credit cards.

Building the Pipeline: Layer by Layer

We are going to build one workflow file that runs three security checks in sequence. Each check catches a different category of problem. You can start with just one and add the others when you are ready — the pipeline is modular by design.

Here is the full picture of what we are building:

On every push to main:
│
├── Step 1: Gitleaks — scan for exposed secrets and API keys
├── Step 2: Semgrep — scan for insecure code patterns  
└── Step 3: Snyk or CodeQL — scan for vulnerable dependencies

Each scan catches a different category of problem — secrets, insecure code patterns, and vulnerable dependencies. If any one fails, GitHub stops the pipeline before the code reaches production. You get an email, a red badge on your repository, and a detailed report showing exactly what was found and where.

The diagram below maps how the pieces connect. Think of it as your security assembly line — every push goes through it automatically, without you having to remember to run anything manually.

Let's build each layer.

Step 1: Catching Exposed Secrets with Gitleaks

Gitleaks scans your codebase for anything that looks like a secret — API keys, database passwords, tokens, private keys. It knows the patterns for hundreds of services: AWS, OpenAI, Stripe, Supabase, GitHub itself.

This is the Moltbook failure in automated form. If Gitleaks had been running on that repository, the exposed Supabase key would have been flagged before the first commit ever reached production.

Create a file at .github/workflows/security.yml and add this:

name: Security Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  secret-scan:
    name: Scan for Exposed Secrets
    runs-on: ubuntu-latest

    steps:
      # Step 1: Download your code onto the pipeline machine
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0    # Scan the full git history, not just the latest commit

      # Step 2: Run Gitleaks
      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}  # GitHub provides this automatically

What this does in plain English: Every time you push to main or open a pull request, GitHub downloads your code onto a fresh machine and runs Gitleaks across every file and every commit in your history. If it finds anything that looks like a secret, the pipeline fails and you get a detailed report showing exactly which file and which line contains the problem.

The fetch-depth: 0 line is important — without it, Gitleaks only scans your most recent commit. With it, it scans your entire history, which catches secrets that were committed weeks ago and never removed.

Step 2: Catching Insecure Code Patterns with Semgrep

Gitleaks catches secrets. Semgrep catches insecure patterns — things like SQL queries that trust user input directly, authentication checks that can be bypassed, or configuration values that should never be public.

Semgrep has a free tier and a library of pre-written rules maintained by security researchers. You do not need to write the rules yourself. You just point it at a ruleset and it does the work.

Add this job to the same security.yml file, underneath the secret-scan job:

  code-scan:
    name: Scan for Insecure Code Patterns
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Run Semgrep
        uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/secrets
            p/javascript
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

What this does in plain English: Semgrep reads through your code looking for patterns that security researchers have identified as dangerous. The p/security-audit ruleset covers common vulnerabilities. The p/javascript ruleset adds JavaScript and TypeScript-specific checks. If your project uses Python, swap p/javascript for p/python. If it uses both, list both.

To get your SEMGREP_APP_TOKEN, create a free account at semgrep.dev, go to Settings, and copy your token. Then in your GitHub repository, go to Settings → Secrets and Variables → Actions → New Repository Secret, and paste it there as SEMGREP_APP_TOKEN. GitHub stores it encrypted and injects it into the pipeline automatically — your token never appears in your code.

Step 3: Catching Vulnerable Dependencies

Your app almost certainly uses packages written by other people — React, Express, Axios, whichever libraries your AI reached for. Those packages sometimes contain known security vulnerabilities. You did not write the vulnerability, but if it is in your app, it is your problem.

You have two solid options here depending on your comfort level.

Option A: Snyk (beginner-friendly, generous free tier)

Snyk is built for accessibility. It has a VS Code extension, a web dashboard, and a GitHub integration that makes setup straightforward. Add this job to your workflow:

  dependency-scan-snyk:
    name: Scan Dependencies with Snyk
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Run Snyk
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high  # Only fail on high and critical issues

Get your SNYK_TOKEN by creating a free account at snyk.io, going to Account Settings, and copying your Auth Token. Add it to GitHub Secrets the same way you added the Semgrep token.

Option B: CodeQL (built into GitHub, no extra account needed)

CodeQL is GitHub's own static analysis engine. It is more powerful than Snyk for code-level analysis, slightly more complex to configure, but requires no external account. Replace the Snyk job with this:

  dependency-scan-codeql:
    name: Scan with CodeQL
    runs-on: ubuntu-latest
    permissions:
      security-events: write

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Initialize CodeQL
        uses: github/codeql-action/init@v3
        with:
          languages: javascript  # Change to python, ruby, etc. if needed

      - name: Perform Analysis
        uses: github/codeql-action/analyze@v3

Results from CodeQL appear directly in your GitHub repository under the Security tab — no external dashboard needed.

Which should you choose? Start with Snyk if you want immediate, readable results in plain English. Move to CodeQL when you want deeper analysis integrated directly into GitHub. There is no wrong answer — running either is infinitely better than running neither.

The Complete Pipeline

Here is the full security.yml file with all three jobs combined. Drop this into .github/workflows/security.yml in any project and your automated security gate is live:

name: Security Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  secret-scan:
    name: Scan for Exposed Secrets
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  code-scan:
    name: Scan for Insecure Code Patterns
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/secrets
            p/javascript
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

  dependency-scan:
    name: Scan Dependencies
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

Three jobs. Three categories of risk. All running automatically on every push.

Reading the Results

When a pipeline run completes, GitHub shows you one of two things:

Green checkmarks — all scans passed. You are clear to merge or deploy.

A red X — something was found. Click into the failed job, read the output, and it will tell you exactly what was flagged, in which file, and often why it is a problem.

Do not treat a red X as a failure. Treat it as the system working. The pipeline caught something before it reached production — which is precisely what it is there to do.

One Thing to Do Right Now

If setting up all three jobs at once feels like too much, start with just Gitleaks. Create the .github/workflows/security.yml file with only the secret-scan job. Push it to your repository. Watch it run.

Once you have seen a pipeline run — green or red — the rest becomes much less intimidating. The structure is always the same: trigger, machine, steps. You are just swapping in different tools.

Security automation is not a one-time setup. It is a habit that compounds. Every project you start from now on gets the pipeline from day one. Every collaborator who opens a pull request gets their code scanned automatically. Every push gets checked before it ships.

That is what consistency looks like when you remove the human from the loop.

Where This Fits in Your Stack

This pipeline covers the code layer — what is in your repository. Combined with the platform-level defaults from the previous article — RLS enabled, rate limiting on, secrets in the right environment variables — you now have security running at two levels simultaneously:

Before the code ships → GitHub Actions catches it in the pipeline
After the code ships → Platform defaults limit the damage if something slips through

Neither layer is perfect on its own. Together they cover the vast majority of the failures that appear in real-world breaches — including the ones that made Moltbook a case study.

You did not need a Computer Science degree to set this up. You needed a .github/workflows/ folder and about an hour.

The next article in this series covers something slightly different: what to do when the AI itself is part of your pipeline — and the new attack surface that creates.

Found this useful? Share it with someone who just shipped their first repo. The best time to add a security pipeline is before the first breach. The second best time is right now.

The Hidden Layer Every AI Developer Must Learn

Benjamin Tetteh — Fri, 22 May 2026 12:22:52 +0000

Late January 2026. A developer ships a social network over a weekend. No traditional code written — just prompts, a vision, and an AI that turned ideas into a working product in days. The platform goes viral. Andrej Karpathy, OpenAI co-founder, calls it "the most incredible sci-fi takeoff-adjacent thing I have seen recently."

Then a security researcher opens the browser's developer tools.
Within minutes, they find an API key sitting in plain JavaScript — visible to anyone who knows how to press F12. They use it to query the production database. No login required. No special tools. Just a simple command and a coffee.

What comes back: 1.5 million API authentication tokens. 35,000 email addresses. Thousands of private messages. The entire platform — every agent, every credential, every conversation — sitting wide open.

The platform was called Moltbook. The fix, when it came, took two SQL statements.

This is not a story about a bad developer. It is a story about a gap that AI does not fill automatically — and what you can do about it before you ship.

The Illusion That Catches Everyone

A few years ago, building software required crossing a painful barrier. You had to learn syntax, frameworks, databases, APIs, Git, deployment — and break things repeatedly along the way. For most people outside tech, software engineering felt like a locked room with a very small door.

Then AI arrived.

Now someone with little traditional programming experience can build a SaaS app over a weekend, connect a database to a frontend, integrate payments, and deploy an API — all from prompts. That shift is extraordinary, and I think it is genuinely amazing. I am a vibe coder too. I understand the excitement of watching an idea move from imagination to a working product faster than ever before.

But there is a dangerous illusion forming around AI-generated software: If the app works, people assume it's safe. Those are not the same thing.

A beautifully designed application can still expose private user data, leak API keys, allow unauthorized access, and accidentally disable database protections — all while the UI looks polished and the login flow works perfectly. Security problems live underneath visible functionality. That is exactly what happened with Moltbook.

What AI Gets Right, and What It Quietly Skips

AI is very good at helping you build the happy path — the feature works, the button responds, the API returns data, the page renders. That part is genuinely impressive.
Security lives in the unhappy paths:

What if someone queries your database without logging in?
What if an attacker manipulates a request from the browser?
What if your API keys are visible in the page source?
What if someone calls your registration endpoint ten thousand times in a loop?

Experienced developers ask these questions automatically. Not because they are smarter — but because they built the habit slowly, over years of debugging painful issues, reading post-mortems, and making mistakes in lower-stakes environments.

AI compresses the implementation timeline dramatically. It does not compress the experience required to ask the right security questions. That gap is where breaches happen.

And to be clear: this is not only a beginner problem. Even experienced developers can become overconfident when AI accelerates output speed. Because AI-generated code often looks extremely convincing. The explanations sound confident. The architecture appears plausible. The feature functions correctly.

But plausible code is not the same as safe code.

The Moltbook Breakdown: What Actually Went Wrong

Moltbook was built on Supabase — a popular, well-documented backend service that is excellent for fast development. Supabase is designed to work with a public API key exposed on the client side. That is intentional and not, by itself, a security failure.

The security failure is what you configure that key to be able to do.

Supabase ships with a feature called Row-Level Security — a database setting that ensures users can only access their own data. It is not enabled by default. You have to turn it on. And if you are vibe coding and the AI generates a working backend without you asking about security, there is a good chance that step never comes up.

At Moltbook, it didn't.

The result: anyone with basic technical knowledge could query the entire production database — every user's credentials, private messages, and authentication tokens — using the key sitting in plain sight on the website. Write access was also open, meaning an attacker could have edited any post on the platform without logging in.

The founder's public statement captured the situation honestly: "I didn't write a single line of code for Moltbook. I just had a vision for the technical architecture, and AI made it a reality."

The AI made a working platform. It did not make a secure one.

It Is Not Just Moltbook

Six months before Moltbook, security researchers at Wiz found a critical vulnerability in Base44 — a vibe coding platform used by actual enterprises to build internal HR systems, customer databases, and knowledge bases containing sensitive employee data.

The flaw was shockingly simple: two API endpoints for registering and verifying users required no authentication whatsoever. Using only a value visible in the app's public URL, a researcher could create a verified account inside any private enterprise application on the platform — bypassing SSO and every other access control entirely.

Here is the detail that changes the conversation: Base44 builders did not write that vulnerable endpoint. The platform did. Individual developers had no visibility into the flaw. This is the second dimension of vibe coding security risk that almost nobody talks about. The first is what AI generates when you prompt it. The second is what the platform you are building on introduces independently of your code.

Both matter. Both can be addressed.

Security in Plain English

One reason security feels intimidating is because the terminology sounds abstract and technical. Most of it isn't. Here is a plain-English translation of the concepts that come up most often:

Term	What It Actually Means
Authentication	Verifying who someone is
Authorization	Deciding what they are allowed to access
API Key	A secret password your app uses to talk to another service
Row-Level Security	Preventing users from reading other users' data in your database
Rate Limiting	Stopping someone from making thousands of requests in a loop
Secret Scanning	Automatically detecting exposed passwords or keys in your code
Least Privilege	Only giving a system the minimum access it actually needs
Input Validation	Making sure users can't send dangerous or unexpected data

Security is not magic. Most of the time it is about reducing obvious mistakes, limiting damage when mistakes happen, and protecting user trust. That's it.

The Five Things AI Consistently Misses

These are the patterns that show up repeatedly in AI-generated code — not as exotic edge cases, but as defaults. Each one comes with a practical fix.

1. API Keys Exposed in Client-Side Code
When you ask AI to connect your app to an external service, it will often put the credentials directly in the frontend code. Frontend code is public. Anyone can open the browser's developer tools and find it. Automated scanners crawl the web looking for exactly this.

The fix: Run Gitleaks before you push code. It scans for secrets and blocks the commit if it finds any. GitHub's built-in secret scanning does the same thing automatically on public repositories — no setup required.

2. Row-Level Security Not Enabled
This is the Moltbook failure. AI can generate a complete Supabase schema without ever enabling RLS, because RLS requires understanding your data access model — who should see what — and AI often skips that reasoning unless you ask for it explicitly.

The fix: In your Supabase dashboard, check that RLS is enabled on every table containing user data. Then write policies that define exactly who can access each row. The Supabase documentation has a beginner-friendly walkthrough that takes about twenty minutes.

-- Enable RLS on a table
ALTER TABLE agents ENABLE ROW LEVEL SECURITY;

-- Users can only read their own records
CREATE POLICY "owner_only"
ON agents FOR SELECT
USING (auth.uid() = owner_id);

3. API Endpoints With No Authentication
AI generates routes that respond to requests. Whether it adds authentication to those routes depends on whether you asked — and whether the AI remembered your earlier requirements by the time it got to that file.

The fix: Go through every API route and ask: what happens if someone calls this without logging in? Tools like Bearer scan your codebase and flag unprotected routes for free. Better still, apply authentication at the middleware layer so every route is protected by default.

4. Secrets on the Wrong Side of the App
Many AI tools know not to hardcode secrets and will suggest environment variables. What they sometimes miss is the difference between variables available to the client (public) and variables available only to the server (private).

In Next.js, any variable prefixed with NEXT_PUBLIC_ is bundled into the client JavaScript and visible to everyone. Your OpenAI API key, Stripe secret key, and database credentials should never have that prefix.

The fix: Search your project for NEXT_PUBLIC_ and verify that nothing sensitive uses it. Server-only secrets get no prefix. Public configuration values — like your Supabase URL — can use the prefix safely, but only if RLS is properly configured.

5. No Rate Limiting
AI generates endpoints that respond to requests. It does not add rate limiting unless you ask. This means your registration endpoint, login endpoint, and data endpoints will accept unlimited requests from anyone.

At Moltbook, this allowed a single bot to create 500,000 fake accounts. The same pattern can be used to exhaust your API quota overnight and run up a bill that ends your project.

The fix: If you are on Vercel, enable rate limiting in your project's security settings — it takes five minutes and requires no code. For Supabase, the same option exists under Project Settings. Do this before you go public.

The Mistake Almost Everyone Makes: "I'll Secure It Later"

This mindset is understandable. When you are learning, shipping feels difficult enough already. Security can feel like an advanced topic for a future version of yourself.

The problem is that insecure architecture hardens very quickly. Once real users arrive, technical debt compounds, insecure patterns spread through the codebase, and leaked secrets cannot be unexposed. The Moltbook breach did not happen because the founder planned to fix security later. It happened because the platform went viral before that moment came.

Security is not a decorative layer added at the end. It is part of the design. That does not mean you need perfection before you launch. It means security awareness needs to begin at the same time as everything else.

Your Security Stack, Kept Simple

You do not need to become a security engineer. You need a short checklist and the discipline to run it.

Start here — these take under an hour total:

GitHub Secret Scanning — enabled by default on public repos, catches exposed keys automatically
Gitleaks — run it locally before pushing; blocks commits containing secrets
Supabase RLS — enable it on every table in your dashboard; follow the docs walkthrough
Vercel Rate Limiting — enable it in your project settings before going public
Snyk free tier — scans your dependencies for known vulnerabilities; integrates with VS Code

When your project gets more serious:

Semgrep — static analysis that catches insecure code patterns in CI
CodeQL — deeper analysis integrated into your GitHub pull request workflow
Pre-commit hooks — stop dangerous commits before they leave your machine

Think of these tools as an automated second opinion. If AI is your fast-moving junior developer, security tooling is your automated reviewer. That combination is far safer than relying on intuition alone — especially when moving quickly.

One More Thing: Ask Your AI

One of the most underused techniques in vibe coding security is simply prompting for it. Before you ship any feature that touches user data, try this:

"Review this code for security issues. Check whether any credentials are exposed in client-side code, whether database tables have Row-Level Security enabled, whether API endpoints require authentication, and whether there is rate limiting on registration and data endpoints."

AI is quite capable of security review when asked explicitly. The problem is that it does not apply that review automatically. Make it a habit to ask. It takes thirty seconds and it will catch things.

A Fair Hearing for the Critics

The people arguing against vibe coding are not wrong. They are pointing at a real pattern: AI generates working code that skips assumptions a trained developer would never skip. Moltbook and Base44 are valid evidence of that.

But the conclusion — that people without traditional coding backgrounds should not build things — does not follow. What the evidence actually shows is that vibe coding without security awareness is dangerous. That is a different claim, and it has a different solution.

The Wiz Research team — the same team that found both breaches — put it clearly: the opportunity is not to slow down vibe coding but to elevate it. AI tools that generate Supabase backends can enable RLS by default. Deployment platforms can scan for exposed credentials automatically. The infrastructure for secure-by-default vibe coding exists. It just is not the default yet.

Until it is, the gap has to be filled by builders who know what to check — and who check it.

Before You Ship

[ ] No API keys or secrets in frontend code
[ ] Gitleaks run before pushing to the repository
[ ] Row-Level Security enabled on every database table with user data
[ ] Every API endpoint requires authentication, or is explicitly marked public
[ ] Rate limiting enabled on registration and data endpoints
[ ] NEXT_PUBLIC_ prefix checked — nothing sensitive uses it
[ ] Snyk or equivalent scanned your dependencies
[ ] Asked AI to review your code specifically for security issues
[ ] Opened the browser dev tools and checked what a stranger can see

AI is making software creation more accessible than ever. More people building means more innovation, more creativity, more diverse voices entering technology. That is a genuinely good thing.

But software engineering has always been more than generating working code. There is a layer underneath every application — trust, security, permissions, responsibility — that still belongs to the person who shipped it.

You do not need to learn everything before you build. You just need to know the layer exists, and make a habit of checking it.

The checklist is above. The tools are free. The rest is discipline. The future of software may be AI-assisted. But responsibility is still human.

Found this useful? Share it with someone who just shipped their first AI-built app. The person who needs it most is usually the one who doesn't know they need it yet.

Building My First AWS VPC and EC2 Environment with Terraform: A Beginner-Friendly Guide for Career Changers

Benjamin Tetteh — Fri, 08 May 2026 20:47:37 +0000

Not long ago, terms like “VPC,” “subnet,” and “Terraform” would have made my eyes glaze over. While my background wasn’t originally rooted in cloud engineering, I’ve always been fascinated by how modern infrastructure is designed, automated, and scaled behind the scenes.

Now, partway through my DevOps journey, I’ve gone from simply reading about cloud infrastructure to actually building it, using Terraform to provision a fully functional AWS network entirely through code.

If you're reading this while sitting at a career crossroads — maybe you're a teacher, an accountant, a customer service rep, or anyone wondering "can I really break into tech?" I want this post to be your proof that yes, you absolutely can.

Before we touch any code...

Let's understand why everything exists. Tools make a lot more sense that way. Think of it like building a neighbourhood. Imagine you're a city planner given a plot of land. Your job is to:

Draw the boundary of the land — this is your VPC (Virtual Private Cloud). It defines your space in AWS. Nothing gets in or out unless you say so.

Divide the land into zones — some areas are public (like a shopping street anyone can visit) and some are private (like a gated estate — no outsiders allowed).

Build a gate to the outside world — this is the Internet Gateway (IGW). The single controlled entrance between your network and the internet.

Set the traffic rules — Route Tables tell your network traffic exactly where to go, like road signs.

Construct buildings inside the neighbourhood — these are your EC2 instances, the virtual servers that actually run applications and services.

Hire security guards for the buildings — these are your Security Groups, which act like firewalls controlling who can access your servers and through which doors (ports).

💡 Why Terraform instead of clicking around in AWS?
Clicking in the AWS console is slow, hard to repeat, and easy to mess up. Terraform lets you write your infrastructure as code — describe what you want, run one command, and it builds everything consistently every time. This is called Infrastructure as Code (IaC) and employers actively look for this skill.

The project structure

terraform-vpc/
├── main.tf       # The blueprint — everything to build
├── variables.tf  # The settings — values we can change
└── outputs.tf    # The receipt — shows what got created

Think of main.tf as the architect's drawing, variables.tf as the customizable options, and outputs.tf as the summary report after construction is done.

Step 1: Setting up Terraform — the provider block

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.region
}

The first block tells Terraform: "We're working with AWS, and we want version 5 of the AWS plugin." That plugin is called a provider — think of it as an adapter that lets Terraform talk to AWS.

The second block specifies which AWS region to build in. A region is a physical location with Amazon data centres — us-east-1 is Northern Virginia, USA.

Notice var.region? That means: "look up the value of region in my variables file."

Step 2: Creating the VPC — your cloud neighbourhood

resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr_block
  tags = {
    Name = "main-vpc"
  }
}

The cidr_block defines the total size of your network. 10.0.0.0/16 gives us room for up to 65,536 addresses — a big plot of land!

tags are just labels to help you find your resources in the AWS console. Always tag. Your future self will thank you.

Step 3: Internet Gateway — the front gate

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "main-igw"
  }
}

Without this, your VPC is sealed off — like a neighbourhood with no road to the outside world. Notice vpc_id = aws_vpc.main.id? Terraform links resources like this. It figures out the build order automatically.

Step 4: Subnets — carving the zones

# Public subnet (the shopping street)
resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = var.public_subnet_cidr_block
  map_public_ip_on_launch = true # Automatically assign public IPs to instances launched in this subnet
  tags = {
    Name = "main-public-subnet"
  }
}

# Private subnet (the gated estate)
resource "aws_subnet" "private" {
  vpc_id     = aws_vpc.main.id
  cidr_block = var.private_subnet_cidr_block
  tags = {
    Name = "main-private-subnet"
  }
}

We're carving our big VPC into zones. The public subnet (10.0.1.0/24) is for resources that need internet access, like web servers. The private subnet (10.0.2.0/24) is for sensitive things like databases — no direct internet access. The /24 gives each subnet 256 addresses.

map_public_ip_on_launch = true For resources inside a subnet to actually receive public internet access, instances launched there need public IP addresses. Without a public IP, an EC2 instance cannot be reached from the internet, even if everything else is configured correctly.

Step 5: Route tables — the traffic signs

# Public route table + association + internet route
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "main-public-rt" }
}
resource "aws_route_table_association" "public" {
  subnet_id      = aws_subnet.public.id
  route_table_id = aws_route_table.public.id
}
resource "aws_route" "public_igw" {
  route_table_id         = aws_route_table.public.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.main.id
}

# Private route table + association (no internet route)
resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "main-private-rt" }
}
resource "aws_route_table_association" "private" {
  subnet_id      = aws_subnet.private.id
  route_table_id = aws_route_table.private.id
}

The key line is destination_cidr_block = "0.0.0.0/0" pointing to the IGW. 0.0.0.0/0 means "any address on the internet" — this is what makes the public subnet actually public.

The private subnet gets its own route table but no internet route — isolated by design. The associations are the connectors that glue each table to its subnet.

Step 6: Security groups - for the public subnet

resource "aws_security_group" "public_sg" {
  name        = "public-sg"
  description = "Allow SSH and HTTP access"
  vpc_id      = aws_vpc.main.id

  # Allow SSH access from anywhere
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow HTTP access from anywhere
  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Allow all outbound traffic
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "main-public-sg"
  }
}

A Security Group is basically a firewall attached to your EC2 instance. It decides who can enter, which ports are open, what type of traffic is allowed.

This Security Group allows:

SSH access (port 22)
HTTP web traffic (port 80)

cidr_blocks = ["0.0.0.0/0"] means “Allow traffic from anywhere on the internet.”

Step 7: Create EC2 instance in the public subnet

resource "aws_instance" "public_ec2" {
  ami             = var.ami_id
  instance_type   = var.instance_type
  subnet_id       = aws_subnet.public.id # This places the EC2 inside the public subnet
  security_groups = [aws_security_group.public_sg.id]
  tags = {
    Name = "terraform-public-ec2"
  }
}

ami = var.ami_id An AMI (Amazon Machine Image) is essentially a template for the operating system. Think of it like installing Windows or Linux onto a new computer. I used an Amazon Linux AMI for this project.

instance_type = var.instance_type This defines the size and power of the virtual server. I used t3.micro (referenced in the variables.tf file) which is lightweight and great for learning purposes.

subnet_id = aws_subnet.public.id This places the EC2 instance inside the public subnet we created earlier.

Then security_groups = [aws_security_group.public_sg.id] attaches the firewall rules to the server.

Step 8: Variables — the settings file

variable "region" {
  type        = string
  description = "AWS region to deploy resources in"
  default     = "us-east-1"
}

variable "vpc_cidr_block" {
  type        = string
  description = "CIDR block for the VPC"
  default     = "10.0.0.0/16"
}

variable "public_subnet_cidr_block" {
  type        = string
  description = "CIDR block for the public subnet"
  default     = "10.0.1.0/24"
}

variable "private_subnet_cidr_block" {
  type        = string
  description = "CIDR block for the private subnet"
  default     = "10.0.2.0/24"
}

variable "ami_id" {
  type        = string
  description = "AMI ID for the EC2 instance"
  default     = "ami-0c94855ba95c71c99"
}

variable "instance_type" {
  type        = string
  description = "Instance type for the EC2 instance"
  default     = "t3.micro"
}

Instead of hardcoding values everywhere, I used variables for region, subnet CIDRs, AMI ID, instance type. This makes the infrastructure easier to modify and reuse later.

For instance, instead of repeating "us-east-1" everywhere, we define it once in variables. Want to deploy to a different region? Change it in one place, not everywhere. Clean, reusable, professional.

Step 9: Outputs — the receipt

# output the VPC id
output "vpc_id" {
  value = aws_vpc.main.id
}

# output the public subnet id
output "public_subnet_id" {
  value = aws_subnet.public.id
}

# output the private subnet id
output "private_subnet_id" {
  value = aws_subnet.private.id
}

# EC2 Public IP
output "ec2_public_ip" {
  value = aws_instance.public_ec2.public_ip
}

# EC2 Instance ID
output "ec2_instance_id" {
  value = aws_instance.public_ec2.id
}

After Terraform finishes, outputs are printed in your terminal — like a receipt. Instead of logging into AWS to find your VPC ID, Public IP, EC2 Instance ID, Terraform just hands it to you. That means you can immediately locate the server, connect to it and verify the deployment worked, without manually digging through the AWS console.

Deploying the infrastructure

Once everything was configured, I used the standard Terraform workflow:

terraform init     # Download the AWS provider and initialize Terraform
terraform fmt      # Format the code neatly
terraform validate # Check for configuration errors
terraform plan     # Preview what Terraform will create
terraform apply    # Provision the infrastructure

And when you're done experimenting:

terraform destroy  # Tear everything down to avoid unnecessary AWS charges

The full architecture

Challenges I faced

Like every beginner, I made mistakes:

Using quotes incorrectly around variables inside main.tf which broke my configuration
Confusion around route tables and associations
Understanding how IGW actually connects to subnets
Debugging Terraform errors for the first time

But each error helped me understand Terraform and AWS networking better.

What's next?

I plan to explore:

Connecting to the EC2 instance via SSH
Installing NGINX and hosting a simple webpage
Terraform modules
Remote state management with S3
CI/CD pipelines with GitHub Actions
Docker and container deployment I'm still learning and still building. Follow along!

Enhancing Cybersecurity in Healthcare: A NIST Cybersecurity Framework Assessment

Benjamin Tetteh — Sat, 08 Mar 2025 19:10:57 +0000

Cybersecurity threats are an ever-growing concern, especially in industries handling sensitive data like healthcare. To address these risks, I conducted a NIST Cybersecurity Framework (CSF) Assessment for a fictional mid-sized healthcare provider, MediHealth Solutions Inc., as part of my cybersecurity portfolio.

Project Overview
The goal of this assessment was to evaluate MediHealth’s security posture, identify vulnerabilities, and recommend remediation strategies in alignment with NIST CSF and HIPAA requirements. The assessment covered key cybersecurity domains, including identifying assets, implementing protective measures, detecting threats, responding to incidents, and ensuring recovery.

Key Findings
One of the major findings was the presence of legacy system risks. The organization relied on an outdated Electronic Health Records (EHR) system, increasing its exposure to unpatched vulnerabilities. To mitigate this risk, I recommended system upgrades and the deployment of automated patch management. Another critical issue was human factors in cybersecurity. A phishing simulation revealed that 30% of employees fell for phishing attempts, highlighting the need for increased awareness. I proposed a cybersecurity training program using platforms like KnowBe4 and GoPhish to educate employees on recognizing and avoiding phishing attacks.

Additionally, I identified the absence of an Incident Response Plan (IRP) to handle ransomware and data breaches. Without a structured IRP, the organization risked delayed responses to security incidents. To address this, I developed a comprehensive IRP based on NIST SP 800-61 Rev. 2, outlining clear response procedures and implementing quarterly tabletop exercises to ensure readiness. Weak access controls were another major concern, as critical systems lacked Multi-Factor Authentication (MFA) and Role-Based Access Controls (RBAC). Enforcing MFA for all high-risk accounts and restricting access based on user roles significantly improved the security posture. Furthermore, the lack of centralized monitoring meant that the organization had no Security Information and Event Management (SIEM) system to detect and analyze threats in real-time. To remedy this, I recommended deploying SIEM tools such as Splunk or ELK Stack, along with Intrusion Detection Systems (IDS/IPS) to enhance threat detection and mitigation capabilities.

Relevance to My Cybersecurity Journey
As a self-motivated cybersecurity enthusiast, this project was instrumental in refining my skills in risk assessment, incident response, compliance, and security control implementation. Conducting this assessment independently showcased my ability to analyze real-world cybersecurity threats, design security solutions, and align them with industry standards. This hands-on experience reinforced my understanding of security governance, risk management, and compliance (GRC), which are crucial skills for cybersecurity professionals. It also highlights my capability to work autonomously, proactively learn, and apply best practices in enterprise security.

This project provided invaluable experience in conducting enterprise-wide cybersecurity assessments, aligning security controls with compliance frameworks, and implementing actionable security improvements. It reinforced the importance of a structured approach to risk management, proactive threat detection, and continuous cybersecurity awareness training. Cybersecurity is a constantly evolving field that requires a mix of technical expertise and risk-based decision-making. This NIST assessment has been a valuable addition to my cybersecurity portfolio, demonstrating my ability to analyze security gaps and implement industry-standard security measures.

📌 Check out the full assessment here.

💬 Let’s discuss! Have you worked with the NIST Cybersecurity Framework before? How do you approach security risk assessments in your projects?

From Data Breach to Insight: Exploring the Intersection of Cybersecurity and Communication

Benjamin Tetteh — Sat, 08 Mar 2025 18:22:00 +0000

I recently received an email notifying me of a data breach at a major public service provider in London that I rely on. Before this, I never truly considered that I could be directly impacted by a breach, even though they’re frequently reported in the media. With incidents like these becoming increasingly common, it was unsettling to think that my personal data may have been compromised. However, the service provider has been proactive, sending follow-up emails in the weeks following the initial notification, outlining the incident and their remediation efforts. As a communications professional, I found their response reassuring.

Data breaches are becoming so frequent that they’re starting to feel like notifications from my telecom provider—constant, annoying, and impossible to ignore.

Coincidentally, I’d been enrolled in the Google Cybersecurity Certificate course. My initial foray into cybersecurity was driven by the assumption that I would be diving into a highly technical world—one filled with firewalls, encryption, and endless lines of code, likely while wearing a hoodie in a dark room. While I certainly encountered that (minus the hoodie), what piqued my interest was discovering how crucial communication is within the cybersecurity landscape.

In today's hyper-connected world, cybersecurity has become one of the most critical aspects of every organization's operational strategy. It’s not just about protecting sensitive data or ensuring business continuity; it’s also about building and maintaining trust with customers. I’ve come to realize that cybersecurity is more than just a technical responsibility; it’s also a communications challenge.

The Intersection
Why? Because no matter how sophisticated an organization's defenses are, human error remains one of the most significant risks. This is where effective communication plays a pivotal role. While studying incident response plans, I realized that when a data breach occurs, it’s not just the IT team scrambling behind the scenes to secure systems and data. The communications team is equally essential in ensuring that stakeholders—whether customers, employees, or partners—are informed and reassured. Organizations are legally obligated to disclose breaches, and the quality, clarity, and timeliness of that communication often determine whether trust is preserved or lost. Cybersecurity professionals may patch vulnerabilities and mitigate future risks, but without clear, strategic communication, even the best technical response can leave people in the dark and cause unnecessary panic.

One of the most critical elements of cybersecurity is awareness. Many threats—from phishing to social engineering—target the weakest link: people. Ensuring that employees and stakeholders understand the risks and how to avoid them requires more than a one-time memo or a check-the-box training module. It requires consistent, clear, and engaging communication. By translating complex technical concepts into easily understandable information, communicators can help create a culture of security. This extends to everything from regular awareness campaigns to engaging content that demystifies topics like password security, device protection, and data privacy.

Gaining Technical Expertise: The Next Frontier
On the flip side, my experience with the technical aspects of cybersecurity has also been eye-opening. Through the Google Cybersecurity Certificate, I’ve gained hands-on experience with tools like Python, Linux, and SQL, and I’ve worked with Security Information and Event Management (SIEM) tools to identify risks and mitigate threats. Understanding these technologies has allowed me to better appreciate the technical side of cybersecurity.

My observations and learnings from the past weeks have made me appreciate the relationship between cybersecurity and communications. Both disciplines require a keen understanding of risk, an ability to anticipate and mitigate problems, and a focus on protecting people—whether through securing data or ensuring that information is clear and accessible. As I continue to explore both fields, I’m excited by the possibilities that lie at this intersection.

On to the next.

PS: I first published this article on my LinkedIn profile on 16/9/24.

DEV Community: Benjamin Tetteh

Real-World Git Branching Strategies: How Teams Manage Code in Practical Dev Environments

Introduction

A Note on Real-World Workflows

Table of Contents

1. Why Branching Matters in Real Projects

Why main exists

2. The Common Environments

Local Development (Your Laptop)

Sandbox Environment

Development Environment (Dev)

QA / Test Environment

Staging Environment

Production Environment

3. How Code Moves Between Environments

4. Common Branch Types

Naming conventions in practice

5. GitHub Flow

The rules

In practice

Who should use it

6. Git Flow

The key branches

A typical Git Flow lifecycle

Who should use it

7. Trunk-Based Development

The core principles

Why teams use it

Who should use it

8. Environment-Based Branching

9. Feature Flags

A simple example

Why teams use feature flags

The trade-off

10. Pull Requests and Code Reviews

What a good pull request looks like

The code review process

PR etiquette for beginners

11. What Happens After a Merge?

12. How This Looks on GitHub

13. CI/CD and Branch Protection Rules

Continuous Integration and Continuous Delivery (CI/CD)

How CI/CD connects to branching

Branch Protection Rules

14. Where Does DevOps Fit?

15. A Security Perspective

16. Hotfix Scenario: Fixing Production Quickly

When do you need a hotfix?

The hotfix workflow (Git Flow)

The hotfix workflow (GitHub Flow)

Key principles for hotfixes

17. Which Strategy Do Real Companies Use?

18. Which Branching Strategy Should Beginners Learn First?

Start with GitHub Flow

A simple decision guide

19. Common Mistakes Teams Make

20. Final Thoughts

Git for Beginners: A Complete Practical Guide to Version Control

Introduction

Table of Contents

1. What is Git?

2. Why Git Matters

3. Git vs GitHub

4. Key Git Concepts

5. Installing Git

macOS

Windows

Linux (Ubuntu/Debian)

6. Configuring Git

7. Creating Your First Repository

Option 1: Start a New Project

Option 2: Clone an Existing Repository

8. The Basic Git Workflow

Step 1: Make changes

Step 2: Check the status

Step 3: Stage your changes

Step 4: Commit your changes

Step 5: View your history

9. Working with Branches

Create and switch to a branch

Why `main` exists

12. Understanding `git push origin main`

13. The `.gitignore` File