To me the gitflow concept boils down to a way of tydying up the historical mess that piles up over the years. The branch feature/RollingFileAppender-NG dates actually back to 2012. I'd be happy already if we had a naming convention for the different branch types. From the branch name alone it is at the moment totally unclear what i.e. the log4net-1.3 branch is actually about. It is written down only somewhere in the mailing list archives that we have abandoned it.
What do you think about a simple prefix scheme for named branches like abandoned/x, feature/y, pullrequest/z,..? These are the three kinds of branches I see at the moment. On 21 May 2017 6:11 a.m., "Stefan Bodewig" <[email protected]> wrote: > On 2017-05-19, Dominik Psenner wrote: > > > would we like to use gitflow for our named branches? [1] > > I've used gitflow in one or two projects at work and we've never really > come to a situation where having the release branch really helped. Maybe > because we didn't create bug fix releases on a regular basis and > creating a branch off the tag when you needed one was not a big burden. > > I do like feature branches for changes you work a bit longer on or bug > fixes you feel may require a hotfix. > > I've never really grasped what the tag-only master is good for, tags are > kept alive in git anyway, you don't need a branch for them. > > That being said, I'm not against using gitflow I'm just not convinced of > the benefits it claims to offer. > > Stefan >
