Decide merge/rebase policy for feature branches

We discussed this elsewhere already a bit.

Merging develop into the branch makes a mess if you try to read partial history, as you get the changed caused by the merge of unrelated issues as well. This may need a bit of policy? I typically do rebase, but that may have other problems.

!46 (comment 9829):

If I look at the 'Commits' tab of this GitLab merge request, I see only the commits in this branch and the merge requests from when I merged develop into this branch. The commits from develop itself are not included, as GitLab knows these were already in develop and this merge request merges to develop. Thus, looking through the commits on the 'Commits' tab is pretty convenient. Similarly, the 'Changes' tab should only show the differences of those commits and not all the changes from develop that were merged into this branch. I thus don't experience the 'mess' that you describe.

!46 (comment 9888):

First one has to understand the differences. Googling 'merge vs rebase' quickly provides links such as: https://www.atlassian.com/git/tutorials/merging-vs-rebasing. It also mentions the 'golden rule of rebasing', which essentially means that you should never rebase on a public branch.

In this particular case, you worked on the rail diagram generator in your local branch on your machine, pushed it to a branch on our official Eclipse ESCET GitLab, and created a merge request for it. The branch is then in the public repository, and everyone in the world can check it out. I did just that. As it is a public branch, and following the golden rule, I used a merge rather than a rebase. I think this was the only valid option in this case.

For local developments, which I've committed but not yet pushed, I regularly use the amend feature to amend the last commit. I also sometimes use interactive rebase to reorder, squash, etc commits, before pushing them. That fine as those have not yet been pushed. I think that once something is pushed, we should not rebase it anymore, as indicated by the golden rule.

I thus think that everyone is free to choose how to work locally on non-pushed commits, i.e. whether to use merge or rebase. Especially since cleaning the history via rebasing can be beneficial, but can also be more effort. Once something is pushed, I think merging is the only option left.

What do you think?

!46 (comment 10167):

I agree that anything not published may be changed in any way you desire. However, it is hardly relevant, since nobody is going to figure out what tortures I have applied to the branch before publishing :)

I am aware of merge vs rebase, and the golden rule. The core point there imho is the interpretation of "public". You seem to take the word quite literally, while I see it as "shared" which is a somewhat different notion.

The idea of the golden rule is to never change commits that other people may use for extending, to avoid finding your extension is suddenly built on thin air when another developer moves the underlying commits. For shared branches this makes a lot of sense, and I fully agree on applying the golden rule. I don't think "public" is the key notion, in my view "shared" is the key notion. Eg when you and I share a branch in an otherwise inaccessible branch for everybody else, the golden rule is still a good idea for us. The generally available branches such as develop and master are by definition shared, and in an open-source context also by definition public, so here both notions align. These are arguably also the main branches where the golden rule applies, and with "publically available" being much easier to grasp than "may be shared with other developers that don't tell you they exist but may be building extensive derived work", I can see why the notion "public" was used rather than "shared".

A merge has the advantage that no history is lost, but also the disadvantage that no history is lost. In this case you mrged develop into the railroad branch, dragging in a number of code changes that have no relation at all with railroad diagrams. The distinction between railroad changes and develop progress gets blurred. In particular, it becomes mostly impossible to read commit ranges that include a merge.

A rebase in git exists in two flavours. The complicated version is the interactive rebase, where you can basically mess up the branch completely if you like. The non-complicated version of a rebase is just moving the base point of a branch to some other commit. Here, rebase is only discussed in the non-complicated version. A rebase has the advantage that code in the branch stays cleanly separated from other changes in the repository. The disadvantage of a rebase is that it loses the original starting time of the branch. It pretends the branch was created at a later date than it really was originally. The rebase may cause a conflict that needs to be resolved, but that is in my view a needed adjustment for moving in time on non-solid ground. That is, you may need to compensate for changes in the underlying commits. I have been thinking about other things in the branch itself that may change or go wrong, but I don't think there are any. With the clean separation, one can easily find what changes are introduced in the branch, by who, and when.

So we arrive at the crux of the point, how public is a development branch containing non-finished software? In the literal sense, public is easily defined as "can be read or copied by anyone", and yes, in that sense a development branch is public. The more complicated question imho is, is the branch shared? That is, are there developers mad enough to start off from my work-in-progress, build an awesome extension in some other direction, not tell us about it, and expect it to be stable ground?

My guess is no, but let's explore a bit further.

A merge to railroad would work for the awesome branch, since it doesn't lose anything. A rebase however also doesn't change code beyond compensating for the changes of the 'develop' ground. As such, the unknown developer should be able to rebase his awesom branch onto the equivalent rebased commit, and it all should continue to work without a hitch. Git cannot find the equivalent commit of a rebased branch, but conceptually, I don't see why this would fail.

Of course neither merge nor rebase makes the railroad branch stable ground for extending. We may decide that the first commits were so wrong we don't want them, and replace that part by something else. The unknown developer then has a problem in either case, since accepting the awesome patch would bring back the deleted code that we don't want.

So there you have it. In my view, the golden rule is not as simple black-and-white as "public" (can be read and copied by anyone) despite of claims in that direction.

For feature branches, I think it mostly mixes changes from different and unrelated sources into an intangible mess that hampers development progress, in order to allow for a practice no sane developer would do, in particular for anything larger than a throw-away experiment.

In the github project I work in, the practice is that the patch developer is also the owner of the feature branch. A feature branch is quick-sand ground. Anything is allowed in the feature branch by the owner, including merge from 'master' ('develop' for us), rebase, interactive rebase, deleting, or closing and burning with fire if so desired. Non-owners of the feature branch may review, make suggested changes, and approve / merge if rights permit.

These rules are not strictly applied in practice. Sometimes additional commits are pushed onto the branch for fixing if the owner doesn't mind or is clearly not capable of doing it (lots of very fresh developers there). In the other direction, if reviewing just results in minor requested changes or even just suggestions for possible changes and the owner is capable, and has rights to merge the feature, a remark like "feel free to commit when you are done." is basically approval to commit the last changes and merge without further review.

My request for policies was more in this latter direction, should we agree on rules for handling feature branches (and possibly other branches as well)?

!46 (comment 10168)

If I look at the 'Commits' tab of this GitLab merge request, I see only the commits in this branch and the merge requests from when I merged develop into this branch.

If you read "changes since you last reviewed", and those changes involves a merge, you get the stuff you don't want there.

I collect this here to further the discussion in a separate issue, to keep focus and have it archived/referenceable.