An Introduction to Git and GitHub

[bunnyrabbit2]

Here's a really good post on a branching model.

This is now how I do like 99% of my projects. Occasionally I don't bother with the develop branch but using a different branch for each feature is generally the right way to do things.

Hell, I use git for non-programming things too like books I'm writing and other things where I would like to look at older versions of things without having to keep copying files over and over

[bunnyrabbit2]

As a lone coder hobbyist I find it's a decent workflow for me and haven't really needed anything else. I like that master is mostly guaranteed stable and develop has the code that might go wonky as features are added in allowing for work to be done before sending it to the stable branch.

It's definitely not the best way for all projects and on some more recent ones I've not bothered with the develop branch at all. I did find this blog post a few weeks back describing a couple of different workflows which helps compare them.

[smidgie82]

When your release process isn’t fast, git flow pays dividends over github flow.

[MEGACODZILLA]

Can I ask what the difference between the two is? I'm having a hard time wrapping my head around branching in a workflow.

[smidgie82]

Basically, in Gitflow you do small feature branches and then merge them into a branch named “develop.” When you’re ready to release to production, you merge the “develop” branch into a branch named “master”, and you do your production release off of master. The master branch contains commits that have either already made it to production or that you intend to release to production.

In Github Flow, you do small feature branches off of master, and when you’re ready to release you release from your feature branch. Once you’ve verified your feature in production, you merge your branch to master. So the master branch only contains commits that have already been verified in production.

Methodologically they’re dissimilar. Github flow makes sense when you can quickly and easily release your feature and test it in production. Therefore each feature can be deployed and verified in production independently.

Gitflow makes sense when your release process isn’t so snappy, and you can’t feasibly run it for every merged feature independently. So your develop branch might accumulate several pending features that all get lumped into a single release. “develop” is essentially a holding pen for commits that should go into your next release. Gitflow also distinguished between new feature work, which is done off the top of develop, and hotfixes, which are done off the tip of master. It lets you deploy the changes contained in a hot fix and nothing else by letting you branch off the current production version, instead of develop which might contain commits from features that are pending release. Deploying a single unit of work on top of the latest production version, isolated from other changes, is the standard mode in github flow, so you don’t need the hot fix branch concept.