Fork me on GitHub

Joslyn Esser

Git workflow for small teams

A finely tuned git workflow can save you an enormous amount of time over the long run. Over time, I have improved my development process by trying out multiple different strategies. I wanted to share the process I’m currently using that has proven to be successful in a small team environment.

I choose to keep things as simple as possible and use the story branch pattern. All development gets worked on in a local feature branch and pushed to a single remote development branch. Releases are tagged and deployed to production from the master branch. The general workflow for a feature involves the following:

  1. Create a new branch off of development named after the feature.
  2. Work on my feature, continuously committing at regular intervals to keep track of what I’ve done.
  3. Keep my local feature branch up to date from any upstream changes my team has made. This needs to happen often to stay fresh.
  4. Once finished, wrap all of my tiny commits into a single, pretty commit.
  5. Merge local feature branch into development and push it up for the rest of the team.
  6. Delete the feature branch, as it is no longer needed.

If you perform all of those steps manually, it can get quite cumbersome over time and you may find yourself or your team taking shortcuts and not sticking to the process. Fortunately, a lot of this can be automated if you are consistent.

Set up your remote branch

Create a remote development branch from your master branch and track it locally. This is what the team will collaborate on:

git push origin master:refs/heads/development
git checkout --track origin/development

Get to it!

  1. Start working on a new feature

     git checkout -b my_cool_feature
  2. Make some changes

     touch part1.txt && git add part1.txt
     git commit -m "Adding first part of new feature"
     touch part2.txt && git add part2.txt
     git commit -m "Adding second part"
  3. Make sure you are up to date with the latest from the remote development branch. Roll your local changes on top of them:

     git checkout development
     git pull
     git checkout my_cool_feature
     git rebase development
  4. Wrap up all of your local commits you’ve made into one commit by performing an interactive rebase:

     git rebase -i development
  5. When your editor opens, combine all commits into one by squashing every commit into the first:

     pick ae3a3dc Adding first part of new feature
     squash 3c82ad8 Adding second part
  6. Now pretty up your single commit message :

     [#123456] My Cool New Feature
       * Adding first part
       * Adding second part
  7. Merge your feature into development, push it up for your team, and delete your local branch

     git checkout development
     git merge my_cool_feature
     git push origin development
     git branch -d my_cool_feature
  8. Repeat for every other feature


Once all features for a release are ready to be shipped out, perform the following:

  1. Merge development into master

     git checkout master
     git merge development
  2. Tag the release (I version my projects using the major.minor.patch versioning)

     git tag 1.0.0
  3. Push up your changes

     git push
     git push --tags

Find a bug?

What happens if a bug is found in production? My general process for handling this involves the following:

  1. Make the fix directly on master
  2. Tag it as a patch release
  3. Push up the change
  4. Merge the change into development


  1. fight night round 4 — January 22, 2011

    I love it! Could perhaps be a tad more polished, but it’s far better than what we use at the moment, nonetheless

  2. rock and roll hall of fame — January 22, 2011

    Thank you for taking the time to make that clearer.

  3. tagged home — January 22, 2011

    Well … all I can say is, wow. This is an impressive collection of resources, thank you for taking the time to put everything together.

  4. Bryan Helmig — May 27, 2011

    One thing I ran into was in step 3, the pull request needed the branch and repository explicitly listed (or else you could set it in the config I understand).

  5. Guias privadas en Rusia — June 04, 2011

    Te creo, junto con el dinero de varios gazillion de inversión que wikipedia podría adquirir algunos servidores mucho más.

  6. Clen — June 22, 2011

    Certainly one of many challenges which people starting a brand new on-line firm face is that of obtaining visitors to their internet site.

  7. miluch — October 17, 2011

    In p 4 it seems it should be
    git rebase -i my_cool_branch
    instead of git rebase -i development

  8. winstrol — November 20, 2011

    you can always count on toshiba laptops when it comes to durability, they are really built tough,

  9. Piotr — January 02, 2012

    instead of `git rebase -i` why not `git merge —squash` ?

  10. amarmpynclalp — January 13, 2012

     Hvis Vil du at et flertall av HIV-positive filippinere synes å være tilstrekkelig beskyttet, hun eller han oppfordret vår Institutt med hensyn til Helse pluss Insurance Commission for å virkelig finne competeing hvorvidt forsikringsselskapene ha vært konstituert på bare henhold hjelp Republic Act 8504 på den andre siden vår AIDS Prevention og / eller Kontroll Law.

    "For forskere, denne skala gir en bestemt rask kategorisering innen planetens relevans når du trenger å biologi, vises i noen samme måte nettopp det stellar typer umiddelbart kan fortelle en astronom noe om en persons størrelse , temperatur, samt en lysstyrke deres stjerne "

    Det er umulig definitivt ikke til varsel anbefalinger om hvordan god ditt firma hund på den andre siden katten føler når du gnir under sine haken eller kanskje klø bak ørene. Vanligvis komfort om hengivenhet enn konstant berøring og samt kjærtegn bidrar til over alle lykke deretter med mindre du er glad du ikke kan din være sunn, kan du?