Git Workflow & Version Control Demo

Date: February 18, 2026
Topic: Version Control Systems (VCS)
Project: Professional Git Workflow Simulation

Project Overview

This project demonstrates a Standard DevOps Branching Strategy (often called Gitflow).
Instead of pushing directly to the production branch (main), we utilize a structured workflow involving feature branches, development integration, pull requests, and semantic version tagging.

1. What? (The Concept)

What I Built I created a repository that follows best practices for collaboration.
It includes:

• Branch Protection: Simulating restricted access to main.
• Feature Isolation: Working in feature/* branches.
• Code Review: Using Pull Requests (PRs) to merge code.
• Release Tagging: Marking specific commits as production releases (v1.0).

2. Why? (The Purpose)

Why complex branching? In a team of 10 developers, if everyone pushes to main, the code will break constantly.

• Safety: Bugs in dev don't break the main website.
• Review: PRs allow others to check code before it merges.
• History: We can rollback to v1.0 if v1.1 crashes.

Tech Stack

Component	Technology	Description
VCS	Git	Local version control
Remote Host	GitHub	Cloud repository & PR management
Strategy	Feature Branching	Workflow model

3. How? (The Implementation)

The Workflow Architecture:

gitGraph
   commit id: "Initial"
   branch dev
   checkout dev
   commit id: "Dev Setup"
   branch feature/header
   checkout feature/header
   commit id: "Add Header"
   checkout dev
   merge feature/header id: "Merge PR"
   checkout main
   merge dev id: "Release v1.0"
   commit id: "Tag v1.0" type: HIGHLIGHT

Loading

Workflow Steps

1. Initialize: Create repo and main branch.

2. Branch: Create dev for integration.

3. Feature: Create feature/add-header for work.

4. PR: Open Pull Request from feature -> dev.

5. Merge: Merge dev -> main for release.

6. Tag: Mark the release with git tag v1.0.

4. Quick Commands Reference

• New Branch: git checkout -b

• Check Branches: git branch -a

• Switch Branch: git switch

• Push Branch: git push origin

• Create Tag: git tag v1.0

FAQ / Interview Prep

1. What is Git?
   As we know Git is a distributed version control system that tracks changes in source code during software development.
   It allows multiple developers to work together non-linearly.

2. Merge vs. Rebase?
   Merge: Creates a new "merge commit" tying two histories together.
   Preserves exact history but can look messy.
   

Rebase: Moves your entire branch to begin at the tip of the target branch. Creates a linear, clean history but rewrites commit IDs (dangerous on shared branches).

3. What is a Pull Request (PR)?
   A PR is a feature in hosting services (GitHub/GitLab) where a developer asks to merge their changes into the main codebase.
   It is the venue for code review and discussion.

4. How do you resolve merge conflicts?
   

   • Git pauses the merge and marks the conflicting files.

   • Open the file, look for <<<<<<< HEAD.

   • Manually edit the code to choose the correct version.

   • Run git add and git commit to finish.

5. What are Git Tags?
   Tags are specific points in history that are important (like a release).
   Unlike branches, tags do not change. v1.0 will always point to that specific commit.

6. What is git stash?
   git stash temporarily shelves (saves) changes you've made to your working copy so you can work on something else, and then come back and re-apply them later (git stash pop).

7. What is the use of .gitignore?
   It tells Git which files or folders to ignore (not track).
   This is crucial for excluding:

   • Build artifacts (/dist, /build)

   • Dependencies (node_modules/)

   • Secrets (.env)