Hacker News Reader

Rebasing, and thus git rebase, is a standard step that predates git.

The typical workflow is that you create a branch off master and do your work on it. Once thw work is complete is rebase the branch if master has changed so that you can test and review independently, then perform a trivial merge.

View on HN

The epiphany I experienced with rebasing is that this is an incorrect visualisation of the workflow. It's not like you create a separate branch and work independent of master. It's more like working on a kind of local pre-release ahead of master.

You work on the development/pre-release, then consolidate by cherry-picking or otherwise, leaving all the todo's, spinoffs, experimental, personal notes in the pre-release. Like a reptile shedding its skin.

It was the default workflow when people used to share patch files as attachments on community forums. You could only diff your changes to the latest tip and send these changes to the maintainer as a “fast forward” merge. If the patch broke, you fixed it locally (rebase) and attached a new version for the maintainers to apply.

Reply on news.ycombinator.com