GitWorkflows

GitWorkflows refer to the conventions teams use to manage changes in a Git repository. A workflow defines how branches are created and used, how changes are proposed and reviewed, and how and when code is integrated and released. Core concepts include branches, commits, merges, pull requests, and continuous integration.

- Centralized workflow: A single main integration branch is used, and developers push to a shared repository. This model is simple for small teams but can become a bottleneck as changes accumulate.

- Feature branch workflow: Each feature or bug fix is developed in its own branch off the main branch. Changes are merged back via pull requests after review and testing.

- Git Flow: A structured model with long-running branches such as main, develop, feature/*, release/*, and hotfix/*. It supports planned releases and multiple QA stages, but adds process overhead.

- GitHub Flow: A lightweight variant where main is deployable at all times. Developers create short-lived branches and open pull requests for review, then merge after checks pass.

- Forking workflow: Common in open source. Contributors fork the repository, push changes to their own fork, and submit a pull request to the original repository. Maintainers review and merge.

- Trunk-based development: Developers integrate frequently into a single trunk (often main) with very short-lived or no feature branches, complemented by feature flags to keep incomplete work out of production.

Choosing a workflow depends on team size, release cadence, code ownership, and tooling. Larger teams with formal release schedules may favor Git Flow; open source projects often use forking workflows; teams pursuing continuous delivery may prefer trunk-based or GitHub Flow.