[zith]

A workflow I was introduced to and have worked with a lot in my teams is,

1. Everyone uses feature branches

2. Everyone cleans up their branch using interactive rebase on top of main before review

3. All merges have been freshly rebase on main

I think it works very well and keeps the history clean while preserving "each commit does one thing".

[mr_mitm]

I wish my team would at least use the rebase merge strategy by default to avoid branch graphs looking like the London tube network. Not in 10 years did I have an issue with that (okay, except accidentally rebasing deliberate no-ff merges).

The one time I suggested that, someone immediately came up to me trying to convince me that rebases are the most dangerous thing ever.

[skitsofrandom]

I worked on a team that did this, + required feature branches to get squashed to a single commit before merge. On that commit, we'd require a very brief bullet list of changes, sometimes a POC, and a link to the PR. This made git blame a lot more helpful when debugging issues. I am a big fan of this approach.

[dijksterhuis]

> On that commit, we'd require a very brief bullet list of changes, sometimes a POC, and a link to the PR.

one of the first things i do in a new gitlab repo is set up ff+squash commit merges with the squash commit message template automatically pulling the MR title, link, description, authors etc.

    %{title} 

    -
    ref: %{reference}
    url: %{url}
    authored by: %{merge_request_author}
    merged by: %{merged_by}
    -
    %{description}