Centralized Workflow

The Cen­tral­ized Work­flow is sim­i­lar to a work­flow used in Sub­ver­sion and the eas­i­est work­flow to imple­ment if you’re tran­si­tion­ing from Sub­ver­sion to Git.

Here are the main ten­ants behind the Cen­tral­ized Workflow:

  • Uses a cen­tral­ized repos­i­to­ry that is the mas­ter record of the repos­i­to­ry. It should be con­sid­ered the sacred his­to­ry of the project.
  • There’s no branch­ing mod­el because all com­mits are done right in the master branch.

Because the devel­op­ers work right from the master branch it mim­ics the trunk set­up that is some­times typ­i­cal in Subversion. 

Step-by-Step #

Here’s the work­flow step-by-step (from the per­spec­tive of a sin­gle developer):

  1. Clone the master branch of remote repos­i­to­ry. git clone https://someurl.com/somerepo.git Now the devel­op­er has a local copy of the project on her own com­put­er. She makes her code changes and additions.
  2. Com­mit any changes to the local repos­i­to­ry. The com­mits are local only until the next step. The devel­op­er can choose to move to Step 3 when she is at a nat­ur­al stop­ping point or the changes she has made are sta­ble and ready to be shared with oth­ers. git commit -a -m "a commit message"
  3. Push changes (a set of com­mits) to the cen­tral repos­i­to­ry. This is done using git push origin (where origin is the short name for the remote repos­i­to­ry). Now the changes the devel­op­er made local­ly are inte­grat­ed with the cen­tral repos­i­to­ry. This is sim­i­lar to svn commit in that it moves changes from local to remote.
  4. Resolve a con­flict. Some­times the changes that the devel­op­er made local­ly and pushed to the cen­tral repos­i­to­ry con­flict with the changes in the cen­tral repos­i­to­ry. In this case, the devel­op­er will be pre­sent­ed with a Merge Con­flict. This pre­vents the devel­op­er from over­rid­ing changes to the remote repos­i­to­ry. The first step to resolv­ing the con­flict is the pull down the lat­est changes from the cen­tral repos­i­to­ry. This is done using git pull --rebase origin master. The rebase option tells Git to move all of the com­mits from the devel­op­er to the tip of the master branch by recre­at­ing each com­mit one at time. Now her changes come after the oth­er changes that are cre­at­ing the con­flict. You do this so you don’t have to cre­ate a merge commit.
  5. Resolve a con­flict, Part 2 Because she used git pull --rebase, Git will step through each com­mit and check for merge con­flicts. The devel­op­er can use git add <some file> to add her changes in to resolve the con­flict (for as many files in which there are con­flicts) and then con­tin­ue the rebase process using git rebase --continue. This will then check the next com­mit for con­flicts until all com­mits are checked.
  6. Push changes to cen­tral repos­i­to­ry Now that the merge con­flict process is com­plete, the devel­op­er can push her changes back to the cen­tral repos­i­to­ry using git push origin master. Now her work is suc­cess­ful­ly inte­grat­ed in the repository.

The advan­tage of the Cen­tral­ized Work­flow is that there is only a small shift in how to think about your code and the repos­i­to­ry. The com­mands you run will be dif­fer­ent but the team does not have to learn a com­plete­ly new way and approach to using ver­sion control.

The draw­back to this work­flow is that your master branch is always at risk of being bro­ken by code changes. The next two work­flows will address that.