Why use squash merging? #43
-
|
imo in the cases ive seen in this repo it's caused me more pain than it helps 🤷 also its not the default and u know I'm a default lover but there might be a legit reason? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
I prefer to avoid adding commits that get undone or are partial. It's just kind of extra noise in the commit history. For example, commits that exist just for formatting, or 2 or more commits that could be described as just one. Alternative to squash merges, I could ask you to interactively rebase your branch, but that could cause even more pain to you 😆 I don't always squash-merge, and try to take things on a case-by-case basis. But the majority of PRs can be summarized as one change, so I'll squash-merge those. If you're curious, I wrote some of my opinions on git history here: https://spenserblack.github.io/tutorials/git |
Beta Was this translation helpful? Give feedback.
-
|
i guess i do agree. my vehamant opposition was because I had started a pr that got completely out of sync because the squash commit didnt align with the history 🤬 but if I had rebased against main instead of manual merge conflicts... hmmmm 🤔 I guess it was a combo of my bad and a weird edge case of merging magic. documentation in contributing.md about merge/squash would be a good idea lmao 😜 after googling around for other devs opinions (in addition to yours) i kinda like this quote
— https://www.lloydatkinson.net/posts/2022/should-you-squash-merge-or-merge-commit/ squash is, like you said, awesome at condensing simple back-and-forth changes into one, while regular merge is useful for larger long-lived items where there might be multiple authors and multiple areas that were touched that you want to stay separate commits |
Beta Was this translation helpful? Give feedback.
I prefer to avoid adding commits that get undone or are partial. It's just kind of extra noise in the commit history. For example, commits that exist just for formatting, or 2 or more commits that could be described as just one. Alternative to squash merges, I could ask you to interactively rebase your branch, but that could cause even more pain to you 😆
I don't always squash-merge, and try to take things on a case-by-case basis. But the majority of PRs can be summarized as one change, so I'll squash-merge those.
If you're curious, I wrote some of my opinions on git history here: https://spenserblack.github.io/tutorials/git