Simpler git-flow model, am I doing it right?

Question

I'm trying to implement a branching model that is similar to git-flow, but simpler (no release or hotfix branches).

The idea is to have the master branch always up to date with the latest tagged release, a develop branch that runs parallel to it, and feature branches to implement longer (more than 1-2 commits) features.

develop branches from master and back into it, while the feature branches do the same in the develop branch.

This is my branching model:

# 1. While in master, create develop branch, and track it.
# This branch is created once here.
git checkout -b develop
git push --set-upstream origin develop
# 2. Do some minor work and push to develop
git add <file>
git commit -m 'did work'
git push
# 3. To work on a feature, create a branch from develop, and track it
git checkout -b feat/issue9
git push --set-upstream origin feat/issue9
# 4. After work on feature is finished, merge into develop
git checkout develop
git merge --no-ff feat/issue9
# Delete remote and local branches
git push origin --delete feat/issue9
git branch -d feat/issue9
git push
# 5. Once a new release is ready, bump version
git add __version__
git commit -m 'Bumped version number to 0.1'
# 6. Add tag
git tag -a v0.1
git push --tags
# 7. Merge develop into master, and push changes
git checkout master
git merge --no-ff develop
git push

Up to this point, the branches look like this:

enter image description here

This is almost what I want, except that develop is behind master by two commits (the bumping of __version__ file, and the merging of develop into master)

So I try to bring develop up to where master is:

# 8. Merge master into develop
git co develop
git merge master
git push

which results in this:

enter image description here

Once this point is reached, I start again from 2. Do some minor work and push to develop. A second cycle looks then like this:

enter image description here

Is this a sensible model to be following? Can it give me problems in the future? Any tips to improve it?

• Cort Ammon: I think there are a remarkable number of sensible models, especially when you tailor them to your work flow. However, I find the wording on this one wondefully clear. I think it's nothing but an extension of yours to handle a few cases you may not have had to deal with yet.

Answer 1

I would consider not having the develop branch but using a staging server for that environment.

Yes work in branches of course but merge them into master in groups and tag the group with a version.

Then choose when to deploy what version to staging and production servers.

This is the feature branch workflow which works well for Pull Requests and is the basic workflow I have seen in the last 3 companies I've worked in.

The workflow you described in your question is the gitflow workflow which has the develop branch and can be more suitable to larger organizations that have more contributors and more defined and/or more formal release processes.

There's also the forking workflow for distributed and open source communities. You see this used with a lot of the open source gems