The Centralized Workflow is similar to a workflow used in Subversion and the easiest workflow to implement if you’re transitioning from Subversion to Git.
Here are the main tenants behind the Centralized Workflow:
- Uses a centralized repository that is the master record of the repository. It should be considered the sacred history of the project.
- There’s no branching model because all commits are done right in the
Because the developers work right from the
master branch it mimics the trunk setup that is sometimes typical in Subversion.
Here’s the workflow step-by-step (from the perspective of a single developer):
- Clone the
masterbranch of remote repository.
git clone https://someurl.com/somerepo.gitNow the developer has a local copy of the project on her own computer. She makes her code changes and additions.
- Commit any changes to the local repository. The commits are local only until the next step. The developer can choose to move to Step 3 when she is at a natural stopping point or the changes she has made are stable and ready to be shared with others.
git commit -a -m "a commit message"
- Push changes (a set of commits) to the central repository. This is done using
git push origin(where
originis the short name for the remote repository). Now the changes the developer made locally are integrated with the central repository. This is similar to
svn commitin that it moves changes from local to remote.
- Resolve a conflict. Sometimes the changes that the developer made locally and pushed to the central repository conflict with the changes in the central repository. In this case, the developer will be presented with a Merge Conflict. This prevents the developer from overriding changes to the remote repository. The first step to resolving the conflict is the pull down the latest changes from the central repository. This is done using
git pull --rebase origin master. The
rebaseoption tells Git to move all of the commits from the developer to the tip of the
masterbranch by recreating each commit one at time. Now her changes come after the other changes that are creating the conflict. You do this so you don’t have to create a merge commit.
- Resolve a conflict, Part 2 Because she used
git pull --rebase, Git will step through each commit and check for merge conflicts. The developer can use
git add <some file>to add her changes in to resolve the conflict (for as many files in which there are conflicts) and then continue the rebase process using
git rebase --continue. This will then check the next commit for conflicts until all commits are checked.
- Push changes to central repository Now that the merge conflict process is complete, the developer can push her changes back to the central repository using
git push origin master. Now her work is successfully integrated in the repository.
The advantage of the Centralized Workflow is that there is only a small shift in how to think about your code and the repository. The commands you run will be different but the team does not have to learn a completely new way and approach to using version control.
The drawback to this workflow is that your
master branch is always at risk of being broken by code changes. The next two workflows will address that.