Ruby on Rails Development and Consulting

1
Ruby on Rails

• Git Work Flow For Ruby on Rails Developers

2

• This is my very first blog post and so I though
  it should be about a tool that is indispensable
  for me Git. I started using git about 10 months
  ago and looking back I cant imagine how I
  managed to get work done without it. The purpose
  of this post however is not to sing gits
  praises, there are lots of good articles on the
  web that do so much better than I ever could.
  Instead, I wish to share the work-flow I use on
  my projects. I developed this work-flow by trial
  and error over the months and is currently the
  most efficient and productive approach I can
  think of. If any experienced git users happen to
  stumble upon this post, please do provide
  suggestions/alternatives to help me improve my
  process.

3

• The project I am currently working on requires me
  to maintain two parallel deployment branches. One
  is a production branch which is deployed on the
  live server and the other is a development
  branch which is deployed on a staging server.
  All enhancements and feature additions are done
  in the development branch and the only changes
  made in the production branch are production
  bug fixes that need urgent attention. Once the
  development branch is deemed stable it is
  merged into production branch and deployed.

4

• Ive divided my work-flow into two parts. The
  first part is a generic approach which I follow
  in all projects, the second part is specific to
  the case mentioned above and discusses how I
  manage the two branches using git. Although I
  mention Rails in the title of this post, the
  work-flow I define below is not Rails specific
  and can be applied to any project where multiple
  deployment branches need to be maintained. I
  assume the reader has a basic understanding of
  git and is comfortable with git branches. There
  are lots of configuration settings in git which
  help you setup things like you git author name,
  email and colors for git commands etc.

5
There are two I would like to mention here though

• git config --global push.default
  quottrackingquot
• This command tells git to perform a push only to
  the tracked remote branch in which you are
  currently working.
• git config --global pack.threads quot0quot
• This command tells git to auto-detect the number
  of threads to use for packing repositories and is
  useful when working on a machine with more than
  one core.

6
1. Generic Workflow

• a. Start with a clean master branch.
• git checkout master
• git pull
• You now have a clean master branch. Never work
  directly in the master branch, instead make all
  changes to a local branch.

7

• b. Create a local branch.
• git branch my_local_branch
• git checkout my_local_branch
• or do both in one command
• git checkout -b my_local_branch

8

• This creates a new local branch named
  my_local_branch and switches to it. You can now
  perform all changes in this branch. One good
  practice to follow when using git is to commit
  often and in small chunks. This gives you finer
  control on the work done and allows you to fix
  mistakes without losing other work. Once you are
  satisfied, all those smaller commits can be
  consolidated in a single meaningful commit.

9

• c. Merge with master branch.
• git checkout mastergit pull
• if new changes were pulled do the following
• git checkout my_local_branchgit rebase master

10

• A rebase will apply the newly pulled changes in
  the master branch to your local branch and then
  apply local branch changes on top of that. This
  will ensure a clean merge with master. Conflicts
  are very common during a rebase and will need to
  be resolved before you can have a successful
  rebase. You can also pass the -i option to
  rebase to perform an interactive rebase which
  will alllow you to squash multiple commits into
  one if you so require. Once you are finished with
  the rebase do the following

11

• git checkout master
• git merge my_local_branch
• git push
• Once you are satisfied with the push you can
  delete the local branch
• git branch -d my_local_branch

12
2. Managing Multiple Deployment Branches

• The master branch is set as the branch for
  production deployment and a new remote branch is
  created for development phase. Since I use
  capistrano for project deployment I set it up to
  have three separate tasks production,
  production_staging and development_staging.
  The production and production_staging tasks
  use the master branch and the development_staging
  task uses the newly created remote branch. For
  both the remote branches you must follow the
  above work-flow i.e never work directly in the
  branches themselves, instead create local
  branches to work in.

13

• a. Create a new remote branch.
• First create a new remote branch from our master
  branch
• git push origin masterrefs/heads/development_phas
  e_1
• b. Track the remote branch.
• Track the newly created remote branch
• git checkout --track -b development_phase_1
  origin/development_phase_1

14

• This will create a new local branch named
  development_phase_1 that is tracking the remote
  development_phase_1 branch. Everyone who needs
  to work on development branch tracks this remote
  development_phase_1 branch and pushes to it.
  The only pushes to master branch are production
  fixes.

15

• c. Merge the development branch with the master
  branch.Once work on development branch is
  finished we are ready to merge the two
  branchesgit checkout development_phase_1git
  rebase mastergit checkout mastergit merge
  development_phase_1git pushgit branch -d
  development_phase_1git push origin
  heads/development_phase_1

16

• Normally a rebase is not a good idea in a
  remotely tracked branch but since our phase is
  finished and we will create a new remote branch
  for the next phase, I do so here. Alternatively,
  I could do a force push for the remote
  development branch and everyone working on it
  would need to remove and retrack it again. The
  second last line removes our locally tracked
  development branch and the last one removes it
  from the remote repository.

17
Final Thoughts

• As I mentioned before, the above presented
  work-flow is not perfect by any means but it
  works for me. I would appreciate feedback from
  anyone who reads this and has some
  suggestions/recommendations to help me manage my
  projects better.
• Source http//vinsol.com/blog/2009/07/24/git-wor
  k-flow-for-rails-developers/