[brento]

There is nothing wrong with rebasing a feature branch imho. Feature branches should be considered ephemeral. But it probably depends on your team and project size.

[sytse]

My personal opinion is that it breaks history and CI tests for all the feature branches. But at GitLab we encountered customers that insisted on having a linear history after migrating from SVN. Therefore there is a function in the UI of GitLab EE to rebase a merge request when accepting the merge request. See http://doc.gitlab.com/ee/workflow/rebase_before_merge.html

[solutionyogi]

Could you expand on what do you mean by rebase breaking CI tests? I don't see how that's possible.

[plorkyeran]

The results from previous CI runs are no longer connected to the rebased commits, and most people don't have CI set up to retest each commit individually after a rebase.

I've never found this to be an actual problem in practice.

[tehbeard]

Since a rebase changes the commit sha, I assume that's used as a reference for which version of the code the CI test was run against.

That said, shouldn't CI be triggered after the rebase anyway to confirm all still works?

[solutionyogi]

I see. But as you noted, one must do CI tests again after a rebase.

[sytse]

Indeed you need to do them again. But you also have to rerun them after a merge anyway. The problem is that you can no longer see which commits that you merged where green before the merge. For example is very useful if the merge itself breaks the tests (uncommon but it can happen).

[Mithaldu]

Edit: There's a well-written solution for that here: https://news.ycombinator.com/item?id=9745367

[tokenizerrr]

A CI test result is tied to a particular commit hash. If you change this commit hash the CI test result will no longer be tied to that one commit.