Git workflows are team conventions for organizing branches and commits. Common patterns include trunk-based development (commit to main frequently, keep it stable), feature branches (one branch per feature, merge when done), or gitflow (main for releases, develop for integration, feature branches for work). Choose based on team size, release frequency, and how much isolation you need.
Trunk-based development keeps the main branch clean and releasable—every commit to main is a potential release. Teams doing continuous deployment often use this. Feature branches isolate work and allow code review before merging; teams with slower release cycles often prefer this. Gitflow adds explicit develop and release branches, useful for managing multiple versions in parallel, though it can become complex for small teams.
$ git checkout -b feature/login # create a feature branch $ git add ... $ git commit -m "..." # work on the branch $ git push -u origin feature/login # push for code review $ # ... review and merge via pull request $ git checkout main $ git merge feature/login # merge after review
The key principle is consistency: pick a workflow, document it for your team, and stick to it. A messy workflow causes confusion and makes history hard to follow. If you are working alone, trunk-based development or simple feature branches work well. If you are in a team, agree on how branches are named, who reviews before merge, and how to handle hotfixes to released versions.