Git Workflow Patterns

Table of Contents

1. Course presentation
2. Introduction to Git Workflow Patterns
3. Trunk Based Development

• 3.1 Module overview
• 3.2 Key features of Trunk-Based Development
• 3.3 Advantages and disadvantages
• 3.4 Demonstration: Trunk-Based Development via the CLI
• 3.5 Ideal use case and affected teams
• 3.6 How to defend and implement Trunk-Based Development

4. Git Flow

• 4.1 Module overview
• 4.2 Key Features of Git Flow
• 4.3 Git Flow branches in detail
• 4.4 Advantages and disadvantages
• 4.5 Git Flow AVH extension
• 4.6 Demo: Git Flow with Sourcetree
• 4.7 Demo: Git Flow via the CLI
• 4.8 Ideal use case and affected teams
• 4.9 Teach and implement Git Flow
• 4.10 Git Flow variants: GitHub Flow and GitLab Flow

5. The Feature Branching

• 5.1 Module overview
• 5.2 Key characteristics of Feature Branching
• 5.3 Advantages and disadvantages
• 5.4 Demonstration: Feature Branching via the CLI
• 5.5 Ideal use case and affected teams
• 5.6 How to defend and implement Feature Branching

6. Final summary and comparative table

1. Course presentation

This course, titled Git Workflow Patterns, is taught by Markus Neuhoff, Engineering Principal with over a decade of engineering and leadership experience. It is available on the Pluralsight platform.

Git is an amazing tool for tracking source code, but the big question is: how to use it effectively within a team? Every team has different needs, and there are several Git workflows suitable for varying contexts.

Course objectives

At the end of this training, you will be able to:

• Understand the most common Git workflows in the software industry
• Evaluate the advantages and disadvantages of each approach
• Determine which workflow best suits your team based on its unique characteristics
• Effectively advocate for and implement workflow in your organization

Workflows covered

1. Trunk-Based Development — often considered the gold standard for high-performance teams with strong CI/CD practices
2. Git Flow — a complex workflow, ideal for teams and highly regulated industries
3. Feature Branching — an intermediate workflow that seeks to balance the speed of Trunk-Based Development with traceability requirements

Prerequisites

Before taking this course, you should:

• Be familiar with basic Git concepts (commits, branches, push, pull)
• Have a good understanding of your organization’s software development needs

2. Introduction to Git Workflow Patterns

Course format

This course is designed in a modular way: each workflow has its own independent module. You can therefore choose to watch only the module(s) that interest you, without necessarily viewing the entire course in order.

For each workflow, the structure of each module is as follows:

1. Key factors: review of team characteristics that would make this workflow appropriate or inappropriate
2. Demonstration: put into practice to understand how the workflow fits into your context
3. Implementation guide: tips for defending, training and deploying it in your environment

Workflow overview

Note on tools used: In this course, the instructor uses Bitbucket for demonstrations, mainly because this tool offers native visualization of Git branches in its interface. This choice is not a recommendation from Bitbucket over GitHub. The two platforms support all these workflows equally, since the technical base is based on Git.

3. Trunk Based Development

3.1 Module overview

Module duration: 17 minutes 10 seconds

Trunk-Based Development (TBD) is also known as centralized workflow in some older documentation — the two terms mean exactly the same thing.

This module covers:

• The definition of Trunk-Based Development and how it works
• Its advantages and disadvantages
• A demonstration via the Git command line (CLI)
• The types of teams that would benefit the most
• Strategies to defend and implement it

3.2 Key Features of Trunk-Based Development

Trunk-Based Development is based on a fundamentally simple principle:

• A single long-lived branch: the main branch (commonly called main or trunk) contains all of the production code
• Developers commit directly to main: there are no long-lived branches for features
• Ephemeral branches tolerated: if your process requires a short code review before going into production, very short branches can exist, provided that they:
• Last less than 24 hours
• Contain the work of a single developer (or a pair/mob)
• Do not represent large pieces of work
• main is always stable and deployable: each commit must keep production in a stable state, ready to deploy at any time
• Feature flags: to manage features under development without disrupting production, Trunk-Based Development uses feature flags (also called feature toggles). These flags allow you to disable an incomplete feature in the deployed code, until it is ready

main: ---o---o---o---o---o---o---o--->
          ↑   ↑   ↑   ↑   ↑   ↑
        commits directs des développeurs

3.3 Advantages and disadvantages

Important insight: A perceived advantage in one organization may be a disadvantage in another. Analyze each point through the lens of your organizational context.

Advantages ✅

Disadvantages ❌

3.4 Demonstration: Trunk-Based Development via the CLI

Demo Prerequisites

• A Bitbucket (or GitHub) account with access to the sample repository
• Git installed on your local machine

Step 1 — Clone the repository

git clone <url-du-dépôt>
cd <nom-du-dépôt>

Step 2 — Check Current Status

git status
git log --oneline

The visualization on the Commits tab of Bitbucket only shows a single line (a single branch) — this is the nature of Trunk-Based Development.

Step 3 — Make a change

Make a small change to one of the files in the repository (for example, modify index.html or a CSS file).

Step 4 — Index and commit changes

git add .
git commit -m "feat: description courte de la modification"

Step 5 — Push to master branch

git push origin main

Step 6 — Check on remote repository

Go back to Bitbucket (or GitHub) and check that your commit appears on the main branch. The visualization of the branches remains a single, straight line.

Trunk-Based Development Workflow Summary

1. git pull origin main          # Récupérer les dernières modifications
2. [faire des modifications]
3. git add .
4. git commit -m "message"
5. git push origin main          # Pousser directement sur main

Best practices: Make commits small and frequent. This reduces the risk of conflicts and keeps production stable.

Note for GitHub users

If you use GitHub rather than Bitbucket, you can view branches in several ways:

• Via a desktop Git client (e.g.: GitHub Desktop, Sourcetree)
• Via a Chrome extension that displays branch graphs
• Via the git log --oneline --graph --all command in the terminal

3.5 Ideal use case and teams involved

To illustrate use cases, this course uses the fictitious example of Carved Rock Fitness, a large outdoor retailer with a large IT workforce, divided into several engineering teams.

The Carved Rock Fitness teams

E-commerce Team:

• More than 100 engineers divided into several sub-teams
• Widely varied experience levels (beginners to seniors)
• Codebase: a monolith (massive single repository containing all features)
• Mandatory SOC 2 compliance (customer data, financial data)
• The deployment process must be strictly traced with numerous validations, code reviews and tests

Innovations Team:

• Only 5 engineers, all seniors
• Focused on creating new customer experiences
• Minimal access to existing customer data
• Great fan of pairing (pair programming) and mobbing (group programming)
• Was able to build his own CI/CD pipeline, allowing him to deliver code quickly

Content Management Team:

• About 10 engineers
• Intermediate compliance level
• Manages content creation and publishing

Evaluation for Trunk-Based Development

The Innovations team is the ideal case for Trunk-Based Development because:

• 5 senior engineers can easily coordinate
• Their strong CI/CD pipeline ensures stability with every commit
• Pairing and mobbing cause multiple people to see the code before it is committed — this replaces formal code review
• Low compliance constraints linked to lack of access to sensitive customer data

3.6 How to defend and implement Trunk-Based Development

Arguments for engineers

• Reduction of merge conflicts: developers who have already experienced painful line-by-line conflict resolutions will appreciate seeing them significantly reduced
• Smaller, more frequent commits: less pressure on each individual commit
• Faster feedback: bugs are detected earlier thanks to automated tests that run on each commit

Arguments for technical leaders

• Speed of delivery: the code goes directly into production after validation of the tests
• Visibility of production status: we always know exactly what is in production and when it was deployed
• Less technical debt linked to branches: no old branches lying around for months

Arguments for compliance managers

• Direct traceability: each commit is associated with an author, a date and a message
• Smaller, more frequent deployments: easier to isolate a problematic change

Implementation strategy

1. Assess CI/CD maturity: Above all, ensure robust automated testing and a reliable deployment pipeline are in place
2. Train the team on feature flags to manage current features
3. Start gradually: if the team comes from a workflow with long-lived branches, gradually reduce the lifespan of the branches
4. Establish commit rules: small commits, clear messages, high frequency
5. Set up alerts: automatic alerts on broken builds are essential to maintain the stability of main

4. Git Flow

4.1 Module overview

Module duration: 46 minutes 37 seconds

Git Flow is the most sophisticated of all Git workflows. It is a highly structured, multi-branched workflow that provides high traceability and supports formal and complex release processes.

This module covers:

• The definition of Git Flow and its characteristics
• Its advantages and disadvantages
• A demonstration with the Sourcetree graphics tool
• A demonstration via the Git CLI
• The types of teams that would benefit the most
• How to teach and implement Git Flow
• Git Flow variants: GitHub Flow and GitLab Flow

4.2 Git Flow Key Features

Git Flow differs from other workflows in several fundamental aspects:

• Multiple long-term branches: unlike Trunk-Based Development which only has one, Git Flow has several
• Strong traceability, auditability and testing support: ideal for software products with specific, planned releases
• Established processes for urgent fixes: hotfixes have their own branch type in Git Flow
• Protection of main branches: main and develop do not allow direct commits — everything goes through pull requests

4.3 Git Flow branches in detail

Git Flow defines five branch types:

Long-term branches (permanent)

1. main (or master)

• Represents the current state of production
• Does not accept direct commits — protected by branch rules
• Only receives merges from release/ and hotfix/ branches
• Each merge on main represents a new version in production

2. develop

• Contains the code that will be integrated into the next release
• Represents the future state of production after the next deployment
• Also generally does not accept direct commits
• It is from develop that the feature/ branches are created

Ephemeral (temporary) branches

3. feature/<name>

• Created from: develop
• Merged to: develop
• Contains work on a specific feature
• May only exist while the feature is being developed
• Each feature has its own branch, making it easier to track work in progress

4. release/<version>

• Created from: develop
• Merged to: main AND develop
• Used to prepare a release: last-minute minor bug fixes, update version numbers, etc.
• Allows you to continue the development of new features on develop while the release is prepared
• Once finalized, a version tag is created on main

5. hotfix/<name>

• Created from: main
• Merged to: main AND develop
• Used to fix a critical bug in production without waiting for the next release
• This is the only ephemeral branch that starts directly from main
• Allows you to deploy an urgent patch while following the structured process

main:     ---o-----------o-----------o----------->
              |           ↑           ↑
develop:  ----o---o---o---o---o---o---o---------->
              |   |       ↑       |   ↑
feature/A:    o---o---o---/       |   |
                              |   |   |
feature/B:                    o---o---/
                                  ↑
hotfix/1:                    o---o
                             |   ↑(vers main ET develop)

Note on support/ branches: Git Flow also defines support/ branches to maintain multiple versions in production simultaneously, but they are less commonly used.

4.4 Advantages and disadvantages

Reminder: As with all workflows, the advantages and disadvantages depend entirely on the context of your organization.

Advantages ✅

Disadvantages ❌

4.5 The Git Flow AVH extension

While demoing Git Flow, you will quickly realize that there are a lot of Git commands to run. Fortunately, there is an extension that automates the vast majority of them.

Which version should I use?

There are two versions of the Git Flow extension:

• Git Flow AVH (A Virtual Home) — this is the current version, the one you should use. Installation instructions can be found on their GitHub page.
• The original Git Flow extension — not updated since 2012, it does not have the new features (custom hooks, custom naming of main branches, etc.). Avoid.

Good news: If you use Git for Windows, the Git Flow AVH extension is already included automatically. It is also integrated into many popular graphics Git clients, including Sourcetree.

Git Flow extension commands

Once the extension is installed, here are the commands available from the command line:

Initialization

# Initialiser Git Flow sur un dépôt existant
git flow init

This command is interactive: it will ask you which branches to use for main and develop, as well as the desired prefixes for the hotfix/, release/ and feature/ branches. It is generally recommended to leave the default values.

Feature management

# Créer une nouvelle branche de fonctionnalité (depuis develop)
git flow feature start <nom-de-la-feature>

# Publier la feature sur le dépôt distant (pour que d'autres y aient accès)
git flow feature publish <nom-de-la-feature>
# Équivalent à : git push origin feature/<nom-de-la-feature>

# Terminer la feature (merge dans develop, suppression de la branche)
git flow feature finish <nom-de-la-feature>

Release management

# Créer une branche de release (depuis develop)
git flow release start <version>
# Exemple : git flow release start 1.2.0

# Terminer la release (merge dans main ET develop, création d'un tag)
git flow release finish <version>

Hotfix management

# Créer une branche de hotfix (depuis main)
git flow hotfix start <nom-du-hotfix>

# Terminer le hotfix (merge dans main ET develop)
git flow hotfix finish <nom-du-hotfix>

Summary: The Git Flow extension significantly simplifies branch management by automating complex cross-merges (feature → develop, release → main AND develop, hotfix → main AND develop).

4.6 Demo: Git Flow with Sourcetree

Sourcetree is the free Git graphics tool developed by Atlassian (the publisher of Bitbucket). It natively integrates Git Flow support via a dedicated menu.

Demonstration steps

1. Fork the repository on Bitbucket so you have your own copy to work on
2. Clone the repository locally via Sourcetree
3. Initialize Git Flow via the Sourcetree Bitbucket/Git Flow menu

• Sourcetree will guide you through the same questions as git flow init
• It will automatically create develop branch from main

4. Create a new feature via the Git Flow menu

• Sourcetree will create the feature/<name> branch from develop and position you there automatically

5. Make changes to project files
6. Commit changes via Sourcetree interface
7. Finish the feature via the Sourcetree Git Flow menu

• Sourcetree will automatically merge feature/<name> branch into develop
• Feature branch will be deleted

8. Create a release via the Git Flow menu

• Sourcetree will create the release/<version> branch from develop

9. Finish the release via the Git Flow menu

• Sourcetree will merge the release into main AND into develop
• A version tag will be created on main

10. Observe the branch visualization in the Commits tab of Bitbucket — the diagram now shows several branches with their crossed merges

Sourcetree Advantage

Sourcetree’s GUI is particularly valuable to Git Flow because it makes all branches and their relationships visible. The complexity of the workflow becomes much more visually understandable.

4.7 Demo: Git Flow via CLI

This demo picks up where the Sourcetree demo left off and adds complexity to reflect real-world scenarios.

Demonstration scenario

• Branch protections configured on Bitbucket: main and develop can only receive merges through pull requests
• Two features in parallel to simulate realistic teamwork
• A production hotfix to manage urgently
• A release to create and deploy

Pre-configuration on Bitbucket

Change default branch

1. Go to repository settings
2. Change the default branch from main to develop — this makes it easier to follow for future engineers who clone the repository

Configure the branching model

Bitbucket allows you to specify a branch template that exactly matches Git Flow:

• Set main as production branch
• Add protections to develop: prohibit direct commits, require pull requests
• Add protections on main: prohibit direct commits, require pull requests

Note for GitHub users: Branch protections are not supported on private non-Enterprise and non-Team GitHub accounts. You will need a paid account to enable this feature.

Step 1 — Initialize Git Flow locally

git flow init
# Répondre aux questions de configuration (laisser les valeurs par défaut recommandées)

Step 2 — Start two features in parallel

# Feature A
git flow feature start feature-A
# [faire les modifications pour la feature A]
git add .
git commit -m "feat: implémentation de la feature A"
git push origin feature/feature-A

# Revenir sur develop pour créer la feature B
git checkout develop
git flow feature start feature-B
# [faire les modifications pour la feature B]
git add .
git commit -m "feat: implémentation de la feature B"
git push origin feature/feature-B

Step 3 — Complete features via pull requests

Since develop is protected and does not accept direct merges:

1. Create a pull request from feature/feature-A to develop on Bitbucket
2. Have the pull request approved and merged
3. Repeat for feature/feature-B

# Après merge des PR, mettre à jour develop en local
git checkout develop
git pull origin develop

Step 4 — Handle an urgent hotfix

An alert arrives: there is a critical bug in production!

# Créer le hotfix depuis main
git checkout main
git pull origin main
git flow hotfix start correction-bug-critique

# [faire les corrections nécessaires]
git add .
git commit -m "fix: correction du bug critique en production"
git push origin hotfix/correction-bug-critique

Since main is protected:

1. Create a pull request from hotfix/correction-bug-critical to main
2. Have the PR approved and merged
3. Also create a pull request from hotfix/correction-bug-critique to develop so that the fix is reflected

# Nettoyer en local
git checkout main
git pull origin main
git branch -d hotfix/correction-bug-critique

Step 5 — Create and deploy a release

# Créer la branche de release depuis develop
git checkout develop
git pull origin develop
git flow release start 1.0.0

# [éventuellement : corrections de dernière minute, mise à jour du numéro de version]
git add .
git commit -m "chore: bump version to 1.0.0"
git push origin release/1.0.0

Since main is protected:

1. Create a pull request from release/1.0.0 to main
2. Also create a pull request from release/1.0.0 to develop
3. Have the two PRs approved and merged

# Ajouter le tag de version sur main
git checkout main
git pull origin main
git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0

Full flow summary with branch protections

develop ──────────────────────────────────────────────────────>
    │ pull depuis develop        ↑ PR merge           ↑ PR merge
    │                     feature/A          feature/B
    │
    └─ release/1.0.0 ──────────────────────────────────────────>
                               ↑ PR merge               ↑ PR merge
                             main                     develop

main ─────────────────────────────────────────────────────────>
    │                                    ↑ PR merge         ↑ PR merge (back to develop)
    └─ hotfix/correction-bug-critique ─────────────────────>

4.8 Ideal use case and teams involved

Let’s go back to the Carved Rock Fitness teams to assess suitability with Git Flow.

Team evaluation

E-commerce team (100+ engineers, monolith, SOC 2)

Git Flow is a great match for this team because:

• The team size (100+ engineers) requires a structure to manage the many features in parallel
• SOC 2 requirements align perfectly with Git Flow’s formal approval process (code reviews, pull requests, deployment traceability)
• The monolith nature benefits from release branches to coordinate deployments
• Scheduled releases correspond well to Git Flow release/ branches
• The potential presence of a release manager fits naturally into the Git Flow process

Innovations Team (5 senior engineers)

Git Flow is not recommended for this team because:

• The small size (5 people) does not justify the complexity of Git Flow
• Their agility and ability to deliver quickly would be severely hampered
• Their low compliance constraints do not require as much structure

Content Management team (10 engineers)

The case is nuanced — Git Flow could be suitable if:

• They have significant compliance requirements
• They have planned releases

But if their needs are simpler, Feature Branching would probably be a better choice.

4.9 Teaching and Implementing Git Flow

Defend Git Flow to engineers

Adopting Git Flow for engineers can seem difficult due to its perceived complexity. Here are the arguments that work well:

• Reducing painful merge conflicts: Many engineers have experienced exhausting line-by-line conflict resolution. The structure of Git Flow, with isolated feature branches, significantly reduces this risk. This argument will be well received.
• Production Emergency Management: A common concern is that Git Flow can slow down emergency responses. But thanks to hotfix/ branches, fixes can be deployed quickly and safely, without disrupting the work in progress.
• Clarity on work in progress: each feature having its own branch, each engineer knows exactly where their work is at all times.

Defend Git Flow to technical leaders

• Bottleneck Prevention: with 100+ engineers on the same repository, Git Flow is designed exactly to avoid blockages thanks to its features and releases strategy
• Multi-team management: particularly relevant when several sub-teams contribute to the same monolith
• The role of Release Manager: Many organizations already informally have someone who manages complex merges and plans releases. Git Flow formalizes this role. If someone in the organization always coordinates deployments, giving them a formal title and a clear process can add tremendous value.

Defend Git Flow to Compliance Officers

• Full traceability: every line of code can be traced from feature branch to release, with all approvals in between
• Reducing the risk of audit failure: Having been in the situation of undergoing an audit and seeing your team fail due to an insufficient process is an experience that no one wants. Git Flow provides the structure needed to keep listeners happy.
• Formal review processes: mandatory pull requests on develop and main create a natural audit trail

Implementation strategy

Phase 1 — Preparation and communication

1. Identify and train one or two workflow “champions” among experienced engineers
2. Organize a presentation for the whole team
3. Create quick reference guides (cheat sheets) for Git Flow commands

Phase 2 — Training

1. Organize practical training sessions, ideally hands-on
2. Explain in detail what happens to the code once it leaves the developer’s machine — this is the hardest part to understand
3. Use branch diagrams to visualize flow

Phase 3 — Phased implementation

1. Start with a single team or pilot project
2. Configure branch protections on the repository
3. Designate a Release Manager (formal or informal) to coordinate the process
4. Clearly define branch naming conventions
5. Document the complete process specific to your organization

Recommended naming conventions (Git Flow AVH default):

feature/<nom-descriptif>       ex: feature/user-authentication
release/<version-sémantique>   ex: release/2.3.0
hotfix/<description>           ex: hotfix/fix-payment-null-pointer
support/<version>              ex: support/1.x

4.10 Git Flow variants: GitHub Flow and GitLab Flow

During your research on Git workflow patterns, you have probably encountered several variations. The trainer presents two particularly common ones.

GitHub Flow

GitHub Flow is a simplified approach that only has two types of branches:

1. main — always represents production
2. Feature branches — each feature in its own branch

The fundamental difference with Git Flow: feature branches are merged directly into main, and therefore directly into production.

GitLab Flow

GitLab Flow is a more complete and interesting variant. Its main feature is that it easily supports separate test environments (staging, QA), which Git Flow handles less naturally.

GitLab Flow Architecture

GitLab Flow uses multiple long-lived branches, each associated with an environment:

feature/* ──────────────────────────────────────────────────>
    │ merge via PR                 
    ↓                              
main ───────────────────────────────────────────────────────>
    │ auto-déploiement            ↑ merge périodique
    │ vers DEV                    │
    ↓              testing ───────────────────────────────>
    │                    │ auto-déploiement vers STAGING
    │                    │                    ↑ merge
    │                    ↓     production ──────────────>
    │                              │ auto-déploiement vers PROD

GitLab Flow in detail:

1. Engineers create ephemeral feature branches and merge them into main
2. The main branch automatically deploys to the shared development environment
3. main is periodically merged into the testing branch, which automatically deploys to the staging/QA environment
4. When testing is merged into production, deployment to production is triggered

Advantages of GitLab Flow over Git Flow

• No hotfix/ branches or release/ branches to manage and track — many engineers appreciate this simplicity
• Native support for multiple environments (dev, staging, prod) with automatic deployments
• Less complex than Git Flow while offering more structure than pure Feature Branching

When to choose GitLab Flow?

GitLab Flow is a good choice when:

• Your team has separate testing environments (staging, QA)
• You want automated deployments per environment
• Git Flow seems too complex but Feature Branching lacks structure

5. Feature Branching

5.1 Module overview

Module duration: 17 minutes 4 seconds

Feature Branching is a workflow that seeks to find a balance between the simplicity of Trunk-Based Development and the robustness of Git Flow. It’s often described as a “happy medium” between the two extremes.

This module covers:

• The definition of Feature Branching and its characteristics
• Its advantages and disadvantages
• A demonstration via the Git CLI
• The types of teams that would benefit the most
• Strategies to defend and implement it

5.2 Key characteristics of Feature Branching

Feature Branching is based on the following principles:

• A permanent main branch: main is always present and represents production
• Ephemeral feature branches: from main, temporary branches are created for each new feature, then merged back once completed
• Parallel development: several features can be developed simultaneously on their respective branches
• main always ready for production: features are only merged into main once completed and validated
• Integration with CI/CD: With a strong CI/CD pipeline, main can always reflect the current state of production

main:        ---o---------o---------o-------o--------->
                |         ↑         ↑       ↑
feature/A:      o---o---o-/         |       |
                                    |       |
feature/B:          o---o---o---o---/       |
                                            |
feature/C:                  o---o----------/

In this diagram (read from left to right as time progresses):

• main receives one-off commits as features are merged
• Each feature branch starts from main and returns there via a pull request
• Several features can coexist at the same time

Reading branch diagrams: Git diagrams are generally read from left to right (past to present) or sometimes from bottom to top (on some interfaces like Bitbucket), where the most recent commit is at the top.

5.3 Advantages and disadvantages

Advantages ✅

Disadvantages ❌

5.4 Demonstration: Feature Branching via the CLI

Demo Prerequisites

• A Bitbucket (or GitHub) account with access to the sample repository
• Git installed on your local machine

View of the repository before starting

In Bitbucket’s Commits tab, the branch diagram is read from bottom to top (most recent commit is at the top). We can already see an existing feature branch displayed in red — this is an example of a feature in progress.

Step 1 — Fork and clone the repository

# Après avoir forké le dépôt sur Bitbucket (ou importé sur GitHub)
git clone <url-de-votre-fork>
cd <nom-du-dépôt>

Step 2 — Create a feature branch

# Vérifier qu'on est bien sur main et à jour
git checkout main
git pull origin main

# Créer et se positionner sur la branche de feature
git checkout -b feature/ma-nouvelle-fonctionnalite

# Alternative moderne (Git 2.23+)
git switch -c feature/ma-nouvelle-fonctionnalite

Step 3 — Make Changes

Make your changes to the project files. The exact content of the changes doesn’t matter — what matters is the Git process.

Step 4 — Commit changes

git add .
git commit -m "feat: ajout de la nouvelle fonctionnalité"

Step 5 — Push branch to remote repository

git push origin feature/ma-nouvelle-fonctionnalite

Step 6 — Create a pull request

On Bitbucket (or GitHub), create a pull request for feature/my-new-feature to main:

1. Go to the repository page
2. Click on “Create pull request”
3. Select feature/my-new-feature as source branch and main as target branch
4. Write a clear description
5. Assign reviewers if necessary
6. Submit the pull request

Step 7 — Merge the pull request

Once the code review is approved, merge the pull request. On Bitbucket or GitHub, this is done via the web interface.

Step 8 — Delete feature branch

After merge, delete the branch — it is no longer useful.

Delete remote branch:

git push origin --delete feature/ma-nouvelle-fonctionnalite

Delete local branch:

# Se repositionner sur main d'abord
git checkout main
git pull origin main

# Supprimer la branche locale
git branch -d feature/ma-nouvelle-fonctionnalite

Note: The -d flag (lowercase) deletes the branch only if it has already been merged. If you want to force the deletion of a non-merged branch (be careful!), use -D (uppercase).

Summary of Feature Branching flow

# 1. Partir de main à jour
git checkout main
git pull origin main

# 2. Créer la branche de feature
git checkout -b feature/<nom-descriptif>

# 3. Développer et commiter
git add .
git commit -m "feat: description de la fonctionnalité"

# 4. Pousser vers origin
git push origin feature/<nom-descriptif>

# 5. Créer une PR sur Bitbucket/GitHub

# 6. Après approbation et merge de la PR
git checkout main
git pull origin main

# 7. Nettoyer les branches
git branch -d feature/<nom-descriptif>
git push origin --delete feature/<nom-descriptif>

Check local branch status

# Lister toutes les branches locales
git branch

# Lister les branches distantes
git branch -r

# Lister toutes les branches (locales et distantes)
git branch -a

Keep your branch up to date with main

To avoid conflicts during the final merge, it is recommended to regularly synchronize your feature branch with main:

# Méthode 1 : merge de main dans la feature branch
git checkout feature/<nom>
git merge main

# Méthode 2 : rebase de la feature branch sur main (historique plus propre)
git checkout feature/<nom>
git rebase main

5.5 Ideal use case and teams involved

Let’s meet the Carved Rock Fitness teams one last time to assess the suitability with Feature Branching.

Description of teams

E-commerce team (100+ engineers, monolith, SOC 2)

• Large team with many features in simultaneous development
• Monolith shared by many engineers of varying levels (beginners to seniors)
• Strict SOC 2 compliance with mandatory code reviews, testing and traceability of deployments

Innovations Team (5 senior engineers)

• Very small team of seniors
• Strong culture of pairing and mobbing
• Their own code base, separate from the monolith
• Mature CI/CD pipeline they built themselves
• Ability to deliver quickly

Content Management team (10 engineers)

• Intermediate size (approximately 10 engineers)
• Manages platform content
• Intermediate compliance level
• More homogenous team

Evaluation for Feature Branching

The Content Management team is the ideal case for Feature Branching because:

• 10 engineers: large enough to benefit from the structure, small enough not to be overwhelmed by the complexity
• Pull requests provide a formal code review without the heaviness of Git Flow
• Basic traceability provided by feature branches is sufficient for their compliance requirements
• The ability to work on multiple features in parallel matches their work pace

5.6 How to defend and implement Feature Branching

Arguments for engineers

• Simplicity vs Git Flow: if the team comes from Git Flow, Feature Branching will be seen as a welcome simplification. If it comes from Trunk-Based Development, pull requests and feature branches offer more safety nets.
• Work isolation: each developer works in their own branch, without risk of disrupting the work of colleagues
• Natural code review: pull requests are a natural mechanism for sharing knowledge within the team

Arguments for technical leaders

• Visibility of work in progress: each feature branch is visible in the repository, giving a clear view of what is under development
• Gateway to Compliance: For teams that need more control than a direct commit to main, Feature Branching provides the minimum level of control required
• Moderate scalability: works well for teams of around 5 to 20 engineers

Arguments for compliance managers

• Traceability of changes: each feature is clearly identified and its path to production is documented
• Mandatory code reviews: pull requests can be configured to require approvals before allowing merge
• Ticket links: branch names can reference tracking tickets (e.g.: feature/JIRA-1234-user-authentication)

Implementation strategy

Preparation

1. Define clear naming conventions for branches
2. Configure branch protections to main (require PRs, CI tests)
3. Establish rules on the maximum lifespan of feature branches (e.g.: 1-2 weeks)

Training

1. Train the team on the pull request process
2. Define clear criteria for PR approval
3. Establish pull request templates to standardize descriptions

Good practices to establish

1. Short branches: the longer a feature branch lives, the greater the risk of conflict. Aim for short cycles.
2. Regular synchronization: encourage developers to regularly merge main into their feature branch
3. Descriptive naming: feature/TICKET-123-short-description rather than feature/ma-branche
4. Deletion after merge: always delete feature branches after their merge to keep the repository clean

Recommended naming conventions:

feature/<ticket-id>-<description>    ex: feature/CMS-42-article-editor
fix/<description>                    ex: fix/image-upload-timeout
chore/<description>                  ex: chore/update-dependencies

6. Final summary and comparative table

Summary of the three workflows

This course covered three distinct Git workflows, each with their own strengths and weaknesses:

Trunk-Based Development

• The gold standard for small teams with excellent CI/CD practices
• Direct commits to main, continuous deployment
• Ideal for agile teams with few compliance constraints

Git Flow

• The preferred workflow for large, compliance-minded organizations
• Multiple long-term branches, planned releases, structured hotfixes
• Ideal for teams of 20+ engineers with SOC 2 or equivalent requirements

Feature Branching

• A workflow that seeks to balance the speed of Trunk-Based Development with the traceability requirements needed for auditing
• Ephemeral feature branches, pull requests, main always stable
• Ideal for mid-sized teams (5-20 engineers)

Workflow comparison table

Carved Rock Fitness Team Recap

How to choose the right workflow for your team

To make an informed decision, ask yourself the following questions:

1. How big is your team?

• Less than 8 people → Trunk-Based Development
• Between 5 and 20 people → Feature Branching
• 20+ people → Git Flow

2. What is your CI/CD maturity level?

• Robust automated pipeline → Trunk-Based Development possible
• Basic CI/CD → Feature Branching or Git Flow

3. What are your compliance requirements?

• SOC 2, HIPAA, PCI DSS or equivalent → Git Flow
• Basic audit required → Feature Branching
• Few constraints → Trunk-Based Development

4. Do you have any releases planned?

• Yes, with fixed dates → Git Flow
• No, continuous deployment → Trunk-Based Development
• Sometimes → Feature Branching or GitLab Flow

5. How do your engineers work?

• Pairing/mobbing, great coordination → Trunk-Based Development
• Individual work on separate features → Feature Branching or Git Flow

Decision tree

Êtes-vous une petite équipe (<8 personnes) 
avec un CI/CD mature et peu de conformité ?
        │
        ├── OUI ──→ Trunk-Based Development
        │
        └── NON
              │
              └── Avez-vous 20+ ingénieurs 
                  et/ou des exigences de conformité strictes ?
                        │
                        ├── OUI ──→ Git Flow
                        │
                        └── NON ──→ Feature Branching
                                    (ou GitLab Flow si multi-environnements)

Quick Reference Git Commands

Trunk-Based Development

git pull origin main
git add .
git commit -m "type: description"
git push origin main

Git Flow (with AVH extension)

# Initialisation
git flow init

# Feature
git flow feature start <nom>
git flow feature publish <nom>
git flow feature finish <nom>

# Release
git flow release start <version>
git flow release finish <version>

# Hotfix
git flow hotfix start <nom>
git flow hotfix finish <nom>

Feature Branching

# Créer la feature branch
git checkout main && git pull origin main
git checkout -b feature/<nom>

# Développer et commiter
git add . && git commit -m "feat: description"
git push origin feature/<nom>

# Créer une PR sur Bitbucket/GitHub

# Après merge de la PR
git checkout main && git pull origin main
git branch -d feature/<nom>
git push origin --delete feature/<nom>

This document is an exhaustive summary of the training content, written in French.

Search Terms

git · workflow · patterns · ci/cd · devops · flow · feature · branch · branching · advantages · development · arguments · disadvantages · trunk-based · defend · gitlab · repository · teams · demonstration · features · via · branches · case · changes