Centralized, integration-manager, and dictator workflows

Because Git is distributed, every developer is potentially both a node and a hub, able to contribute code to other repositories and to maintain a public repository that others base work on, which supports several standard workflows. In the centralized workflow, one hub repository accepts code and every developer synchronizes with it: the first developer to push succeeds, and others must fetch and merge before pushing, because Git rejects non-fast-forward pushes rather than letting users overwrite each other. This model works as well in Git as in centralized systems such as Subversion, and with Git's branching it can scale to hundreds of developers on dozens of simultaneous branches. The integration-manager workflow gives each developer write access to their own public repository and read access to everyone else's: a contributor pushes to their public clone and asks the maintainer to pull, and the maintainer adds that repository as a remote, merges locally, and pushes to the canonical repository — a pattern common on hub-based tools like GitHub and GitLab. Huge projects with hundreds of collaborators, such as the Linux kernel, use the dictator-and-lieutenants variant. Scope: Git. Reviewed October 4, 2026.