Pull Requests and Team Workflow

GitHub Flow

Most teams use a simple flow:

1. Create a branch from up-to-date main: git switch -c feature/search.
2. Commit small, focused changes; push the branch: git push -u origin feature/search.
3. Open a pull request (GitHub, Bitbucket) or merge request (GitLab): describe what and why, link the ticket, add screenshots for UI changes.
4. Automated checks (tests, linting) run; teammates review and comment.
5. Address feedback with more commits, then merge (often "squash and merge") and delete the branch.
6. main deploys automatically or on release.

Keep branches short-lived (days, not weeks) to avoid painful conflicts. Protect main so changes only arrive through reviewed pull requests.

Commit message conventions

Many teams use Conventional Commits: feat: add search box, fix: handle empty cart, docs:, refactor:, chore:. Tools can then generate changelogs and version numbers automatically.

Tags and releases

A tag marks a release: git tag -a v1.2.0 -m "Release 1.2.0", then git push origin v1.2.0. Semantic versioning: MAJOR.MINOR.PATCH (breaking, feature, fix).

git init -b main --quiet app && cd app
git commit --allow-empty -m "chore: initial commit" --quiet
git tag -a v1.0.0 -m "First release"

for msg in "feat: add search box" "fix: handle empty search" "docs: explain search syntax" "feat: search suggestions"; do
  git commit --allow-empty -m "$msg" --quiet
done
git tag -a v1.1.0 -m "Search release"

echo "--- changes in v1.1.0, grouped by type:"
git log --format="%s" v1.0.0..v1.1.0 | sort | awk -F: '{ print "  [" $1 "]" $2 }'
echo "--- tags:"
git tag -n1
echo "--- latest release: $(git describe --tags --abbrev=0)"

--- changes in v1.1.0, grouped by type:
  [docs] explain search syntax
  [feat] add search box
  [feat] search suggestions
  [fix] handle empty search
--- tags:
v1.0.0          First release
v1.1.0          Search release
--- latest release: v1.1.0