Closed ebuchman closed 5 years ago
Im inclined to say that "Use Master and a branch for each Release Series" seems like the more sensible path. I've noticed other well maintained large open source repositories do this as well. Regarding on how to "get fixes back to master", it seems that opening a PR of the original fix branch against master would make sense. We don't get the version/changelog updates here, but how much headache would that cause to do manually?
support "previous", "current", and "next" releases of the software (ie. backports and some semblance of stability on the main branch/es)
good point!
sounds like Just Use Master
option is excluded from this. GitWorkFlow seems pretty confusing - from the provided description, I'm still a bit unclear on the use of pu
branch 💩 .
I'm confused on GitWorkFlow as well. I think we want something easy to understand, so new contributors can join.
I personally like master + develop. I wouldn't be opposed to merging CLI/UX changes and hot fixes directly to master though.
i think a good flow is fairly well established. re-open if conversation needs to be continue
Git Workflow
How should we co-ordinate changes to our software?
Let's write some requirements and see the pros and cons of different branching/release models.
Requirements
Just Use Master
Pros
Cons
Use Master and a branch for each Release Series
release-0.x
branch for each minor versionx
release-0.x
branchrelease/0.x.y
based onrelease-0.x
release-0.x
Pros
Cons
release-0.x
branch requires github protectionUse Master and Develop
Pros
Cons
Use GitWorkFlow
This is the workflow used by git.git itself. It has 4 branches:
Here, pu branch is constantly thrown away and reset. Only topic branches are ever merged directly back to master.
Pros
Cons