Changes in our Git Branching flow

[davigonz]

Considering the following scenario with our current Git branching flow:

1. We create branches to work on 2.9.2 features that are eventually merged into master branch.
2. Once 2.9.2 development is finished, we create release_2.9.2 branch. At this point,master branch is blocked and if I or other contributors want to keep working on features for 2.10 release and merge them is not possible because we have to wait for merging and tagging release_2.9.2(step 3).
3. Once release_2.9.2 is approved and fully tested, me merged it into master, tag the commit with oc-android-2.9.2 and make the release public via GitHub and PlayStore.
4. Merge master into stable.

This branching flow comes from long time ago and to speed up and not block our development process, including contributions, and according to what GitFlow defines, I would suggest the next changes:

1. Same as before
2. Once 2.9.2 development is finished, we create release_2.9.2 branch but master is not blocked anymore and we can keep merging features for coming releases because of step 3 changes.
3. Once release_2.9.2 is approved and fully tested, me merged it into stable, tag the commit oc-android-2.9.2 and make the release public via GitHub and PlayStore.
4. Merge stable into master.

Think this workflow is widely used and fits properly to our case, what are your thoughts about? @felixboehm @PVince81 @michaelstingl @jesmrec

[michaelstingl]

@davigonz we use OneFlow (simple version) in the ios-app. Could you also have a look?

[davigonz]

we use OneFlow (simple version) in the ios-app. Could you also have a look?

I've just read the details in https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow and these are the main differences with our current process:

Tasks	Our current Flow	One Flow
Tag release commit	Tag last commit in master branch after merging release_x.x one.	Tag last commit in release_x.x branch.
Use stable branch	Yes	Not needed

The main disadvantage I see in OneFlow is that master branch will contain a messy history, i.e. commits of features for next releases before commits of current releases (when using rebase) or mixed (when using merge).

So I would keep the stable branch to have a branch with the history properly ordered and find the latest production version of the code in an easy way, as Variation - develop + master section details in OneFlow documentation.

To sum up, we can keep using our current branching flow but with one of the next options to avoid blockers in master branch.

Option 1 (One flow variation, develop + master) ✅

1. Tag release commit in release_x.x branch with x.x tag.
2. Merge release_x.x branch into master.
3. Merge x.x tag into stable.

Option 2:

1. Merge release_x.x branch into stable.
2. Tag release commit in stable branch with x.x tag.
3. Merge stable branch into master.

Maybe, the @owncloud/ios-core-developers guys want to add something about their flow. 😄

[hannesa2]

When I read "At this point,master branch is blocked ..." this is really bad ! Maybe this is the reason why PR needs that much time here.

It's your decision what to do, but you should definite avoid blocking

[hannesa2]

I vote at least for a removement of the PR-must-based-on-recent-master rule and accept such a git flow

Advantage: the annoying "please rebase on master, then we can merge" tasks are gone

[davigonz]

I vote at least for a removement of the PR-must-based-on-recent-master rule Advantage: the annoying "please rebase on master, then we can merge" tasks are gone

Do you mean do not merge any feature till we release a new version? That's what I see in the git flow you attach.

[hannesa2]

Sorry bad example, I hope this clarify it

PR-must-based-NOT-on-recent-master rule

Instead of current

PR-must-based-on-recent-master rule

[davigonz]

So you propose to use merge instead of rebase, is that correct? Could you give us an example by using branch names like the ones I used in https://github.com/owncloud/android/issues/2359#issue-381584501?

[hannesa2]

Correct, merge instead of rebase ! It avoids tons of "please rebase on master"

All development is done in master and after a release_2.9.2 was created, only cherry picks to release_2.9.2 will be done.

No merge release_2.9.2 to master is valid. This cross merge makes confusion.

-my suggestion-

[hannesa2]

Ordinary I'm a rebaser, but when you work in a big team with a lot parallel epics, I mutated to a merger. When here code format or lints are merged within hours, then I like rebase. But to be honest, this is not the reality (sorry, it's not to blame someone. It's just to explain) What me make here to a merger, is that even simply commit needs weeks to month to be merged.

[michaelstingl]

Could the merge button options help here?

In the repo of the new iOS app, we only have the squash-merging button enabled.

[davigonz]

When here code format or lints are merged within hours, then I like rebase.

IMHO, choosing rebase or merge is not a matter of having the features merged asap but a matter of what a team and a project needs. In our case, having an ordered history is what we wanted/needed till now and using rebase provides us that because we have the commits ordered by feature and not mixed in case we want to know where a specific issue comes from.

Could the merge button options help here?

Maybe allow rebase merging? Documentation says: This allows contributors to merge a pull request by rebasing their individual commits onto the base branch.

So I guess contributors do not need to perform the rebase manually any more but not sure what's going to happen when some conflicts come up.

[hannesa2]

Normally speed matters, but not everywhere. So you stay on recent behavior

[jesmrec]

Already moved to GitFlow.