This guide shows what to do after your team has chosen a branching model: start a feature, review it, prepare a release, and carry a hotfix back to ongoing work. For the decision itself, use our GitFlow versus trunk-based comparison.

Before running the examples

The examples assume a repository with a remote named origin, a default branch named main, and a clean working tree. Substitute your branch names. GitFlow examples also assume an existing develop branch. Use a practice repository first; these commands are examples, not a universal release policy.

A short feature branch with GitHub Flow

Start from the latest default branch and make one focused change. For trunk-based teams, keep this review cycle short enough to integrate at least daily; a pull request does not itself make a workflow trunk-based.

git switch main
git pull --ff-only origin main
git switch -c feature/add-search
# Edit and test the change.
git add src/search.js
git commit -m "feat(search): add query filtering"
git push -u origin feature/add-search

Open a pull request, let CI run, and address the review. Merge through your repository's protected-branch process. If you squash commits, make the final squash message follow your release convention; the intermediate messages may not survive.

Use the Conventional Commits formatter for the message, and the text Diff Checker when comparing pasted configuration or documentation. The web tool compares text; it does not inspect your Git repository.

Starting and finishing a GitFlow feature

In GitFlow, features normally branch from develop. After review and tests, integrate there using the merge strategy agreed by your team.

git switch develop
git pull --ff-only origin develop
git switch -c feature/add-search
# Edit, commit, test and push; then open a PR targeting develop.

Preparing a release without losing its fixes

A GitFlow release branch stabilizes a selected set of changes. Finish release fixes there, test the result, merge it to the production branch, tag it, and merge the fixes back into develop. Omitting that last step can make the next release reintroduce a bug.

git switch develop
git switch -c release/1.2.0
# Update release metadata, commit stabilization fixes and run tests.
git switch main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
git switch develop
git merge --no-ff release/1.2.0
# Push the reviewed branches and tag according to your release process.

A trunk-based team can also maintain a release branch when it needs a stable version. The difference is that new development continues to integrate on trunk instead of accumulating on a permanent second integration branch.

Carrying a GitFlow hotfix forward

Branch from the affected production version. Apply and test the fix, merge it to the production branch, and carry it into ongoing development. If a release branch is active, agree where the fix must also land.

git switch main
git pull --ff-only origin main
git switch -c hotfix/login-timeout
# Make the fix, commit it and run tests.
git switch main
git merge --no-ff hotfix/login-timeout
git tag -a v1.2.1 -m "Fix login timeout"
git switch develop
git merge --no-ff hotfix/login-timeout

A review checklist for each change

  • Is the target branch correct?
  • Are the tests checking the changed behavior?
  • Will the final merged commit message produce the intended release notes?
  • Have release-only fixes reached the next development version?
  • Can an incomplete feature be split into smaller changes or hidden behind a flag?

For message validation and release automation, continue with the commitlint and Husky setup guide.

Sources