When working in collaboration with other people we use hosting services like GitHub to host a centralized version of the repository. There are two possible workflows that we can use: Centralized Workflow or Integration-Manager Workflow.
In the Centralized Workflow, all collaborators have push authorization and can thus write changes to the central repository. They all start by cloning the central repository to get a local copy of it on their machines. To keep their copy up-to-date with what's on the central repository, they use the pull command. To send their local changes to the central repository they use the push command.
In the Integration-Manager Workflow, only some people (known as Maintainers) have push access to the central repository. In order to contribute to these projects, Contributors need to first fork the central repository. This creates a copy of the central repository on GitHub to which they have push access. Then they must clone this forked repository to get a local copy on their machines. Once they are done with their proposed changes, they push them into their forked copy of the centralized repository, and from it, send a pull request to the Maintainer of the original centralized repository. Maintainers then review the changes and decide whether they want to pull the changes into the repository or not.
The Centralized Workflow is the workflow we commonly use for projects with people we know. The Integration-Manager Workflow is the one commonly used for open-source projects where anyone can contribute.
Many companies use a hybrid workflow. In this workflow, there are two roles: the team manager and the contributors, and the repository is organized in at least three branches. The master branch is where the production code lives. The team manager is in charge of maintaining this branch and of merging Pull Requests. Other team members work on the staging and feature branches. When someone needs to start working on a new feature, they start by creating a new branch from the staging branch. Once they are done working, they send a pull request from the feature branch to the staging. Another team member must approve it before it can be merged on to the staging branch.
There's usually a server that runs the code in the staging branch called a staging server. Once code reaches this branch (and thus this server) it is presented to clients and/or stakeholders for approval. If approved, the team manager merges the staging branch into the master branch and creates a new release tag. Code that makes it to the master branch is run on the production server and makes up the application or program that can be accessed by the final users.
