Consider Switching to Git Flow

[ilexp]

Summary

The Duality repo currently uses a custom setup for its branches and workflow. To make it easier for new contributors to understand the process, consider adopting the widely used git flow model, or a variant of it.

Analysis

• This can be done entirely by renaming branches and updating docs in the wiki.
• Renaming a branch should be no big deal and not a breaking change for forked repos.
  • Branch off from the original branch using the new name.
  • Push the new branch to the repo.
  • Delete the old branch on the repo.
  • Fetch + Prune the local clone of the repo.
• Branches to be renamed:
  • master becomes develop
  • release becomes master
  • develop-3.0 becomes release/3.0
  • 1.x becomes archive/1.x
  • Any ongoing feature branch becomes feature/[3.0/]name-of-whatever
• Update the docs:
  • Development Cycle
  • Branch Descriptions
  • Make sure there's a link it in the appropriate .github docs
• Deviations from standard git flow:
  • Using slashes for feature and release branch prefixes instead of hyphens.
  • Allow to directly merge smaller changes directly from develop to master, except for really big stuff.
  • Using archive branches for old major versions.
• Whether or not to switch to the new model is to be discussed.
  • Is there really a need to do this?
  • Does it make the development process easier or harder?

[BobGneu]

SO Discussion of pros and cons

GitFlow makes the process of developing features in git easier because it establishes very clear processes through which you contribute. As long as you follow the stages of a flow, (branch feature > commit > merge to develop) your contributions are easy to follow and rebase.

A major deviation from the current cycle is that most changes occur in develop, and only patches occur off of master. It also helps with understanding and classification of branch intent. A feature enhances the project in a substantive way, a hotfix addresses a bug in production and the like.

I have been using GitFlow professionally for the last 2 years and until someone defines a better flow I don't think we will be using anything different.

As defined above, I'm not entirely sure the renames are accurate to the process as discussed in the standard sources, but we ought to do whatever is convenient to keep working on the project. Using /3.0/ would definitely help with grouping features.

As I understand it, Release branches are supposed to be quick and focused on wrapping up develop for release. Long running release branches sound like version branches in this model, in which case the question would be why not fork the project? Is the intent to maintain 3.0 and 2.0 separately?

[ilexp]

Thanks for the discussion link and your insights on this!

Long running release branches sound like version branches in this model, in which case the question would be why not fork the project? Is the intent to maintain 3.0 and 2.0 separately?

The Duality approach for major version changes so far is documented roughly on this page, but in short: Different major versions are maintained simultaneously, but only until the new major version is released. As soon as that happens, the previous major version is branched off master and archived, while the released major version branch is merged into new master. So there's only one "current" version, but a very long transition period from one to the next.

Forking into a different project for different major versions sounds a bit too much for this, I think a branch would be preferable here, whatever name it will carry under git flow (or any other development model). Not sure naming it release is ideal either - but not sure what the proper alternative would be.

As defined above, I'm not entirely sure the renames are accurate to the process as discussed in the standard sources, but we ought to do whatever is convenient to keep working on the project. Using /3.0/ would definitely help with grouping features.

Yep, definitely. The naming isn't final, but in any case I do hope for a good middle ground between "git flow familiarity" and "easy to transform the current model into".

[BobGneu]

There are quite a few adaptations to GitFlow that seem to be inline with the goals you shared.

Maintaining multiple major versions is definitely an option, just not often done. Here is one such discussion.

[Barsonax]

I have been using git flow professionally lately too and so far I like it. Sourcetree even has built in support for it.

[Barsonax]

2 years later and I would suggest its better to look at something like githubflow. Having a separate develop and master doesn't give you any advantages but can cause some pesky merge conflicts. 2 long lived branches that represent the same history is bound to go wrong.

Releasing a new version should be done by creating a new tag. No need for complicated merges and this also makes it easy to see which versions where deployed in the past.

To support older versions we should have a separate branch for each older version we support. These branches are basically a master branch for their respective version. Bringing changes from a newer version to a old version should be done with cherrypicks.