4 ms·
Github is not Git but I find the Squash and Merge functionality on Github's Pull Request system means I no longer need to worry about rebasing or squashing my c
by tomaytotomato 9mo ago
Github is not Git but I find the Squash and Merge functionality on Github's Pull Request system means I no longer need to worry about rebasing or squashing my commits locally before rebasing.
At work though it is still encouraged to rebase, and I have sometimes forgotten to squash and then had to abort, or just suck it up and resolve conflicts from my many local commits.
- cdmckay 9mo agoThis Rebase only makes sense if you making huge PRs where you need to break it down into smaller commits to have them make sense. If you keep your PRs small, squashing it works well enough, and is far less work and more consistent in teams. Expecting your team to carefully group their commits and have good commit messages for each is a lot of unnecessary extra work.
- ivanjermakov 9mo agoSquash is not Github specific and is part of git: git merge --squash
- quacker 9mo agoRight, but they are referring to configuration on a GitHub repository that can make squash merge automatic for all pull request merges. e.g. When clicking the big green "Merge pull request" button, it will automatically squash and merge the PR branch in. So then I don't need to remind or wait for contributors to do a squash merge before merging in their changes. (Or worse, forget to squash merge and then I need to fix up main).
- freeplay 9mo agoCouldn't agree more. Squash merges to main ONLY. That way, I don't care if your branch contains 100 commits or 1 commit. I don't need to worry about commit messages like: - fix 1 - fix 2 - dfljfdlkfdj - does it work now? Do whatever you want with your commits on your feature branch. Just make sure the title of your PR is clean and follows our formatting. Git history is always well formatted and linear. It's the ideal solution.