[11235813213455]

It's more that feature branches should be rebased instead of merging the main branch into it (like most developers unfortunately do)

    [pull]
        rebase = true

in your ~/.gitconfig, and just pull the branch your forked from

This way, the git history is linear, clean and readable

[ScottFree]

Rebase is so terrible and not because of the lost commit history (most of which deserves to be lost, imho. git merge history is too verbose and oftentimes not useful).

My issue with rebase is that as soon as you want a single other person to commit code to that branch, you can no longer rebase. Everything must be merged from that point on, otherwise the histories diverge and you wind up in rebase/merge hell.

The only alternative I've found is to over-communicate every push to your co-worker because it requires him to stash his changes, delete his local branch, pull down the "new" remote branch and re-apply his changes.

[pxue]

use interactive rebase?

[AstralStorm]

And you lose information about when given code was done. (Commit date and parent) Which is crucial to know if any given piece is stale in a bigger project. Stale code may be rotten code.

Why is a linear history better again? If you cannot read history graphs, perhaps you should really not use a VCS where merging happens.