Add branching suggestions to version control best practices

[dazza-codes]

See http://datasift.github.io/gitflow/IntroducingGitFlow.html http://datasift.github.io/gitflow/GitFlowForGitHub.html

Key points:

• enhancements are in feature branches (off the develop branch)
  • push/pull feature branches with a github origin
• github pull requests merge a feature branch into the develop branch
  • don't accept your own pull requests (unless you have to)
• the develop branch is deployed to -dev systems (continuously)
  • feature branches may be broken, but develop should be passing unit tests (at least)
• the release branch is deployed to -stage systems for integration testing
  • release branch is named with a release version
  • any -stage bug fixes are in bug-fix branches off the release branch
  • bug-fix branches may be merged into the develop branch as well as the release branch
  • the release branch is continuously deployed to -stage
• once tested and bug-fixed, create a pull request to merge a release into master
  • master is deployed to production
  • release merge into master is tagged in master with the release version

[ndushay]

:-1: I think the gitflow approach is overkill in most of our sul-dlss repos. It creates extra steps, a bunch of overhead and the benefits seem thin for most of our git repos.

I think gitflow makes sense for much larger teams working in the same code base, and for situations where there are more people poking at the dev and stage instances to ferret out problems. And where "releasing code" is a more formal process with more consumers using it.

I also don't agree with automatic deployments triggered by a commit, especially from a non-production branch.

[dazza-codes]

That's why it's a suggestion to provide reference material on this topic of branching and ways to do it effectively. All there is now is a sentence or two about using branches and that's it. I think there's more to this topic.

[ndushay]

@darrenleeweber yes, i understand it is a suggestion, but I disagree with the suggestion that this is an appropriate best practice for us to adopt at this time.

[eefahy]

:-1: I don't think we have or will have a consensus on any branching scheme for all projects, even as a suggestion. Branching schemes/workflows should be decided on project or team at a time and the decision should be documented for ease of transition from project to project.

[cbeer]

-0. I'd be more comfortable with a section in Versioning, maybe called "Version Control workflows" listing, possibly among other options, gitflow and github flow.

Maybe I'm worried that, as-is, this sounds like we have consensus on or are pushing the gitflow model, which I don't believe is or should be the case. But, I agree with @eefahy that branching is an important thing for project teams to agree on. Maybe that would be a good section in the project README.md? Once you get into integration with external tools, e.g. waffle.io, you get some extra benefits from a consistent process across a project team.

I think I'd be +0 in suggesting github flow is a DLSS best practice, and, although I think it is a better representation of existing practice, I'm not sure there's agreement on that either especially for project teams of 1.

[azaroth42]

:-1: We don't currently do this (gitflow) in general, and there's no consensus that it's a great idea.

:+1: to adding a section that teams should agree upon workflow in general, including this (and trello vs waffle, etc) Please submit a new proposal for it.