Explain the Git workflow you use most frequently

A Git workflow defines the process developers follow to manage source code changes efficiently. The most commonly used workflow in enterprise projects is the:

Feature Branch Workflow

In this workflow:

• developers create separate branches for features or bug fixes
• changes are tested independently
• code is merged into the main branch after review

Typical Workflow Steps

Step 1: Pull Latest Code

git pull origin main

Step 2: Create Feature Branch

git checkout -b feature-login

Step 3: Develop and Commit Changes

git add .
git commit -m "Added login API"

Step 4: Push Branch

git push origin feature-login

Step 5: Create Pull Request

Code is reviewed before merging.

Step 6: Merge into Main Branch

After approval, branch is merged.

Advantages of this Workflow

Parallel Development

Multiple developers work independently.

Better Code Quality

Supports code review process.

Safer Releases

Main branch remains stable.

Easy Rollback

Changes are isolated per feature.

Real-World Usage

This workflow is heavily used in:

• Spring Boot projects
• microservices architecture
• DevOps pipelines
• agile development teams

Can you describe the process of creating a new branch and merging it back into the main branch?

Creating and merging branches is a core Git workflow used for feature development and bug fixing.

Step 1: Switch to Main Branch

git checkout main

Step 2: Pull Latest Changes

git pull origin main

Step 3: Create New Branch

git checkout -b feature-payment

This:

• creates branch
• switches to branch

Step 4: Add Code Changes

Modify application files.

Step 5: Commit Changes

git add .
git commit -m "Added payment service"

Step 6: Push Branch to Remote

git push origin feature-payment

Step 7: Merge into Main Branch

Switch to main:

git checkout main

Merge branch:

git merge feature-payment

Step 8: Push Updated Main Branch

git push origin main

Why This Process is Important

This approach provides:

• isolated development
• safer deployments
• cleaner code reviews
• better collaboration

It is a standard workflow in enterprise software development.

What is a merge conflict in Git and how do you resolve it?

A merge conflict occurs when Git cannot automatically combine changes from two branches. This usually happens when:

• multiple developers modify the same lines of code
• one developer deletes code another developer modifies

Example Conflict Scenario

Developer A changes:

server.port=8080

Developer B changes:

server.port=9090

Git becomes unable to decide which change to keep.

How Git Displays Conflict

Git marks conflicting sections like:

<<<<<<< HEAD
current code
=======
incoming code
>>>>>>> feature-branch

Steps to Resolve Conflict

Step 1: Open Conflicted File

Review conflicting code.

Step 2: Edit Manually

Choose:

• current change
• incoming change
• combined version

Step 3: Mark Conflict as Resolved

git add .

Step 4: Complete Merge

git commit

Why Merge Conflicts Happen

Conflicts are common in:

• large teams
• parallel development
• long-running branches

Best Practices to Avoid Conflicts

Pull Frequently

Keep branch updated.

Create Small Commits

Smaller changes reduce conflicts.

Communicate with Team

Coordinate shared file changes.

Merge Regularly

Avoid outdated branches.

Real-World Importance

Resolving merge conflicts is a critical skill in:

• enterprise projects
• agile development
• microservices teams

because collaborative development frequently introduces overlapping changes.

What is a fast-forward merge in Git?

A fast-forward merge occurs when Git can move the branch pointer forward without creating a new merge commit.

This happens when:

• target branch has no new commits
• feature branch is directly ahead

Example

main
  \
   feature-login

After merge:

main → feature-login latest commit

No extra merge commit is created.

How Fast-Forward Merge Works

Example:

git checkout main
git merge feature-login

Git simply advances:

main

to latest commit.

Advantages

Cleaner Commit History

No unnecessary merge commits.

Faster Merge Process

Simpler branch integration.

Easier Navigation

Linear commit history.

Disadvantages

Reduced Historical Context

Branch structure becomes less visible.

Real-World Usage

Fast-forward merges are common when:

• feature branches are short-lived
• development is simple
• commit history should remain linear

Define a three-way merge

A three-way merge occurs when two branches have diverged and Git must combine changes using a common ancestor commit.

Git compares:

• current branch
• incoming branch
• common ancestor

Hence the name:

three-way merge

Example

        A
       / \
      B   C

Where:

• A = common ancestor
• B = current branch
• C = incoming branch

Git creates new merge commit combining both histories.

How Three-Way Merge Works

git merge feature-branch

Git analyzes:

• differences from ancestor
• conflicting changes
• merge possibilities

Advantages

Preserves Branch History

Complete development history remains visible.

Supports Parallel Development

Multiple teams work independently.

Better Traceability

Feature integration becomes clearer.

Possible Challenges

Merge Conflicts

Conflicting code changes may require manual resolution.

Real-World Importance

Three-way merges are very common in:

• enterprise projects
• large development teams
• microservices environments

because branches often diverge significantly during development.

How do you rebase a branch in Git?

Rebasing moves or reapplies commits from one branch onto another base branch. It creates a cleaner and more linear commit history.

Purpose of Rebase

Instead of merging:

• commits are replayed sequentially

Example

git checkout feature-login
git rebase main

This reapplies:

feature-login

commits on top of:

main

Advantages of Rebase

Cleaner History

Avoids unnecessary merge commits.

Linear Timeline

Simplifies project history.

Easier Debugging

Commit flow becomes easier to understand.

Possible Risks

Rebase rewrites commit history.

Avoid rebasing:

• shared public branches

Conflict Resolution During Rebase

If conflict occurs:

git rebase --continue

Abort rebase:

git rebase --abort

Real-World Usage

Rebase is widely used before:

• pull requests
• feature integration
• release preparation

to maintain clean commit history.

Explain the pros and cons of rebasing vs. merging

Both rebasing and merging integrate code changes, but they differ in history management.

Merging

Combines branch histories using merge commits.

Example:

git merge feature-login

Rebasing

Replays commits onto another branch.

Example:

git rebase main

Key Differences

Advantages of Merge

Preserves Full History

Shows exact branch structure.

Safer for Shared Branches

Does not rewrite history.

Advantages of Rebase

Cleaner Commit History

Linear structure simplifies tracking.

Better Readability

History becomes easier to understand.

Disadvantages of Merge

• additional merge commits
• cluttered history

Disadvantages of Rebase

• rewrites commit history
• dangerous on public branches

Real-World Best Practice

Use Merge For:

• shared branches
• team collaboration

Use Rebase For:

• local cleanup
• feature preparation

Enterprise teams commonly use both depending on workflow needs.

What is the purpose of git tag?

The:

git tag

command creates named references for specific commits.

Tags are commonly used to mark:

• releases
• milestones
• production versions

Example

Create tag:

git tag v1.0

Push tag:

git push origin v1.0

Types of Tags

Lightweight Tag

Simple commit reference.

Annotated Tag

Stores:

• author
• date
• message

Example:

git tag -a v1.0 -m "First release"

Why Tags are Important

Release Management

Track application versions.

Easy Rollback

Restore stable versions quickly.

CI/CD Integration

Deployment pipelines often use tags.

Real-World Usage

Production releases commonly use:

v1.0
v2.1
release-2026

naming conventions.

How do you revert a commit that has already been pushed to the remote repository?

To safely undo a pushed commit, Git provides:

git revert

This creates a new commit that reverses previous changes.

Example

git revert commit-id

Why git revert is Preferred

Safe for Shared Repositories

Does not rewrite commit history.

Maintains Audit Trail

Original commit remains visible.

Collaboration Friendly

Avoids breaking team repositories.

Difference Between revert and reset

After Revert

Push reverted commit:

git push origin main

Real-World Importance

Revert is commonly used in:

• production hotfixes
• release rollback
• enterprise Git workflows

because safety is critical in collaborative repositories.

What is the significance of the master branch in Git?

Traditionally, the:

master

branch was the default primary branch in Git repositories.

Modern repositories often use:

main

instead.

Purpose of Master/Main Branch

The primary branch usually contains:

• stable code
• production-ready code
• release versions

Importance

Central Integration Branch

Feature branches merge into it.

Deployment Source

Production deployments often originate here.

Stable Codebase

Only reviewed and tested code should exist.

Typical Workflow

main/master
    ↑
feature branches

Modern Industry Practice

Most organizations now prefer:

main

instead of:

master

due to updated naming conventions.

Real-World Usage

The main branch plays a critical role in:

• CI/CD pipelines
• release management
• production deployments
• agile development workflows