Git gives you branches, merges, rebases and tags, but it doesn't tell a team how to use them together. Should everyone commit to main? Should every feature get its own branch? How long should branches live, and how are releases made? The agreed answer to those questions is a team's workflow, or branching strategy.
A good workflow keeps main working, makes it easy to review changes, reduces painful merge conflicts and lets the team release with confidence. There's no single correct choice: a solo developer, a startup that deploys twenty times a day and a company shipping a mobile app every month have different needs.
In this final Git lesson you'll compare the most common workflows, learn naming and commit message conventions that teams use everywhere, and build a simple daily routine that brings together everything from this course.
Feature branch workflow
The most widely used approach, and the one GitHub is built around:
mainalways works and is what gets released.- Every change, a feature or a fix, happens on its own short-lived branch:
feature/search-box,fix/cart-total. - The branch is pushed and a pull request is opened for review and automated tests.
- Once approved, it's merged into
main, and the branch is deleted.
It's simple, works for teams of any size and pairs naturally with code review. Its main risk is branches that live for weeks and drift far from main, which leads to big, painful merges.
Trunk-based development
In trunk-based development, everyone integrates into main (the "trunk") at least once a day. Branches, if used at all, last hours rather than days. Unfinished features are hidden behind feature flags: settings that switch new code on or off without a separate branch.
This keeps everyone close to the same code, so merge conflicts stay small, and it supports continuous delivery, releasing many times a day. It depends on strong automated tests, because every change reaches main quickly. Many large tech companies work this way.
Git Flow
Git Flow uses several long-lived branches:
| Branch | Purpose |
|---|---|
main | Released versions only, each tagged |
develop | Where finished features are combined |
feature/* | New work, branched from and merged into develop |
release/* | Preparing and testing a release |
hotfix/* | Urgent fixes to a released version |
It suits software with scheduled, versioned releases, such as desktop or mobile apps, or libraries supporting several versions. For websites that deploy continuously, its extra branches add ceremony without much benefit, and many teams now prefer the simpler approaches above.
Conventions that help every workflow
- Branch names say what the work is:
feature/dark-mode,fix/login-redirect,docs/readme-setup. - Commit messages start with a short summary in the imperative mood, under about 50 characters: "Add dark mode toggle", not "added stuff". Add a blank line and more detail when it helps.
- Conventional Commits add a type prefix, such as
feat: add dark modeorfix: correct cart total, which tools can use to generate changelogs and version numbers automatically. - Protect
main: on GitHub, branch protection rules can require pull requests, reviews and passing tests before anything is merged.
Git Workflows Syntax
A feature branch cycle
git switch main
git pull
git switch -c feature/short-description
git add -p
git commit -m "feat: describe the change"
git push -u origin feature/short-description
# open a pull request, get review, merge
git switch main
git pull
git branch -d feature/short-descriptionGit Workflows Summary
- A workflow is a team's agreement on how branches, reviews and releases work.
- Feature branch workflow: short-lived branches merged into main through pull requests.
- Trunk-based development: integrate into main daily, hiding unfinished work behind feature flags.
- Git Flow: develop, release and hotfix branches for scheduled, versioned releases.
- Clear branch names, good commit messages and a protected main help every workflow.
Git Workflows Examples
Each example shows the code, the output it produces and what each part does.
One task, from start to merge
git switch main
git pull
git switch -c fix/cart-total
git commit -am "fix: include tax in cart total"
git push -u origin fix/cart-totalAlready on 'main'
Already up to date.
Switched to a new branch 'fix/cart-total'
[fix/cart-total 6c2d8e1] fix: include tax in cart total
1 file changed, 2 insertions(+), 1 deletion(-)
branch 'fix/cart-total' set up to track 'origin/fix/cart-total'.Line-by-line explanation
- Lines 1 to 2Always start from an up-to-date main.
- Line 3A descriptive branch name with a type prefix.
- Line 4A Conventional Commits message: type, colon, short summary.
- Line 5Push the branch so a pull request can be opened.
Keeping a longer branch up to date
git switch feature/dark-mode
git fetch
git rebase origin/main
git push --force-with-leaseSuccessfully rebased and updated refs/heads/feature/dark-mode.
To https://github.com/samlee/portfolio.git
+ 52ac9e1...91fe2c3 feature/dark-mode -> feature/dark-mode (forced update)Line-by-line explanation
- Lines 2 to 3Bring in the latest main by replaying your branch on top of it.
- Line 4Because the branch's commits were rewritten, update the remote copy safely. This is your own branch, so rewriting it is fine.
A hotfix in Git Flow
git switch -c hotfix/1.2.1 v1.2.0
git commit -am "fix: crash on empty basket"
git switch main
git merge --no-ff hotfix/1.2.1
git tag -a v1.2.1 -m "Hotfix release"
git switch develop
git merge --no-ff hotfix/1.2.1Switched to a new branch 'hotfix/1.2.1'
[hotfix/1.2.1 0b1c2d3] fix: crash on empty basket
Switched to branch 'main'
Merge made by the 'ort' strategy.
Switched to branch 'develop'
Merge made by the 'ort' strategy.Line-by-line explanation
- Line 1Start the hotfix from the released tag.
- Lines 3 to 5Merge into main and tag the new release.
- Lines 6 to 7Merge into develop too, so the fix isn't lost in the next release. --no-ff always creates a merge commit, keeping the hotfix visible in history.
Common Git Workflows Mistakes
Long-lived feature branches
# a branch open for six weeks, never updated
git merge feature/redesign # hundreds of conflicts# small branches, merged within days, and main merged in regularly
git merge origin/mainCommitting straight to main on a team
git switch main
git commit -am "quick change"
git pushgit switch -c fix/quick-change
git commit -am "fix: describe the quick change"
git push -u origin fix/quick-changeMeaningless commit messages
git commit -m "update"
git commit -m "asdf"git commit -m "feat: add password strength meter"
git commit -m "fix: stop basket total showing NaN"Git Workflows in Real Projects
Workflows in practice
Most web teams use the feature branch workflow with pull requests and protected main, deploying automatically after each merge. Companies such as Google run trunk-based development at enormous scale with feature flags, while mobile apps and versioned libraries often keep release branches similar to Git Flow. Many teams write their chosen workflow in a CONTRIBUTING.md file so new members know exactly what to do.
Git Workflows FAQ
Which Git workflow should a small team use?
A feature branch workflow with pull requests suits most small teams: short-lived branches, a review for each change and main always working. If you have good automated tests and deploy often, moving towards trunk-based development with very small branches works well. Git Flow is usually more process than a small team needs.
What is GitHub Flow?
It's a lightweight feature branch workflow: create a branch from main, commit, open a pull request, get it reviewed and checked, merge it, and deploy from main. There are no long-lived develop or release branches. Many teams use it without knowing the name.
What are Conventional Commits?
A convention for commit messages that starts each subject with a type, such as feat: add dark mode or fix: handle empty basket. A ! after the type, or a BREAKING CHANGE: footer, marks a change that breaks compatibility. Tools can then generate changelogs and version numbers from the history.
What are feature flags and why do trunk-based teams use them?
A feature flag is a setting in the code that switches a feature on or off without a new deploy. Teams practising trunk-based development merge unfinished features to main behind a flag that stays off, so they can integrate small changes daily without users seeing half-built work.
How often should I update my feature branch from main?
At least daily on an active project, and always before opening or merging a pull request. Merging or rebasing main into your branch often keeps conflicts small and easy to understand. Better still, keep branches short so there's little to catch up on.
Git Workflows Exercises
Answer each one and check it instantly. If you get stuck, open the hint before the answer.
Complete the command that starts a branch for a fix.
git switch fix/login-redirectIn the feature branch workflow, where does new work happen?
What makes trunk-based development different?
Which commit message follows Conventional Commits?
Which project best suits Git Flow?
Git Workflows Quiz
5 questions to check what you learned.
What's the first thing to do before starting a new task?
- Delete old branches
- Force push
- Create a tag
- Switch to main and pull the latest changes
Why keep feature branches short-lived?
- Git deletes old branches automatically
- Branches that drift far from main cause large, painful merges
- Long branches can't be pushed
- Reviews are only allowed on new branches
What do branch protection rules on GitHub do?
- Hide the branch
- Encrypt the branch
- Prevent cloning
- Require things like pull requests, reviews and passing tests before merging into a branch
What is a feature flag?
- A Git tag for features
- A type of commit message
- A setting that switches new code on or off without needing a separate branch
- A branch naming rule
In Git Flow, where must a hotfix be merged?
- Into main (and tagged) and into develop
- Only into main
- Only into develop
- Into every feature branch