5 ms·
I've heard this before, and it seems reasonable on the surface. The argument I make against this viewpoint is: "git rebase gives us powerful tools that allow us
by Sir_Cmpwn 7y ago
I've heard this before, and it seems reasonable on the surface. The argument I make against this viewpoint is: "git rebase gives us powerful tools that allow us to curate a good commit history in the same way we use refactoring to uphold good software design practices."
- mixmastamyk 7y agoMost shops don't follow good software design practices, so how likely is it to get a practice one-step-removed from that, with a difficult UI to boot, adopted?
- Sir_Cmpwn 7y agoSo you're saying we shouldn't argue for the adoption of good software design practices? There are a lot of software teams that do care, you know.
- mixmastamyk 7y agoBut this isn't that. It's one step removed. Maybe if the UI gets better. Even then an uphill battle.
- fulafel 7y agoPRs are a good unit of changes for examining meaningful units of changes. No reason to lose info about how the sausage was actually made, it is also a valuable record
- gshulegaard 7y agoMy biggest issue with that argument though is what constitutes "good" is subjective. For me a good commit history is one that faithfully chronicles what happened. With this in mind, acceptable curation of the history for me is squashing or separating commits and neither of these require rebase. But I wouldn't object if a colleague chose to use rebase to accomplish this. I would, however, object to reordering commits or rebasing since this alters the chronicle. Which I guess leaves me with my opinion on rebase: You can, but you don't need to. If you are going to, be sure you understand what you are doing and don't alter the chronicle.