Branches and Branching Strategies

A branch is an independent line of development. It lets you work on a new feature or a fix without touching the stable code that others use.

Think of a branch as a separate draft. You can try anything you want; as long as you have not merged, other people's work is not affected.

Without branches, the whole team would write in the same file at the same time: guaranteed chaos. With branches, each person advances in their own lane, then you bring everything together cleanly.

The basic commands already seen in module 01:

# Create a branch and switch to it
git switch -c feature/login

# List branches
git branch

# Return to main
git switch main

🔧 Mini-exercise — Write the modern command to create a feature/login branch and switch to it in one step.

In a team, you do not create branches at random: you give them a role and a conventional name. Here are the most common types.

Realistic name examples:

feature/ajout-paiement-stripe
feature/dashboard-utilisateur
release/1.4.0
hotfix/correction-faille-login

A good naming convention is free documentation: from the branch name alone, the team knows what it is about.

🔧 Mini-exercise — You must urgently fix a login vulnerability in production. Which branch prefix do you use, and propose a full name.

Git Flow is a structured strategy introduced by Vincent Driessen in 2010. It rests on two permanent branches (main and develop) and three types of temporary branches (feature, release, hotfix).

The typical cycle:

1. You start from develop to create a feature/* branch.
2. Once finished, the feature is merged into develop.
3. When enough features are ready, you create a release/* to stabilize.
4. The release is merged into main (and tagged) and into develop.
5. A critical production bug? You create a hotfix/* from main, then merge it into main and develop.

# Start a feature (without the git-flow extension)
git switch develop
git switch -c feature/panier

# ... work + commits ...

git switch develop
git merge feature/panier
git branch -d feature/panier

Git Flow shines for software shipped by versions (mobile apps, installed software). For a website deployed 10 times a day, it becomes a brake.

GitHub Flow is a simple and light strategy, designed for continuous deployment. A single permanent branch: main. Everything else goes through short feature branches and pull requests.

The golden rules:

1. main is always deployable.
2. For any work, you create a descriptive branch from main.
3. You commit regularly and open a pull request (seen in lesson 03).
4. After review and green tests, you merge into main.
5. You deploy main immediately.

git switch main
git pull
git switch -c feature/filtre-recherche
# ... commits ...
git push -u origin feature/filtre-recherche
# → open a Pull Request on GitHub

GitHub Flow is probably the best starting point for a modern team: enough structure to collaborate, enough lightness to go fast.

🔧 Mini-exercise — In GitHub Flow, write the two commands to start from an up-to-date main before creating your working branch.

git switch main
git pull

Trunk-Based Development pushes simplicity even further: everyone integrates their work into a single branch (the trunk, that is main) very frequently — ideally several times a day.

Key principles:

• Feature branches are tiny and live less than a day.
• Unfinished features are hidden behind feature flags rather than in long-lived branches.
• Continuous integration (CI) is mandatory: every commit triggers build + tests.

# Ultra-short cycle
git switch main
git pull
# small change...
git commit -am "Add the export button"
git push      # integrated into the trunk a few minutes later

The worst enemy of Git teams is branches that live for weeks. The later you integrate, the more painful the merge. Trunk-based solves that by integrating early and often.

🔧 Mini-exercise — In Trunk-Based, how do you integrate an unfinished feature without blocking others or creating a long-lived branch?

There is no universal strategy: the right choice depends on the product type, the team maturity, and the deployment frequency.

Advice: most teams should start with GitHub Flow. It offers the best simplicity / safety trade-off. You migrate to trunk-based when CI is mature, or to Git Flow only if the product requires versions.

Question 1: What is a Git branch mainly for?

a) Backing up the repository to the cloud

b) Working in isolation without affecting the stable code

c) Compressing files

d) Deleting the history

Question 2: How many permanent branches does Git Flow use?

a) A single one (main)

b) Two (main and develop)

c) None

d) One per developer

Question 3: Which strategy is best suited to a website deployed several times a day?

a) Git Flow

b) GitHub Flow or Trunk-Based

c) No branch at all

d) One branch per year

Question 4: In Trunk-Based Development, how do you hide an unfinished feature?

a) In a long-lived branch of several weeks

b) With a feature flag

c) By deleting the code every evening

d) You cannot, you must finish everything at once

Question 5: Which branch prefix do you use to fix a critical bug directly in production?

a) feature/

b) release/

c) hotfix/

d) develop/

Instructions

You work on a repository whose main is stable. You are asked to add an “About” page. Implement GitHub Flow:

1. Start from an up-to-date main.
2. Create a well-named feature branch.
3. Make a commit that adds the file apropos.html.
4. Push the branch to the remote repository to prepare a pull request.
5. List your branches to verify.

Correction

# 1. Start from an up-to-date main
git switch main
git pull origin main

# 2. Create a descriptive branch
git switch -c feature/page-apropos

# 3. Create the file then commit it
echo "<h1>About</h1>" > apropos.html
git add apropos.html
git commit -m "Add the About page"

# 4. Push the branch to the remote
git push -u origin feature/page-apropos

# 5. Check the branches
git branch

Expected result:

* feature/page-apropos
  main

Logical next step: open a pull request on GitHub to have this work reviewed and merged — that is exactly the subject of lesson 03.

Key takeaways

1. A branch isolates work without affecting the stable code.
2. Branch types: main, develop, feature/, release/, hotfix/ — each with a role.
3. Git Flow: structured, two permanent branches, ideal for planned versions.
4. GitHub Flow: simple, one main branch + pull requests, perfect for the web.
5. Trunk-Based: very frequent integration on the trunk, requires a solid CI.
6. The choice depends on the product, the team, and the deployment frequency.

What's next

Now that you know how to organize your branches, on to lesson 02 — Merge and rebase: how to bring these branches together cleanly and resolve conflicts.