5 ms·
What do you use your "cleaner history" for? I seldom go back and look at historical commits unless I'm debugging, in which case I'd prefer to know what actually
by m12k 6y ago
What do you use your "cleaner history" for? I seldom go back and look at historical commits unless I'm debugging, in which case I'd prefer to know what actually happened at the time with as much information preserved as possible.
- swalsh 6y agoFore removing code that's buggy in production. It's way easier to find and remove 1 commit.
- falcolas 6y agoIsn’t that what rolling back releases for? i.e. revert the container (or whatever your unit of release is) to the previous version? If you’re removing individual commits and re-releasing (rolling forward), you’re still at risk of being down, because you’re not going back to a known good release.
- m12k 6y agoAnd what do you think about the linked article that shows how it's easier to find exactly which code is buggy if you have it in small commits instead of one big squashed one?
- swalsh 6y agoGood, do what he did too... but in a feature branch.
- byte1918 6y agoA clean history with proper commit names can work as a change log for you app. We actually did that and it worked quite well. In Azure DevOps the release pipelines have access to the list of commits since the previous release so one only has to simply take the titles of those commits to build it.
- nikisweeting 6y agoYou can achieve that with PR titles instead of commit titles.
- spdionis 6y agoBut then... PR titles don't show up in the git log.
- Aeolun 6y agoI’d prefer that too, but preserving all commits often leads to things like: ‘Changed file 1’, ‘Changed file 2 and 3’ etc. You’ll have a ton of noisy commits that together make up one full feature. In this case having all that noise squashed into one commit with a proper description is much nicer.