Go-ipfs: Fully implementing git-flow

[Kubuxu]

Our way of working on the project (feature workflow) already is in great part of the git-flow and we could benefit greatly by fully implementing it.

Required changes to our workflow would be:

• [x] creation of release branch - release - pointing to the latest release
• [ ] enabling protection on that branch (if it is possible)
• [ ] working on the release (bumping versions, updating changelog) in a version branch (branch named after the version).
• [ ] fast-forward the release branch to the version branch
• [ ] tagging release on the release branch
• [ ] merging the release branch back to master

It is a bit more complicated but would allow for continuous work on the master and new release, which as project grows the time from release initiation to the release will grow.

Git-flow also creates concept of hot-fix branches. Branches that are based off current the release branch for quick deployment of fix (as master could have included some other changes that need longer review). This means that there is no need for _feature freeze_ as version branches will not be affected by new features added to the master.

I would like to hear your opinions about this matter, especially from the major contributors and people that will be preparing releases.

[RichardLitt]

I am a big fan of git-flow, fully implemented. I think that this is the right way to do things, and may save us some issues in the long run. However, I'm not sure the current system is broken; what do you think we lose right now with our current system? Where have we performed less than satisfactorily? This might be a premature optimization.

I still agree, I just need to ask these questions first.

[Kubuxu]

I've never said that current system is broken. It works great and as it is very similar to git-flow (feature model), implementing git-flow fully right now might be "premature optimization" but it isn't like you can implement it right away when it is needed. We will notice lack of git-flow (version branches) when we run into problems. I wouldn't like the situation from dev0.4 to repeat, when there was a bit of mess with PRs.

If this was done because all of breaking changes in the 0.4 release we didn't want the main branch to include them. With git-flow fully implemented we could have switched the main branch to release and continue working on master with breaking changes.

[haarts]

I'm not a release manager or a contributor in any way to IPFS so feel absolutely free to ignore everything I say.
But I, too, feel Git Flow is a bit over the top: http://endoflineblog.com/gitflow-considered-harmful. And to further radicalize the topic (again feel free to ignore), what about C4, the process ZeroMQ is employing (rational)?

[Kubuxu]

I have to disagree with that blog post, he points out two "mistakes" gitflow makes:

Release and development branch split - release branch is still really useful for triggering automatic build systems, git based packages (AUR) and so on. Tags don't solve the problem here as with tags you can't difference release candidates and full releases.

The uncleanness of --no-ff is personal preference, with right tooling (even CLI) the graph of added features is cleaner than simple chain where you don't know where one feature starts and other ends. Also as go-ipfs has quite strict review process fast forward merges are really rare.

_My personal opinion bellow_
I consider the "considered harmful" essays to be harmful. I can recommend “Considered Harmful” Essays Considered Harmful essay.

[whyrusleeping]

how would git flow have helped in the dev0.4.0 case where we wanted to make changes and push releases on master, with the old code,while also still adding new features to the 0.4.0 branch with the incompatible code?

[Kubuxu]

We could have "stabilize" main branch (by switching main branch to release from master), continuing to support it with hotfixes (where you create branch of a last release tag) and keep the development process on master. As hotfixes are merged into release and master the branches still would keep common root at the top. Making each PR made to release also applicable to master (possibly with merge conflict but it is resolvable, isn't it).

Or we could use _version branch_ and keep only bugfixes in it.

[MasterJames]

Some use a dev branch I'm used to.
here is one other recommendation
http://nvie.com/posts/a-successful-git-branching-model/

[Kubuxu]

This is exactly what git-flow is.

[Stebalien]

We're switching to a fixed release model where we'll have to branch off a new release every 6 weeks, releasing three weeks after branching. That means:

• Each release has 6 weeks of features, 3 weeks of baking.
• This means that every release will get:
  
  
  
  • 3 weeks of "shared" time with the previous release.
  
  
  • 3 weeks of focus time.
  
  

Given that we can't afford to lose that shared time, we need to find a way to keep merging when the next release is baking. Git-flow was designed for exactly this kind of scheduled release cycle.

First of all, any objections from the team? Specifically, the model I'm talking about is https://nvie.com/posts/a-successful-git-branching-model/.

Second, we have two options:

• A: True git-flow. That is, the model described in the link above.
• B: Git-flow as described in this issue.

Where the only difference is:

• A: patches go to develop, "master" is the stable release branch.
• B: patches go to master, "release" is the stable release branch.

I'm leaning towards B given that:

1. For 99% of users, this work flow will look like the standard GitHub PR model.
2. We're already half-way there (we already have a release branch).

The main thing we need to implement full git-flow is to start doing the back merges (e.g., https://github.com/ipfs/go-ipfs/pull/7243), so we can easily deploy hot patches at any time.

Thoughts?

[Stebalien]

Note: I'm forking this into a new issue (#7245) to avoid confusion. The original issue has some _slight_ differences from GitFlow (like fast-forwarding) that I'm not sure about.