6 ms·
Should they be squashing instead?
by good-idea 5y ago
Should they be squashing instead?
- brimstedt 5y agoI was actually hoping for a nuanced view on code branch/merge tactics. Got any suggestions on the topic?
- good-idea 5y agoI don't have any good resources off-hand (other than what shows up in a quick search), but my "best practices" are to always squash and keep PRs as small as possible. When a working branch falls behind main, I prefer to rebase it instead of merging from main to keep it up to date. However, if you've already pushed your working branch to a repo, after rebasing you need to `git push --force` - which is a problem if there are others who have previously cloned the working branch.
- vincentmarle 5y agoSquashing also introduces problems when you are resolving merge conflicts in your branch: squashing doesn’t preserve merge conflict resolution so you end up having to resolve those conflicts again after merging.
- codyb 5y agoGreat comment and spot on. You can avoid the issue with force by using `—force-with-lease` which won’t push the force if there’ve been changes upstream. That’s a bunch to type so I alias it to `fwl` In `~/.git config` and use it after rebases.
- zentiggr 5y agoThis looks entirely offtopic. Commenting on wrong post?
- oplav 5y agoIt sounds like a git joke about squashing vs merging.
- blendergeek 5y agoIt looks to me like GP may have commented without reading the article. "Mergers ruin everything" could be misread as "Merges ruin everything". Just reading the title could lead someone to think this was a discussion about git best-practices.