Docs: update squashing commits with rebase section
Problem to solve
This came about as one of our community contributor asked the question whether to use merge
or rebase
.
Although, I used rebase quite often admittedly, I wanted to give our official answer because I remember seeing a doc against using rebase.
https://docs.gitlab.com/ee/topics/gitlab_flow.html#squashing-commits-with-rebase
Above doc seems to suggests that we should never use rebase once our code hits upstream. However, I see myself rebasing quite often mainly to fix Dangerbot warnings, bringing in changes from master, or even just general commit history clean up for readability.
I feel the wording of that doc is too strongly against rebasing and I'm wondering if this is still the case.
However, you should never rebase commits you have pushed to a remote server.
I understand the general reasoning behind it, but in practice we rarely work on the same branch and it feels too restrictive and makes the history too messy.
I think we could rewrite it to say something along the lines of:
However, you should never rebase commits you have pushed to a remote server and the branch is "shared" with others
Also, @tkuah summarised as below as well.
It's OK to have the following flow:
- Develop locally. Rebase all the time.
- Push to an MR for review. Don't rebase, but add commits as it's being reviewed.
- It's approved! Rebase, right before it's ready to be merged
But in real life, this happens all the time, with little problems:
- Develop locally. Rebase all the time.
- Push to an MR for review. Rebase from master all the time, re-arrange commits etc.
- The reviewer reviews the whole diff again
- It's approved! Merge
As @eread pointed out during our Slack conversation, Apply suggestions could become quite noisy.
One other option is to use squash commit on merge feature, but that doesn't provide full control as we don't always want to turn it into a single commit.
Further details
This is the one we link from our doc, but it seems to have a softer tone to it.
https://www.atlassian.com/blog/git/git-team-workflows-merge-or-rebase
Proposal
Update the doc so that we can fully understand the consequences of using rebase, but leave it up to individual developers to make a judgement call if it doesn't affect others.
Who can address the issue
I suppose we need a consensus that this is where we stand today. If not, I should follow what the doc says more precisely. I believe that's counter productive, but I'll need to get over it if that's how we do at GitLab.