Stop reading about Gitflow—start practicing it. This repository is a hands-on playground designed to teach you the industry-standard branching model. Whether you are a student or a professional, this guide and the built-in game will help you master collaboration.

In Gitflow, we organize work by intent. We separate the "Stable World" (Production) from the "Development World" (In-progress).

A commit is not just a save button; it is a documented transition. A clean history is the hallmark of a professional developer.

type(scope): short summary in present tense

[Optional: why was this change made? What is the impact?]

• feat: A new feature (e.g., feat: add multiplication logic).
• fix: A bug fix.
  • Note: You usually perform a fix inside a bugfix/ or hotfix/ branch.
• refactor: Code changes that neither fix a bug nor add a feature (cleaning up).
• style: Changes that do not affect the meaning of the code (white-space, formatting).
• docs: Documentation changes only.

Atomic means one commit = one task.

• Easy Reverts: If your "division" logic breaks the build, you can revert that specific commit without losing your work on "addition."
• Readability: Your teammates can understand your thought process just by reading the git log.

Work peacefully without disturbing the main codebase:

git checkout -b feature/task-name develop

This is the golden rule of Gitflow. When merging a feature back to develop:

git checkout develop
git pull origin develop   # Always update before merging!
git merge --no-ff feature/task-name
git push origin develop   # Share the integration

Why --no-ff?

• By default, Git performs a "Fast-Forward" (merging the history into a flat line).
• --no-ff forces a Merge Commit. This visually preserves the branch in your graph, showing exactly when a feature was worked on and by whom.

If production (main) crashes, don't wait for the next release:

1. Create hotfix/bug-name from main.
2. Fix it, then merge into main (with a Tag like v1.0.1).
3. Crucial: Merge it back into develop so the bug never returns!

Theory is one thing; practice is another. This repo contains an interactive validator.

1. Fork this repository to your own GitHub account.
2. Clone your fork locally.
3. Run the interactive game:

   make run

4. Follow the instructions displayed in the game and validate your progress.

💡 Tip: Don't forget to check the Cheatsheet.md file in this repository! It contains all the commands and conventions you'll need.

By finishing this game, you will master:

• Strict branching model (Develop vs Main).
• Feature isolation and clean history merging.
• Hotfix procedure for production critical bugs.
• Release tagging.

Good luck, Lead Dev! 🚀