12

Long ago the small team of web developer I work with started using git for web development. Back then we just committed to staging or master directly and then merged frequently between the two. It was better than nothing, but it was also a mess.

Not too long ago we adopted the gitflow work flow. While it's certainly better than the chaos that came before it seems somewhat cumbersome and excessively release/milestone oriented. My fellow devs are frequently ask me to clarify how it's supposed to work and what should merge and shouldn't. In general it seems ill suited for web development work where we're deploying code frequently and without tracking specific milestones for release.

On a friends recent suggestion I've begun looking at GitHub Flow. Reading Scott Chacon's post here hits the pain point perfectly with this:

So, why don’t we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the “release”. We don’t really have “releases” because we deploy to production every day – often several times a day.

FWIW, I've also looked at this nice round up of workflows on Atlassian's site: https://www.atlassian.com/git/workflows#!workflow-feature-branch

However they ALL look like poor choices for web development in a small team and again geared towards major application releases not frequent/daily releases.

The is a question over on SE asking to compare git-flow to github-flow https://stackoverflow.com/questions/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github-flow

That's a good answer in general, but as I mentioned in my comment below meta.programmers.SE seems to indicate that questions about general best workflow practices belong here and I was hoping for a broader list of possible answers than just git-flow and github-flow, while being specific to web development. Hence I think it warrants a new question here.

With that, what do you find is the best/prefered git based workflow for a small web development team working on projects with fairly continuous deployment? Is it github-flow or something else?

  • BTW, I'm putting this question here on Programmers.SE based on this: meta.programmers.stackexchange.com/posts/6312/revisions – jb510 Aug 15 '14 at 2:40
  • Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask – gnat Aug 15 '14 at 6:50
  • @gnat I'm not sure what more I could share in that regard? gitflow being so release oriented is cumbersome. GitHub-Flow purports to be good for daily deploying, but having dozens of branches waiting to be merged in also looks like chaos. Was hoping someone would answer with "X is great for web dev because Y". It's well covered in the link I provided, I guess I could excerpt quotes from it? – jb510 Aug 15 '14 at 7:27
  • 1
    @gnat - I completely rewrote the question to show more research and be very specific about the answer I'm looking for. – jb510 Aug 15 '14 at 8:10
7

First I'd like to make a little summary of the different workflows that you've looked into and you think are not suitable for the kind of development you're working on:

  • Centralized (Source): Pretty much like SVN workflow but now on a distributed environment. Every developer works on a personal copy of master and pushes changes to origin/master directly or via pull request.

  • Feature branch (Source): Well, that. Every developer working on a particular feature should work on a specific branch dedicated to that feature only. This feature branch should be created from master or from another feature branch. Eventually everything gets merged back to master.

  • Gitflow (Source): Two main branches track a project history, develop and master. Another 3 branches called hotfix, release and feature hold changes made directly to master for fixing critical production bugs, change version number and other details prior to a release or work on a particular feature just like Feature branch, respectively.

  • GitHub flow (Source): Developers create a feature branch off of master. Changes are pushed via pull request. Changes accepted into master get deployed immediately by GitHub bot Hubot.

For the development part of your question, the answer depends on the background of your team. Do they come from an SVN environment? Then you should go with the centralized approach since it's the one that resembles SVN most. Do they feel comfortable working with Git? Then perhaps you shouldn't try to adapt your team's workflow to any of those but implement your own, crafted to suit your needs which if I understood well are development flexibility and fast deployment.

I also think you should focus on improving the latter. How is your deployment pipeline composed of? In "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" the authors identify possible causes for infrequent deployments, some of which are:

  • The deployment process is not automated.
  • Testing takes a long time.
  • People don't understand the build/test/deploy process.
  • Developers are not being disciplined about keeping the application working by making small, incremental changes, and so frequently break existing functionality

Do any of those sound like something you could improve? Perhaps you could tell us a little bit more about how you and your team handle this part of the project.

  • 2
    +1, the key to cd isn't git or your gitflow but CI and delivery workflow. – Wyatt Barnett Aug 15 '14 at 12:51
  • Thinking a LOT about this. Thanks for the insight. FWIW, I specifically avoiding using the term CI because we don't use CI. Maybe we should, but we don't, it's just too cumbersome for the dozens of projects we work on in a given week, some short term, some long term. – jb510 Aug 15 '14 at 21:53
  • 2
    @jb510 -- we've got a similar project setup, I would not dream of flying it without CI. Switching contexts is alot easier when all the dumb but fragile parts are scripted. – Wyatt Barnett Aug 22 '14 at 17:56
  • 1
    Sometimes, inability to implement CI easily is a sign of how much you need CI on a project. No unit tests? Deployment all manual? Lots of fiddly deploy steps? Needs examination. – Kzqai Aug 10 '15 at 15:14
  • 1
    I've followed this question and answer over the years. I'd hoped others would offer answers as well, but this is itself a great answer so finally marking it accepted (probably should have done that a long time ago) – jb510 May 23 '17 at 3:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.