I want clean history, but that really means (a) clean and (b) history.

People can (and probably should) rebase their private trees (their own work). That’s a cleanup. But never other peoples code. That’s a “destroy history”

So the history part is fairly easy. There’s only one major rule, and one minor clarification:

  • You must never EVER destroy other peoples history. You must not rebase commits other people did.

[…]

If you are working with git together with other people, it’s worth a read.

  • fitgse@sh.itjust.works
    link
    fedilink
    arrow-up
    0
    ·
    11 days ago

    If ‘—first-parent’ was the default way that git log worked, I don’t think we’d even be having this argument over how to merge branches.

    In my opinion, the best strategy is to always use a merge commit, and then when viewing master, always use —first-parent which will ONLY show commits on master. This gives you:

    • a very clean, linear history
    • the ability to let people work in their branches in their own way (it is ok to merge master into your branch multiple times without rebasing)
    • you can dig into the history of any branch if needed
    • it makes it easy to backport changes as you can cherry-pick out the merge commit which contains everything.

    The problem is just the default log view of git and tools.