Interview Q&A

git cherry-pick <commit-hash>

git switch -c hotfix/save-work

git checkout -b feature/login abc1234

dashboard).

→ This prevents misuse.

Remove the secret from code:

git rm --cached path/to/file

git commit -m "Remove sensitive file"

Accidentally pushing secrets (API keys, passwords, tokens) is serious — even if you delete

them, they may still exist in commit history.

Steps to fix it:

git merge origin/main

My preferred strategy depends on the project type and team size:

• For large enterprise projects with planned releases → I prefer Git Flow.
• Branches: main, develop, feature/*, release/*, hotfix/*
• Benefits: Organized release management, clear isolation of features and

fixes.

• For agile teams or startups deploying multiple times a day → I prefer Trunk-Based

Development.

• Developers work on short-lived feature branches and merge into main

frequently (often daily).

• CI/CD pipelines ensure code is always deployable.

Follow:

Real-world example:

At my last company, we used Trunk-Based Development for a SaaS platform — it reduced

merge conflicts and allowed fast continuous deployment.

Review the concept and prepare a concise verbal explanation with a real project example.

Review the concept and prepare a concise verbal explanation with a real project example.

Git is a distributed version control system (VCS) that allows multiple developers to work on

a project without overwriting each other's work. It's designed to be fast, flexible, and

scalable, allowing developers to track changes in code and collaborate with ease.

In contrast, SVN (Subversion) is a centralized version control system. This means that SVN

has one central repository, and developers check out code to work locally. Git, on the other

hand, allows every developer to have their own full local repository, including the project’s

history. This makes Git faster and more reliable, especially in distributed teams.

Follow:

Real-World Example:

If you were working on a website project with a team, using Git allows each developer to

clone the repository, make changes locally, and push their changes without disrupting others.

In SVN, the code is pulled from the central server, and only one developer can commit

changes at a time.

After initializing a Git repo locally (git init), you can connect it to a remote repository

(like one on GitHub) using:

git remote add origin

Then push your code:

git push -u origin main

Explanation:

• origin is just a nickname for the remote URL.
• The -u flag links your local branch with the remote one so future pushes are easier

(git push alone works after that).

Follow:

Real-world example:

You create a local portfolio website and later decide to host it on GitHub. You connect your

local repo to the remote one using git remote add origin so both stay in sync.

Follow:

Mark the conflicting sections in your file:

<<<<<<< HEAD

your current branch code

=======

incoming branch code

>>>>>>> feature/new-ui

A branch in Git is like a separate line of development — a parallel universe for your code. It

allows you to work on new features, bug fixes, or experiments without affecting the main

codebase (usually called the main or master branch).

Why branches are useful:

They make collaboration easier by keeping each developer’s work isolated until it’s ready to

be merged back.

Follow:

Real-world example:

Imagine your company website is live, but you need to add a “dark mode” feature. Instead

of editing the main code directly (which might break the live site), you create a new branch

called feature/dark-mode to work independently. Once it’s done and tested, you merge it

back into main.

A Git tag marks specific points in a repository’s history — usually to label release versions

Follow:

(like v1.0, v2.1, etc.). It’s like a snapshot that says, “this commit is stable and ready to

release.”

Types of tags:

• Lightweight tag: just a name for a commit.
• Annotated tag: includes metadata like the tagger’s name, date, and message.

Commands:

git tag -a v1.0 -m "Version 1.0 release"

git push origin v1.0

Real-world example:

After testing your project, you tag the commit representing your first release with v1.0. This

helps other developers or CI/CD pipelines identify which version is live.

<<<<<<< HEAD

current branch code

=======

incoming branch code

>>>>>>> feature/contact-form

Review the concept and prepare a concise verbal explanation with a real project example.

A distributed version control system (DVCS) for tracking changes in

source code during software development.

Integration means connecting your Git repository to your CI/CD system so every

push, pull request, or tag triggers an automated build, test, and deploy pipeline.

✅ Jenkins Integration

• Install the Git plugin in Jenkins.

Create a new pipeline job and link it to your Git repository:

pipeline {

agent any

stages {

stage('Checkout') {

steps {

git branch: 'main', url:

Follow:

stage('Build') {

steps {

sh 'npm install'

sh 'npm test'

• Jenkins polls Git or listens for webhooks to trigger builds automatically.

✅ GitLab CI/CD

GitLab CI is built-in — simply create .gitlab-ci.yml:

stages:

• test
• deploy

test:

script:

• npm install
• npm test

deploy:

script:

• ./deploy.sh

only:

• main

Every push triggers this pipeline automatically.

✅ GitHub Actions

GitHub has its own YAML-based workflows:

name: Node CI

Follow:

on: [push, pull_request]

jobs:

build:

runs-on: ubuntu-latest

steps:

• uses: actions/checkout@v4
• run: npm ci
• run: npm test

It runs directly in GitHub without needing extra setup.

Real-world example:

Your team pushes code to GitHub → GitHub Actions automatically runs tests →

Jenkins (or GitLab CI) deploys to a staging environment → Approval required for

production deploy.

git config --global user.signingkey <key-id>

git config --global commit.gpgsign true

• Store tokens (like AWS_ACCESS_KEY, DOCKER_TOKEN) in

→ Settings > Secrets and variables > Actions

Access them in workflows:

env:

AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}

Git is the tool used to track changes in your code locally (on your computer), whereas

GitHub is a platform that hosts Git repositories online, enabling collaboration and sharing.

GitHub allows teams to work on Git-based projects in a central location, review code, and

manage issues and pull requests.

Real-World Example:

You use Git to make changes to your website’s code locally. Once you're happy with your

changes, you push them to GitHub so your team can see and review the updates. GitHub is

essentially a cloud service that works on top of Git.

Review the concept and prepare a concise verbal explanation with a real project example.

<<<<<<< HEAD

Your changes

=======

Incoming changes

>>>>>>> main

Large binary files (like images, videos, or data models) bloat Git repositories since Git

stores every version.

To handle them efficiently, I use Git LFS (Large File Storage).

Setup:

git lfs install

git lfs track "*.psd"

git add .gitattributes

git commit -m "Track Photoshop files with Git LFS"

Explanation:

Git LFS replaces large files with lightweight text pointers inside Git, while the actual binary

files are stored on a separate LFS server.

Example:

If a game project has large texture files, Git LFS prevents the repo from becoming gigabytes

in size, improving clone and fetch performance.

Review the concept and prepare a concise verbal explanation with a real project example.

git commit -S -m "fix: secure login flow"

Review the concept and prepare a concise verbal explanation with a real project example.

Review the concept and prepare a concise verbal explanation with a real project example.

• origin – The main remote repository you cloned or own.
• upstream – Usually refers to the original repository that your fork came from.

Example:

If you fork a popular open-source project:

• Your fork on GitHub = origin
• The original repo (the one you forked from) = upstream

Commands to set both:

git remote add origin

git remote add upstream

Why it matters:

This setup lets you pull new changes from the main project (upstream) while pushing your

changes to your fork (origin).

GitHub Actions tokens (GITHUB_TOKEN) should have minimal scopes:

permissions:

contents: read

deployments: write

packages: read

You can create and switch to a new branch using:

git checkout -b feature/login-page

This creates a branch named feature/login-page and switches you to it immediately.

Alternatively, you can do it in two steps:

git branch feature/login-page

git checkout feature/login-page

Real-world example:

If your team assigns you to build a login page, you can create a branch

feature/login-page to isolate your changes from the main code.

If a commit has been pushed to a shared branch, the safest way is to revert it — not

remove it.

git revert <commit-hash>

This creates a new commit that undoes the changes from the old one, without rewriting

history.

Example:

If you pushed a buggy commit that broke the login page, git revert creates a new

commit that removes those buggy changes while keeping the history intact.

⚠ Avoid git reset on shared branches because it rewrites history — it can

mess up others’ work.

Review the concept and prepare a concise verbal explanation with a real project example.

A system where every developer has a full copy of the repository,

including its entire history, allowing for offline work and decentralized collaboration.

Create a branch to restore it:

git checkout -b recovery-branch <commit-hash>

Semantic Versioning (SemVer) follows the format:

MAJOR.MINOR.PATCH

Example: v2.3.1

It’s based on changes — breaking changes bump MAJOR, new features bump

MINOR, and bug fixes bump PATCH.

Automation tools:

• semantic-release (Node.js)
• GitVersion (for .NET)
• release-please (Google’s tool for GitHub Actions)

Example using semantic-release:

Follow:

npm install semantic-release @semantic-release/git

@semantic-release/github -D

Create a .releaserc.json:

"branches": ["main"],

"plugins": [

"@semantic-release/commit-analyzer",

"@semantic-release/release-notes-generator",

"@semantic-release/changelog",

"@semantic-release/github",

"@semantic-release/git"

What it does:

• Reads commit messages (feat:, fix:, breaking:)
• Calculates next version automatically
• Creates a Git tag (e.g., v1.2.0)
• Updates CHANGELOG.md
• Publishes release notes to GitHub

Example output:

chore(release): 1.3.0

• feat: add dark mode toggle
• fix: resolve login error

git add .

git merge --continue # or git rebase --continue

If you deleted a branch accidentally but haven’t run garbage collection yet, it can be

recovered using the commit log.

Steps:

Find the last commit of that branch:

git reflog

Example output:

abc1234 refs/heads/feature/login: commit: Add login validation

Follow:

Clean and optimize the repository:

git gc --aggressive

Example:

You checked out an old commit for debugging:

git checkout a1b2c3d

Then made edits and committed — but forgot to make a new branch.

Create one before switching back, or you’ll lose that work.

Both commands integrate changes from one branch into another, but they work differently:

• git merge combines the histories of two branches, creating a new “merge commit.”
• git rebase rewrites history by placing your branch’s commits on top of another

branch, making it look like you developed your changes sequentially.

Real-world analogy:

• Merge: Like combining two storylines into one — you keep both histories.

Follow:

• Rebase: Like rewriting your story so it appears you followed the main storyline all

along.

Example:

If your feature branch has diverged from main, merging will keep both timelines, while

rebasing will make it look like your branch was based on the latest main version all along.

Review the concept and prepare a concise verbal explanation with a real project example.

Forking is when you create your own copy of someone else’s GitHub repository.

You do this directly on GitHub by clicking the “Fork” button on the top right of the repository

page.

Follow:

Example:

You want to contribute to a public project like freeCodeCamp. You click Fork, creating your

own version under your account. You can modify it freely and then make pull requests to the

original project.

Command-line analogy:

Forking is like cloning, but on the GitHub server level — it gives you your own remote

repository to push to.

Add the resolved file:

git add <file>

git commit # or continue the rebase

Mask secrets automatically using:

run: echo "Deploying..." && echo "${{ secrets.AWS_SECRET_KEY }}"

• GitHub automatically redacts these values from logs.

• Working Directory: This is where you make changes to the files. It's your local

workspace where you're actively editing code.

• Staging Area (Index): This is like a holding area where you prepare files before

committing them to the repository. You can choose which changes to add here.

• Repository: This is where Git stores the project’s history (commits). It's the

permanent record of your project's evolution.

Real-World Example:

When you're editing code, it starts in the working directory. After editing, you "stage" your

changes (using git add), which moves them to the staging area. Once you're ready to

save your changes permanently, you commit them to the repository using git commit.

Follow:

Follow:

Comman

Description Safe for shared

repos?

git revert Creates a new commit that undoes changes from a

previous commit

✅ Yes

git reset Moves the branch pointer back to a previous commit,

potentially removing commits

❌ No (rewrites

history)

Example:

If you realize a commit caused an error:

• git revert will make a new commit that undoes it.
• git reset will erase it as if it never happened (good for local cleanup).

Working Directory (modified files), Staging Area (files marked for

next commit), Local Repository (committed files).

Mark conflicts as resolved:

git add <filename>

git commit

Review the concept and prepare a concise verbal explanation with a real project example.

Prune and repack:

git gc --prune=now --aggressive

A force push can rewrite history and make commits disappear from the remote branch —

but they’re often recoverable.

Steps:

Run git reflog locally to view all commit references:

git reflog show origin/main

Review the concept and prepare a concise verbal explanation with a real project example.

git add .

git commit

git push

git remote add origin

git push --all origin

git push --tags origin

Review the concept and prepare a concise verbal explanation with a real project example.

Signed commits ensure authenticity — they’re cryptographically verified with a GPG

or SSH key, proving the commit really came from you and wasn’t tampered with.

Setup:

Generate a GPG key:

gpg --full-generate-key

You’ll see a green “Verified” badge on signed commits.

Why it matters:

• Verifies authorship for open-source contributions.
• Helps in regulated environments (e.g., fintech, healthcare).
• Prevents supply chain attacks via spoofed commits.

Real-world example:

In a security-conscious org, all commits to the main branch are required to be

GPG-signed — GitHub enforces this with branch protection rules.

• git filter-repo (preferred)

git filter-repo --path path/to/file --invert-paths

Follow:

A Git submodule is a repository inside another repository — useful for including shared

components or libraries.

Example:

You have multiple microservices that share a common authentication library. Instead of

duplicating it, you include it as a submodule:

git submodule add

libs/auth

Follow:

Pros: Keeps shared code centralized.

Cons: Requires careful syncing; new contributors must initialize submodules using:

git submodule update --init --recursive

Review the concept and prepare a concise verbal explanation with a real project example.

Example:

Before approving a PR for a new payment API, I check:

• Code readability and naming consistency
• Proper test coverage
• Security considerations (e.g., no API keys in code)

Bonus:

I sometimes use Suggested Changes in GitHub comments to make small fixes easier for

contributors.

git push origin --force

Follow:

• Instead of long-lived access keys, use federated identity:

■ AWS/GCP trusts GitHub’s identity token.

■ Short-lived credentials are issued dynamically.

Example for AWS:

permissions:

id-token: write

contents: read

Real-world example:

In one project, we replaced static AWS keys with OIDC-based auth in GitHub Actions

— no more long-lived tokens, and access was automatically scoped per workflow.

Follow:

Example:

If you merge feature/login into main, Git finds the last point they shared code, applies

your login branch changes, and creates a new commit that connects both histories.

Intermediate / Advanced Git Concepts

When migrating a legacy product from SVN, I ran the migration on a weekend, verified

history integrity with the team, and locked SVN after the Git migration was complete.

When GitHub reports conflicts in a PR:

Fetch and switch to your branch locally:

git fetch origin

git checkout feature/new-ui

Review the concept and prepare a concise verbal explanation with a real project example.

Reset

Type

What It Does Example Scenario

• -soft Moves HEAD to a previous commit

but keeps your changes staged

You committed too early and just

want to edit the message or add

more changes.

• -mixed

(default)

Moves HEAD and unstages files but

keeps your changes in the working

directory

You want to redo your git add

selections.

• -hard Completely resets everything —

deletes all local changes

You want to discard all work and

return to a clean state.

Example:

git reset --soft HEAD~1 # undo last commit, keep staged

git reset --mixed HEAD~1 # undo last commit, unstage files

git reset --hard HEAD~1 # undo last commit and delete changes

A detached HEAD means Git’s HEAD points to a specific commit instead of a branch —

commits made now won’t belong to any branch.

Follow:

To fix it:

Check what commit you’re on:

git status

Example:

If your teammate accidentally ran git push origin main --force, you can still

restore your lost commits using your local reflog if you had pulled the branch before the

overwrite.

Follow:

A Pull Request is a request to merge your changes from one branch or fork into another

repository or branch — typically to propose new code, bug fixes, or improvements.

Example:

You fixed a typo or added a feature in your fork of a project. You create a PR asking the

original maintainers to “pull” your changes into their main branch.

PRs enable:

• Code review
• Automated testing
• Discussion before merging

Conventional Commits define a standard format for commit messages, such as:

feat: add new user registration flow

fix: correct login validation

chore: update dependencies

To enforce this automatically, use commitlint with husky:

Setup:

npm install --save-dev @commitlint/{config-conventional,cli} husky

Create a commitlint.config.js:

module.exports = { extends: ['@commitlint/config-conventional'] };

Then add a Git hook:

npx husky install

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit

"$1"'

Now every commit is checked — bad messages are rejected.

Example:

✅ feat: add password reset feature

❌ Added new password reset → ❌ rejected

Why this matters:

• Enables automatic changelog and versioning.
• Keeps Git history consistent.
• Works well with tools like semantic-release.

Follow:

A snapshot of your project at a specific point in time, including changes

and a message.

A commit in Git is a snapshot of your project at a specific point in time. It records all the

changes you've made to the files and saves them to the repository. Every commit has a

unique ID, and it's like a save point in a video game—if something breaks, you can go back

to any commit.

Real-World Example:

Let’s say you fixed a bug on the homepage of your app. After completing the fix, you commit

the changes to the repository. Later, if the fix causes an issue, you can roll back to the

previous commit.

Aspect Merging Rebasing

History Keeps all commits, including merge

commits

Creates a linear, cleaner history

Safety Safe for shared/public branches Risky for shared branches (rewrites

history)

Use

Case

When collaboration is ongoing When you want a clean, linear history

before merging

Real-world example:

Before merging a feature into main, many teams rebase it to make the commit history

cleaner. But during teamwork, merging is safer because it doesn’t rewrite other people’s

work.

Two developers edit the same line in README.md — one changes “version 1.0” to “1.1,”

another to “v2.0.” Git will stop and ask you to pick which to keep.

On GitHub:

A fast-forward merge happens when the target branch has not diverged — meaning, there

are no new commits on main since you branched off. Git simply moves the branch pointer

forward to include all your new commits, without creating a new merge commit.

Example:

If main has not changed since you created your feature/navbar branch, merging it back

will simply “fast-forward” main to the latest commit.

git merge feature/navbar

No merge commit — just a pointer move.

Follow:

git init - creates a new Git repository in the current directory.

git stash temporarily saves your uncommitted changes so you can work on something

else without committing unfinished work.

Example:

You’re fixing a login bug but suddenly need to switch branches to fix a production issue.

Instead of committing half-done code, you run:

git stash

git checkout main

Later, you can come back and reapply your stashed work.

Collaboration & Workflow

git push origin --force

When branches diverge, Git can’t automatically merge them — it needs your help.

Steps:

Pull the latest changes and rebase or merge:

git fetch origin

git merge origin/main

git rebase origin/main

Real-world example:

If you’re a team lead, you review a PR for a new feature, check coding standards, ensure

tests pass, and approve it before merging into main.

Security in CI/CD pipelines is crucial — you never want secrets hard-coded in code or

workflows.

Best practices:

On GitHub:

• git fetch: It retrieves changes from a remote repository but does not apply them to

your working directory. You can think of it as checking for updates without actually

installing them.

• git pull: This does two things: it fetches the latest changes and then merges them

into your current branch. It's like fetching updates and immediately applying them.

Real-World Example:

If you're working on a project with teammates, git fetch allows you to see what changes

have been made without affecting your code. git pull, on the other hand, will update your

local copy and merge those changes with your work, which can sometimes result in merge

conflicts.

Merge conflicts occur when two branches modify the same part of a file differently. To

resolve:

Run the merge command:

git merge feature/contact-form

Git hooks are scripts that run automatically when specific Git events occur (like committing

or pushing).

They live inside .git/hooks/.

Common examples:

Follow:

pre-commit: Run linting or unit tests before a commit

# .git/hooks/pre-commit

npm run lint || exit 1

pre-push: Prevent pushes to main

if [ "$(git rev-parse --abbrev-ref HEAD)" == "main" ]; then

echo "You can't push directly to main!"

exit 1

Example:

In a team, we set a pre-commit hook to check code formatting with ESLint before any

commit — ensuring consistency across all contributors.

If you accidentally committed to the wrong branch, you can move those commits cleanly.

Steps:

Switch to the correct branch:

git checkout correct-branch

GitHub Actions is GitHub’s built-in Continuous Integration/Continuous Deployment

(CI/CD) platform.

It lets you automate tasks — like running tests, building code, or deploying apps — every

time code is pushed or a PR is opened.

Example:

You can create a workflow file .github/workflows/test.yml:

name: Run Tests

on: [push, pull_request]

jobs:

test:

runs-on: ubuntu-latest

steps:

• uses: actions/checkout@v4
• name: Install dependencies

run: npm install

• name: Run tests

run: npm test

Whenever code is pushed, GitHub automatically runs your tests — ensuring quality before

merging.

To bring back your stashed work:

git stash apply # reapplies the most recent stash

git stash pop # reapplies AND deletes the stash

git stash list # shows all stashes

git stash show -p # shows what changes are in a stash

Real-world example:

After resolving the production issue, you return to your feature branch and restore your

previous changes with git stash pop.

(Duplicate of #4) A snapshot of your project at a specific point in

time, including changes and a message.

To create a new Git repository, navigate to your project directory and use the command:

git init

This initializes an empty Git repository in that directory. Now you can start tracking changes

in your project.

Follow:

Real-World Example:

Imagine you're starting a new website project on your computer. You open your terminal, go

to your project folder, and type git init. This sets up the Git repository, and you can start

tracking your changes immediately.

Old branches can clutter your repo. You can clean them locally and remotely.

Commands:

To delete merged branches locally:

git branch --merged main | grep -v "main" | xargs git branch -d

To prune deleted remote branches:

git fetch --prune

Example:

After several months, your repo has 50 old feature branches. You can prune them

automatically in CI or periodically with these commands.

Follow:

Locally:

git branch -d feature/old-branch

• (-D for force delete if it’s not merged)

Remotely:

git push origin --delete feature/old-branch

Real-world example:

After merging your feature branch into main, you can safely delete it to keep your repository

clean.

There are several safe rollback methods:

Option 1 — Revert to a previous tag (recommended):

git revert <commit-hash>

git push origin main

This creates a new commit that undoes the bad release.

Option 2 — Deploy a stable tag:

git checkout v1.2.3

git push origin main --force

Example:

If version v2.0 introduced a bug in the payment flow, I revert to v1.9.1 (the last stable tag)

and redeploy while investigating the issue.

Follow:

In CI/CD pipelines:

We often have a ROLLBACK_TAG variable that can deploy a known safe version

automatically.

Use git diff with two commit hashes:

git diff <commit1> <commit2>

This shows line-by-line changes between the two commits.

Follow:

Example:

If you want to compare how your project changed between version 1.0 and version 1.1:

git diff v1.0 v1.1

You’ll see added, removed, and modified lines across files.

Example:

You pushed .env with a production API key. Even after deletion, it’s still in the Git history —

so you must clean and rotate keys right away.

You can enforce reviews and branch protection rules in repository settings under

Settings → Branches → Branch protection rules.

Follow:

You can require:

• Pull requests before merging
• At least one approval
• Passing CI checks (e.g., GitHub Actions)
• No direct pushes to main

Example:

Your team sets a rule that all PRs must be reviewed by at least one other developer and

must pass automated tests before merging.

A lightweight, movable pointer to a commit, allowing for parallel

development.

To clone an existing repository, you use the git clone command followed by the URL of

the remote repository:

git clone

This command creates a copy of the repository on your local machine, including all its files

and history.

Real-World Example:

If you're joining an open-source project on GitHub, you can clone the repository to your

machine by running the git clone command. This gives you access to the full codebase

to start contributing.

Aspect GitHub Flow Git Flow

Purpose Simple branching model for

continuous delivery

Structured model for release

management

Branche

Only main and short-lived feature

branches

Multiple: main, develop, feature,

release, hotfix

Workflow Create branch → Commit → Pull

Request → Merge → Deploy

Feature branches merge into develop,

then release/hotfix merges into main

Use Case SaaS projects, frequent deploys Complex products with scheduled

releases

Example:

• GitHub Flow → Used by startups deploying updates daily.
• Git Flow → Used by large software teams (e.g., enterprise apps) with versioned

releases.

• git add: This command stages changes, telling Git which modifications you want to

include in the next commit. It doesn't save the changes to the repository yet, just

prepares them.

• git commit: This actually saves the changes to the repository, creating a new entry

in your project’s history.

Real-World Example:

You’ve edited a few files in your project. First, you use git add . to stage all changes,

and then you use git commit -m "Fixed bug in homepage" to save those changes

to the repository.

Follow:

To slim down a bloated repository:

Follow:

Remove large unnecessary files:

git filter-repo --path path/to/largefile --invert-paths

A detached HEAD happens when Git’s HEAD (your current position) points to a specific

commit instead of a branch. If you make new commits in this state, they won’t belong to any

branch — you could lose them if you switch branches.

How to fix it:

If you accidentally commit in a detached HEAD state:

git switch -c temp-branch

This creates a new branch from your current state so your commits aren’t lost.

Example:

You checked out an old commit to test something:

git checkout a1b2c3d

If you make changes, create a branch to save them before switching back.

git checkout <branch-name> or git switch

<branch-name> - moves your HEAD pointer to another branch.

In CI/CD, I automate version tagging to keep releases consistent and traceable.

Example pipeline step (GitHub Actions):

• name: Tag release

run: |

VERSION=$(node -p "require('./package.json').version")

git tag -a "v$VERSION" -m "Release version $VERSION"

git push origin "v$VERSION"

Versioning style:

I use Semantic Versioning (SemVer) → MAJOR.MINOR.PATCH

Example: v2.1.4

• Major = breaking changes
• Minor = new features
• Patch = bug fixes

This helps CI/CD pipelines automatically trigger deployments for new versions.

A detached HEAD occurs when Git’s HEAD (which points to your current branch) points to a

specific commit instead of a branch. This means you’re not working on any branch — any

new commits made in this state are “orphaned” unless you create a branch from them.

Example:

If you check out an old commit directly:

git checkout a1b2c3d

You’re in a detached HEAD state.

If you make changes here and don’t create a new branch, you could lose them later.

Fix:

Create a new branch to save your work:

git checkout -b hotfix/rollback-test

Migrating involves preserving history, branches, and tags.

Steps (SVN example):

Install Git SVN:

git svn clone

• -trunk=trunk
• -branches=branches --tags=tags

git merge <branch-name> - combines changes from one

branch into another.

Key practices I follow:

• Branch-per-feature model – Each developer works on isolated branches.

Follow:

• Pull Requests (PRs) for merging into main.
• Code reviews + CI tests required before merging.
• Protected branches prevent direct commits.
• Communication – Sync via Slack, GitHub Discussions, or standups to avoid

conflicts.

Example:

At a fintech startup, 8 engineers worked on a single monorepo. We used short-lived

branches and daily merges, with GitHub Actions running automatic tests for every PR — this

reduced integration headaches.

git cherry-pick lets you apply a specific commit from one branch to another, without

merging the entire branch.

Example:

Imagine you fixed a typo in the develop branch but need that same fix in main

immediately. Instead of merging all of develop, you can just cherry-pick that commit:

git cherry-pick 1a2b3c4

Real-world use case:

Useful when you want to apply a hotfix or small bug fix without merging unrelated feature

work.

A protected branch (like main) restricts direct commits or merges unless specific rules are

met.

You can configure:

• Require pull request reviews
• Require status checks (tests) to pass
• Restrict who can push
• Prevent force pushes or deletions

Example:

You protect the main branch to ensure developers can only merge code through PRs that

have passed CI checks and received approval — preventing accidental overwrites.

When two branches modify the same part of a file, Git can’t automatically decide which

version to keep — this creates a conflict.

Git will:

The .gitignore file tells Git which files or directories it should ignore when tracking

changes. This is useful for files that aren’t necessary in the repository, like log files, compiled

binaries, or local configuration files.

Real-World Example:

If you're working on a Node.js project, you likely don’t want to track the node_modules/

directory, since it can be recreated by running npm install. You can add

node_modules/ to your .gitignore file to ensure that Git doesn't track those files.

When you run a merge, Git:

Squashing combines multiple small commits into one clean commit before merging —

keeping history tidy.

Options:

• On GitHub:

When merging a PR, select “Squash and merge.”

On local machine:

git rebase -i HEAD~3

Change extra commits from pick → squash and then push with:

git push -f

Real-world example:

If your PR has 10 commits like “fix typo,” “oops forgot semicolon,” and “final fix,” you squash

Follow:

them into one commit:

👉 Add responsive navbar component

✅ Pro Tip:

A clean workflow often looks like this:

I believe in a clean, meaningful Git history that tells the story of the project clearly.

Here’s how I maintain it:

• Use atomic commits (each commit = one logical change)

Write clear commit messages:

feat: add user profile API

fix: correct typo in dashboard title

chore: update dependencies

• Use rebase before merge to remove noisy commits (fix typo, debug print)
• Squash commits in PRs before merging
• Avoid committing generated or temporary files (use .gitignore)
• Tag meaningful releases (v1.0.0, v1.1.0-beta)

Follow:

Example:

When reviewing history later, I can quickly find “where” and “why” a change was made — no

messy “temp commit” or “final fix” messages.

✅ In short:

A healthy Git workflow = clear branches, clean commits, automated checks, and

collaborative reviews.

Real-World & Troubleshooting

Scenarios

I treat Git as the single source of truth for builds and deployments.

My approach:

• Each merge to main triggers CI/CD pipelines (GitHub Actions, Jenkins, or GitLab

CI).

• Pipelines:
• Run tests, lint, and security scans.
• Tag builds automatically (e.g., v1.2.3).
• Deploy to staging/production environments.

Best practices:

• Use semantic versioning in tags (v1.0.0).

Follow:

• Store environment configs securely (never in Git).
• Require PR reviews and passing checks before merge.
• Deploy directly from tagged commits, not branches.

Example:

In a microservices project, each push to main triggered automated Docker builds.

Tagging a commit with v2.3.1 automatically deployed that version to production —

ensuring traceability and rollback capability.

✅ In summary:

The key to mastering Git isn’t just knowing commands — it’s knowing how to

recover, clean, and automate safely.

Bonus / DevOps Integration

Manually editing files to combine conflicting changes, then

staging and committing them.

You can interactively rebase to edit, squash, or reorder commits using:

git rebase -i HEAD~3

This opens an editor showing the last 3 commits:

pick 1a2b3c Fix typo in footer

pick 4d5e6f Add login API

pick 7g8h9i Update UI color scheme

You can change:

Follow:

• pick → edit to modify a commit
• pick → squash to combine commits
• pick → reword to change the message

Real-world example:

Before merging your feature branch, you may use git rebase -i to combine small “fix

typo” or “debug print” commits into a clean, single commit.

⚠ Don’t rewrite history on shared branches that others are using — it can

cause conflicts and confusion.

GitHub & Remote Repository

Management

You can view the commit history by using the command:

git log

This shows a list of commits, with each commit’s hash, author, date, and message.

Real-World Example:

Imagine you're trying to figure out when a bug was introduced to your code. By running git

log, you can see all previous commits, helping you pinpoint the changes that might have

caused the issue.

Branching & Merging

Rewrites commit history by moving a sequence of commits to a new

base commit, creating a linear history.

Uploads your local branch commits to a remote repository.

Downloads commits, files, and refs from a remote repository into your

local repository, but doesn't merge them.

git remote add <name> <url> - links a local repository to a

remote one (e.g., GitHub).

git clone <url> - creates a local copy of a remote repository.

A file (.gitignore) that tells Git which files or directories to

intentionally ignore from being tracked.

git status (summary), git diff (detailed changes).

(Duplicate of #18) git restore <file> (unstage/discard

working dir changes), git reset HEAD <file> (unstage).

git reset --soft/--mixed/--hard <commit> - moves HEAD

and optionally changes the staging area/working directory to a specified commit.

git revert <commit> - creates a new commit that undoes the

changes of a previous commit, preserving history.

git checkout <commit> -- <file> - restores a file to its state

at a specific commit.

Follow:

reset rewrites history; revert creates a new commit to undo

changes, preserving history.

Shows a log of where your HEAD and branch tips have been, useful for

recovering lost commits.

git cherry-pick <commit> - applies the changes introduced

by an existing commit from another branch onto your current branch.

Forking creates a copy of an entire repository (often on a

remote server); branching creates a lightweight, isolated line of development within a

single repository.

A permanent, immutable pointer to a specific commit, often used to mark

release points (e.g., v1.0).

A common collaboration model involving forking, branching, pull

requests, and code review.

The process of other developers examining source code to find bugs,

improve quality, and ensure best practices.

An automation platform that allows you to define custom workflows

to build, test, and deploy code directly from GitHub.

A request to merge changes from one branch (often from a fork) into

another, typically involving code review.

Git Large File Storage - a Git extension for versioning large files outside

the main repository, storing pointers in Git while files are on a remote server.

Scripts that Git executes before or after events like commit, push, and

receive. Used for automation and enforcing policies.

Allows you to embed one Git repository inside another as a

subdirectory, maintaining separate histories.

When your HEAD pointer points directly to a commit instead of a

branch name, meaning you're not on any branch.

(Typo for "Interactive Rebase"?)

• Interactive Rebase: git rebase -i <commit> - allows you to squash,

reorder, edit, or drop commits during a rebase operation.

git bundle create <file.bundle> <ref> - packs Git refs and

objects into a single file for easy transfer without a network connection.

git blame <file> - shows who last modified each line of a file and

when.

git worktree add <path> <branch> - creates a new working

directory linked to your main repository, allowing you to work on multiple branches

simultaneously.

A Git repository that does not have a working directory, typically

used as a central remote repository (e.g., on a server).

Temporarily saves changes that are not ready to be committed,

allowing you to switch branches and come back to them later.

Combining multiple commits into a single, more meaningful

commit, typically done during an interactive rebase.

Follow:

The default name for the remote repository from which a project

was originally cloned.

A pointer to the current commit you are on in your local repository.

A configuration file that stores user-specific Git settings (e.g.,

username, email, aliases).

Shows changes between the staging area and the

last commit.

Displays the commit history of the current branch.

Allows you to interactively stage specific parts (hunks) of changes

within a file.

Shows the URLs of the remote repositories associated

with your local repo.

A command used to find the commit that introduced a bug by

performing a binary search on the commit history.

Checks the integrity of the Git file system.

Cleans up unnecessary files and optimizes the local repository.

A merge where the branch being merged can

simply be moved forward to the tip of the other branch without creating a new merge

commit.

A merge that involves the two branch tips and their

common ancestor to determine how to combine changes, potentially creating a new

merge commit.

Long Answers: