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 developgit push --set-upstream origin develop# 2. Do some minor work and push to developgit add <file>git commit -m 'did work'git push# 3. To work on a feature, create a branch from develop, and track itgit checkout -b feat/issue9git push --set-upstream origin feat/issue9# 4. After work on feature is finished, merge into developgit checkout developgit merge --no-ff feat/issue9# Delete remote and local branchesgit push origin --delete feat/issue9git branch -d feat/issue9git push# 5. Once a new release is ready, bump versiongit add __version__git commit -m 'Bumped version number to 0.1'# 6. Add taggit tag -a v0.1git push --tags# 7. Merge develop into master, and push changesgit checkout mastergit merge --no-ff developgit pushUp to this point, the branches look like this: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 developgit co developgit merge mastergit pushwhich results in this: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:Is this a sensible model to be following? Can it give me problems in the future? Any tips to improve it?
Simpler git-flow model, am I doing it right?
git;github;branching;gitflow
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