I’m trying to come up with a personal workflow. I’ve put together a flowchart of the hypothetical lifespan of a release: one developer pushing to a public github repo + a friend helping with some feature and fixing a bug.
Is this a reasonable approach to version control?
The main idea is to keep the public repo tidy:
-
Each new release gets on its own branch until it’s finally tagged in the master branch when it’s finished.
-
All work is done on “feature” or “hotfix” branches, never on an actual release branch, to prevent anomalies.
-
Merges to higher-level branches are always rebased or squashed (to avoid clutter).
If it’s overkill I don’t mind because the whole point is for me is to learn skills I might need for a larger project. The only problem would be if I’m doing something flat out wrong or unnecessary.
edit 2: fixed bad idea in the original flowchart and made it a bit easier to navigate.
4
What I see a lot in the git/github community is this
branches
master
develop
You and contributors work primarily in develop, but someone may have an idea or new feature, so you create a topic branch like git checkout -b user_comments.
Then as you progress through the development you push to master once you git a version you are happy with and tag that in the master branch as 1.0 or 1.1.2 etc ( look up semantic versioning )
1