Skip to content

Git usage

Jump to bottom
Julien Déramond edited this page Oct 18, 2021 · 9 revisions

Commit messages

As mentionned in our DoD for release, you need to use conventional commits messages to ease changelog generation.

The minimum required is the following:

<type>(<optional scope>): <description> #<optional issue number>

with <type> being one of those: fix:, feat:, build:, chore:, ci:, docs:, style:, refactor:, perf:, test:.

<optional scope> is mandatory when you're working on Boosted components. <optional issue number> is optional. Issue number shall be indicated if existing.

Examples of commit messages:

  • fix(orange navbar): change 1px border bottom color (#808) when there is no issue for this bug
  • fix(#303): modify the button alignment when there is already an issue for this bug
  • feat(navbar): current item's border alignment after #252
  • chore(merge v4-dev): latest patched commit → 91d0a65

Branch naming

I tend to follow git-flow branch naming convention—but not git-flow itself since our releases and features require some more steps.

Bootstrap on its side recommends the following pattern:

<target branch>-<author nickname>-[scope]

For example main-ffoodd-rtl would be a branch working on RTL which targets main.

History

Trying to keep things readable, here're a few advices:

  • don't make merge commits: always try to rebase your branch instead. If there's no conflict, GitHub will offer a way in its "Merge" button options: I recommend using Rebase and merge. You could try Squash and merge but ensure to name your PR accurately.
  • if you have conflicts, please learn and use git rebase (maybe using its interactive mode). It's a good thing to master since it'll also allow you to revamp your history on your branch before merging, helping to keep your history as clear as possible.
  • ensure to only have atomic commits where possible: each commit should work standalone, meaning e.g. you shouldn't commit HTML, CSS, JS nor docs separately for a feature.
  • a good history allows to easily revert any feature, fix, or whatever at once.

States

Obviously, main branches (ATM v4-dev and main) should always be stable and ready to release.

While working on other branches, try to keep your branch stable at any commit—unless you're starting something over: in that case, ensure to open a draft PR while iterating, and only make it "Ready for review" when you're stable and almost done.

Naturally, this also means you shouldn't merge anything that wouldn't be ready for release.

Clone this wiki locally