"When merging fixes and features into master, we avoid merge commits and use rebases and fast-forward as much as possible. This makes the branch very easy to browse, understand and work with – as it is 100% linear."
~ Daniel Stenberg, author of curl.

So that's why everyone's been raving about rebase in ! πŸ€”

Β· Β· 3 Β· 0 Β· 2

@celia has there been some rebase chatter? we use it pretty much exclusively at work

@annika Well, not chatter... πŸ˜…

It just kept springing up again and again over time. Probably for good reason as I see now!

@celia I always squash commits when merging to master. Most of the time nobody want to see all the tiny WIP commits from the developer on master.

Squashing also results in a single commit to master and creates a linear history.

Also, not all developers can properly rebase a branch and rewrite remote history by accident, causing trouble on all the other developers local branches.

My advice is always to stay away from rebasing.

@sarvasana @celia but squashing is a form of rebasing. And sometimes it makes sense to have more than one commit coming out of a feature branch.

@sarvasana @celia @tychi Sometimes I rebase, sometimes I squash. The decision is driven by a single goal: keeping the main branch history as readable and relevant as possible. Otherwise it has low value to keep an history.

@celia love me some rebase. But I hate when the remote blocks force push on anything but the main branch.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.