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?
4
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
masterand pushes changes toorigin/masterdirectly 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
masteror from another feature branch. Eventually everything gets merged back tomaster. -
Gitflow (Source): Two main branches track a project history,
developandmaster. Another 3 branches calledhotfix,releaseandfeaturehold changes made directly tomasterfor 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
featurebranch off ofmaster. Changes are pushed via pull request. Changes accepted intomasterget 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.
7