6 ms·
That's really cool, the hand-drawn charts are super clear. I've never considered rebasing but I'll give it a go on my next project
by datene 7y ago
That's really cool, the hand-drawn charts are super clear. I've never considered rebasing but I'll give it a go on my next project
- PascalPrecht 7y agoYou should! If there's one tool I'd recommend everyone to learn it's rebasing. Especially interactive rebasing because it enables things like splitting commits apart, squashing them together and even run automated programs.
- WorldMaker 7y agoThe interactive tools exist outside of rebase. You can also split commits apart as you work on them with for example `git add -i` without needing to rebase. I've met junior developers I'd never trust to get rebase right, but interactive add was an important tool to teach them.
- PascalPrecht 7y ago`git add i` is indeed powerful and lets you interactively craft your index before you create a commit. It doesn't enable you to split up an existing commit though.
- WorldMaker 7y agoInteractive hunk splitting the index maps to the mental model of "splitting the work in progress commit". That may be all a developer needs in a "rebase never" workflow.
- PascalPrecht 7y agoCertainly can not disagree :) I'm not trying to convince anyone here. By now I've sold over 230 copies and I"m getting really positive feedback. So it must be useful to someone.
- BossingAround 7y ago> I've never considered rebasing ... Sounds like you either don't use GIT a lot, or your team doesn't care about clean history. With clean history, you can, for example, automate the generation of release notes. It's very helpful if you ask me.
- wdfx 7y agoIMO the pursuit of, or even a concept of 'clean history' is a fallacy and waste of time. It is a level of obsession which I think is just not worth it. Furthermore, a commit log is not the same thing as release notes. More often than not you need release notes for a product to be constructed in a user centric manner, describing features or changes which affect them - and that actually comes from the original requirements lists and not the minute implementation details. IMO don't rebase, don't worry about 'clean' history. Obsessing over those is time consuming and risky. Just do your work and move on. Let your manager/lead deal with the external world.
- BossingAround 7y ago> Obsessing over those is time consuming and risky That's interesting, because to me, it's slopy. If someone doesn't worry about git history, it typically means they don't do pull requests, and that typically, they don't understand know how git works (i.e. how to leverage the features of git). For me, worrying about history literally takes no extra time. I honestly don't understand the argument.
- wdfx 7y agoPull requests is not the only way to collaborate in a team. git also works with other tools for review and merging can be done by other means.
- PascalPrecht 7y agoHi, Pascal here. The author. Just to clarify this: The aim of rebasing is not a clean commit history. It enables you to make one in case you've been creating lots of work-in-progress commits with no semantic meaning, which makes it harder to work with it. However, even if you stick to that, it's not like rebasing isn't of value anymore. You might still be interesting in squashing your commits or splitting them up or simply rebase on branch on top of another for various reason. That said, I'd recommend to not advocate not to rebase if it's based on the assumption that it's only useful for clean commit histories.