Techie BabajiLearn to Code. Build Real Skills.
DevOps · Git

Branching Strategies

A branching strategy is your team’s agreement on how changes travel from idea to production.

Beginner 5 min Lesson 5 of 30
Before you start:Git Fundamentals
0/30 in DevOps
On this page · 5 min · Beginner

On this page

  1. Learning objectives
  2. Explanation
  3. Code example
  4. Step by step
  5. Real-world use
  6. Common mistakes
  7. Best practices
  8. Remember this
  9. Practice exercise
  10. Mini quiz
  11. Related topics
  12. My notes
Reading time
5 min
Difficulty
Beginner
Updated
Oct 29, 2026

Related tutorials

Interview questions

Learning objectives#

  • Create and switch branches
  • Compare GitHub Flow, trunk-based and GitFlow
  • Name branches consistently
  • Tag releases

Explanation#

A branch is a movable pointer to a commit; creating one is cheap. git switch -c feature/login creates and switches.

GitHub Flow: main is always deployable; short-lived feature branches merge via pull requests. Simple and popular.

Trunk-based development: very short branches (hours) or direct commits to main behind feature flags. Best for high-frequency delivery.

GitFlow: develop, release and hotfix branches. Heavier; useful for software with scheduled versioned releases.

Code example: GitHub Flow in practice#

ShellGitHub Flow in practice Illustrative
git switch main && git pull
git switch -c feature/product-search


# ...edit, commit in small steps...
git add . && git commit -m "Add product search endpoint"
git push -u origin feature/product-search
# open a pull request → review → CI passes → merge → delete branch


git switch main && git pull
git tag -a v1.4.0 -m "Product search" && git push origin v1.4.0
Expected output
main always contains reviewed, tested code; v1.4.0 marks exactly what was released.

This example is illustrative. Copy or download it and run it in your own environment; the expected output is shown above.

Step-by-step explanation#

  1. Start from an up-to-date main.
  2. Work on a short-lived feature branch.
  3. Merge through a reviewed pull request.
  4. Tag releases with semantic versions.

Real-world use case#

Most web teams use GitHub Flow with automatic deployment of main.

Common mistakes#

Long-lived branches

Branches open for weeks create painful merge conflicts. Merge small changes often.

Choosing GitFlow by default

For continuously deployed web apps it adds overhead without benefit.

Best practices#

  • Keep branches short-lived
  • Name branches feature/, fix/, chore/
  • Use feature flags for unfinished work
  • Tag releases with semver

Remember this#

Branch = cheap pointer.

GitHub Flow: main + short feature branches + PRs.

Short branches = fewer conflicts.

Practice exercise#

Your task: List all branches including remote ones.

Show solution
Shell Illustrative
git branch -a

Mini quiz#

Branching Strategies quizMultiple choice Question 1 of 1

In GitHub Flow, what is true about main?

Score so far: 0/0

Want more? Practise all DevOps MCQs · DevOps interview questions

My notes#

Saved in this browser.

Progress is saved in this browser. Sign in to sync.