Skip to content

re: How to create effective Pull Requests VIEW POST

re: Squash is valid when there is a lot of back and forth within the commits themselves which sometimes happens. I do A, commit, change my mind, then d...

I'm not saying there aren't times to take advantage of of it, but I have concerns because tools provide that as policy and I don't want people to take the recommendation that way.

There are always exceptions to the rule. I think with squash the most important thing is to cleanup before you push. Squash what should be squashed but never squash with something that has already been pushed.

Especially not after a (first) review/change-request! When you're rewriting history, I need to do over my entire review. Instead of just checking the changes since last the time.

I like the, add commits after review point. I intend to make the merge request a work in progress at that point and rebase when the review is complete.

My comment on squash was because gitlab can make every merge request squash before merge automatically.

code of conduct - report abuse