[Phlogistique]

This is possible by doing this:

  git checkout feature
  git rebase main 
  git checkout main
  git merge --no-ff feature

[finnthehuman]

I came to the comments to post the same thing. --no-ff is under appreciated.

I like that this poster is at least thinking about what he wants the history to look like, but you’ll never get it good with a broad rule. It really takes the exercise of rewriting every change you make from a stream of consciousness set of WIP commits into a logical series of incremental patches with clear commit messages. And doing that every time you want to push anything (especially when it is “just” a WIP or feature branch). After a months practice your sense of taste will kick in and tell you if a --no-ff merge seems appropriate for the current chunk of work.

[svalorzen]

This is what I also do. I rebase all my branches and merge them with a no-fast-forward commit, which does not introduce any changes itself, but can be used to document the overall changes of a specific feature.

The best part about this workflow is that history remains linear; it is very easy to track the history of changes (since there is never a "branch" with changes on both sides) while at the same time you keep the ability to visualize where the start/end points for a given feature were.

It also works with nested branches! You simply create a new branch2 from your branch1, and then merge --no-ff branch2 to branch1.

[scooble]

You also get to write a nice detailed commit message for the merge commit explaining the purpose of the branch being merged, which may not be apparent from the individual commits. Without the merge commit I’m not sure where this would go.

[koo6]

right, and then git log --first-parent

[ufo]

On Github the workflow we use for this is rebase in the command line and then press the "Create a merge commit" button in the web UI.

[larusso]

Isn’t that what GitHub does when the rebase strategy. Because when the rebase can’t be made cleanly GitHub still asks for conflict resolution.

[yxhuvud]

No. If you rebase you get no merge commit by default.

[jlarky2012]

I was going to post exactly the same. Bonus point you can make it work like that in GitLab (but not GitHub)