Do you sqash commits when you merge to main?
-
Do you sqash commits when you merge to main?
We always kept the full history but i think it is a bit messy for an overview how main changed. Especially if i want to know what changed between two MRs/PRs.
What are your arguments to do it like you do?
-
R relay@relay.an.exchange shared this topic
-
Do you sqash commits when you merge to main?
We always kept the full history but i think it is a bit messy for an overview how main changed. Especially if i want to know what changed between two MRs/PRs.
What are your arguments to do it like you do?
IMO it only gets messy if the individual commits/commit messages are messy. Writing meaningful commit messages takes some discipline. So no, I don't squash since I see it as part of the documentation.
The "conventional commits" approach definitely helps: https://www.conventionalcommits.org/
-
Do you sqash commits when you merge to main?
We always kept the full history but i think it is a bit messy for an overview how main changed. Especially if i want to know what changed between two MRs/PRs.
What are your arguments to do it like you do?
@satobi nope we don’t and it annoying when contractors or new devs come in trying to keep history clean. Reality is no one is really going through the history that often. I focus on the team having more detailed commits so when we do have to go back we know exactly what happened.
I like proper merge commits, especially when there’s conflicts. Maybe it’s because we deal with a lot of contractors but it’s saved my butt a lot.
-
Do you sqash commits when you merge to main?
We always kept the full history but i think it is a bit messy for an overview how main changed. Especially if i want to know what changed between two MRs/PRs.
What are your arguments to do it like you do?
After a few weeks of microcommitting on a branch, I like to squash and I also keep the branch.
-
Do you sqash commits when you merge to main?
We always kept the full history but i think it is a bit messy for an overview how main changed. Especially if i want to know what changed between two MRs/PRs.
What are your arguments to do it like you do?
@satobi Keep the full history, but rebase and do a --no-ff merge each time. That way you can look through history as an "express train" (just focusing on the one-per-PR merge commits) or as a "stopping train" (seeing every commit) https://pdh11.blogspot.com/2013/06/bow-shaped-branches-git-workflow.html
-
@satobi nope we don’t and it annoying when contractors or new devs come in trying to keep history clean. Reality is no one is really going through the history that often. I focus on the team having more detailed commits so when we do have to go back we know exactly what happened.
I like proper merge commits, especially when there’s conflicts. Maybe it’s because we deal with a lot of contractors but it’s saved my butt a lot.
@troy @satobi I don't like squash merging.
As above, history exists. Often when you need to delve into a branch, I've found having the "real" commits ("oops", "cleanup", "refactor slightly") etc can help. It's not infrequently that the "simple cleanup" introduced a weird bug.
Besides, if you want to see "nice clean history", then use "git log --merges" on main and you'll only see the PRs.
-
Do you sqash commits when you merge to main?
We always kept the full history but i think it is a bit messy for an overview how main changed. Especially if i want to know what changed between two MRs/PRs.
What are your arguments to do it like you do?
@satobi No, absolutely not. Because on a main branch it's often useful to maintain invariants like, the branch tip should always compile and pass tests, and each "step" from one main branch tip to the next should represent a coherent functional change in the software (e.g. a feature or bug fix), but when reviewing the history of the code it's often useful to see each functional change broken down in more granularity than that, so that you understand the story of how the change was made. (For example, in test driven development, you might write the tests in one step and write the code that makes them pass in a later step.) You can only get the benefits of both approaches if you don't squash commits.
Though, when I'm working I do make tiny commits like "fix", "WIP on thing", "checkpoint - some tests pass", and _those_ I do squash, but I usually do that before even pushing the branch. Those tiny incremental commits are just "implementation details".
-
@satobi nope we don’t and it annoying when contractors or new devs come in trying to keep history clean. Reality is no one is really going through the history that often. I focus on the team having more detailed commits so when we do have to go back we know exactly what happened.
I like proper merge commits, especially when there’s conflicts. Maybe it’s because we deal with a lot of contractors but it’s saved my butt a lot.
-
Do you sqash commits when you merge to main?
We always kept the full history but i think it is a bit messy for an overview how main changed. Especially if i want to know what changed between two MRs/PRs.
What are your arguments to do it like you do?
@satobi I never squash.
I require the MR author to create a sequence of logically separate, easily reviewable commits, with detailed log messages describing what was changed and why. Squashing would waste all that work.
When the MR is accepted I rebase it on top of the target branch so we get a linear history, but that's only a matter of taste. We use merge commits only for concurrently maintained release lines.
-
IMO it only gets messy if the individual commits/commit messages are messy. Writing meaningful commit messages takes some discipline. So no, I don't squash since I see it as part of the documentation.
The "conventional commits" approach definitely helps: https://www.conventionalcommits.org/
I don‘t want to hear, that my discipline is the problem🫠
But yes I spend not enough time an attention at the commit messages so they aren‘t as clear as they should.I want to learn that
-
@troy @satobi I don't like squash merging.
As above, history exists. Often when you need to delve into a branch, I've found having the "real" commits ("oops", "cleanup", "refactor slightly") etc can help. It's not infrequently that the "simple cleanup" introduced a weird bug.
Besides, if you want to see "nice clean history", then use "git log --merges" on main and you'll only see the PRs.
-
After a few weeks of microcommitting on a branch, I like to squash and I also keep the branch.
Why do you do microcommitting? And what does it mean to you?
-
@satobi Keep the full history, but rebase and do a --no-ff merge each time. That way you can look through history as an "express train" (just focusing on the one-per-PR merge commits) or as a "stopping train" (seeing every commit) https://pdh11.blogspot.com/2013/06/bow-shaped-branches-git-workflow.html
Ahh interesting approach. I think it gets harder with many Developers. Have you experience with that?
