Lab: Trunk-based development, conventional commits and versions

What you will learn in this TP

• Work with short branches
• Automate a rule with a hook
• Version and undo

Introduction #

What you will learn in this section

• Work with short branches
• Automate a rule with a hook
• Version and undo

Context. Your team merges long branches once a month and spends days solving conflicts. You set up a tooled trunk-based workflow.

Prerequisites: Git 2.30 or later  ·  Estimated time: 35 min

A repository with a readable history, two published versions and a rollback.

Hands-on #

Guided steps, with their solution.

1. 1. Create the repository

   Why? main is the only long-lived branch: it must always be releasable.

   Initialise a repository with a small application and a first commit on main.

2. 2. Enforce conventional commits

   Why? An automatically checked rule no longer depends on everyone's memory.

   Write a commit-msg hook rejecting messages that do not follow type(scope): description, then test it.

3. 3. A short branch and its merge

   Why? A branch lasting a few hours merges without conflict and is easy to review.

   Create feat/remise, add a discount function in two small commits, update the branch with rebase then merge it (squash) into main.

4. 4. Publish versions

   Why? Semantic versioning tells users what they risk when upgrading.

   Tag v1.0.0, add a conventional fix, deduce the next number, tag it and generate the list of changes between the two versions.

5. 5. Undo without rewriting history

   Why? On a shared branch, you undo with a new commit: nobody loses their work.

   Introduce a faulty commit, find it with git bisect and undo it with git revert.

Difficulty level : ●●○○○ (2/5)