Web Technology Development Basic Workshop

Git Flow for a Team Project

A practical workflow based on Atlassian Gitflow: protect production, integrate through dev, and use pull requests for review.

Productionmain
Integrationdev
Workfeature/*
Urgent fixhotfix/*
MODEL

Keep two long-lived branches

Git workflow illustration from Atlassian
Workflow illustration from Atlassian's Gitflow guide.
BranchPurposeRule
mainReleased, production-ready code.Merge only a tested release or urgent hotfix; tag each package.
devShared integration branch for the next release.Feature pull requests target this branch.

Never commit directly to main or dev. Require a pull request, review, and passing checks.

FEATURE

Build one change in a feature branch

git switch dev
git pull origin dev
git switch -c feature/TODO-123-add-priority
git push -u origin feature/TODO-123-add-priority

Open a PR from the feature branch into dev. Put the Jira issue key in the branch and PR title, link the Confluence design or acceptance criteria, request review, and delete the branch after merge.

Git Flow branches showing Main, Release, Develop, and Feature branches
Release branch example: promote the tested release to main and publish the tagged package.
RELEASE

Release a package through main

  1. Create release/1.2.0 from dev.
  2. Allow only version bump, release notes, final tests, and small fixes.
  3. Approve a PR from the release branch to main.
  4. Tag the merge commit: git tag v1.2.0, then publish the package from main.
  5. Merge the release branch back into dev.
Build and publish artifacts only from the tagged main commit. The tag answers “what code is in this package?”
HOTFIX

Fix production without waiting for dev

git switch main
git pull origin main
git switch -c hotfix/1.2.1-login-timeout

Start a hotfix from main, not dev. Test the minimal correction, open a PR to main, bump and tag the patch version, publish from main, then merge the hotfix back into dev.

BEST PRACTICES

Use Jira and Confluence as the shared record

  • One branch and PR should solve one Jira issue.
  • Write the decision and API contract in Confluence; link it from the PR.
  • Use clear names: feature/, release/, and hotfix/.
  • Keep PRs small, reviewed, and protected by automated checks.
  • Do not rewrite shared branch history or force-push protected branches.

Source: Atlassian Gitflow Workflow.