4 ms·
In the article he says he keeps the original branch with all of the history around after they squash them with a reference to the original PR in the squashed me
by rubyist5eva 5y ago
In the article he says he keeps the original branch with all of the history around after they squash them with a reference to the original PR in the squashed merge commit message. So you can always just checkout the original branch and go digging in the full history.
- waffletower 5y agoUnwieldy to keep branches around even on moderate sized teams/projects. You don't need them to have a `squashed` view of history when needed. I am surprised that developers still cling to this outdated squashing regimen when pull request tools found on github, gitlab, bitbucket etc. already provide synthetic squash views derived from atomic commits by default.
- rubyist5eva 5y agoHow is it unwieldy? They don't even show up locally when you `git branch` unless you've checked them out. Otherwise they just sit there doing nothing, there is literally no maintenance required on them once they've been squashed into mainline. Most central repositories end up having hundreds (or even thousands) of "finished" branches that nobody ever looks at anyway.
- waffletower 5y agoDepends on configuration if you wind up having that many. I use `git branch -v` often to figure out what branch a colleague is working on. I guess I could apply my same logic and use filtering tools here as well. But I don't see the benefit of squashing the merge commits when git CLI, github etc. can give you the same view without the gratuitous data loss.
- beberlei 5y agoThey show Github in their screenshots, and on Github you can delete a branch and the original commit history in the UI is still kept and available. So you don't have the branches locally, but Github still has them around.