5 ms·

Disagree pretty strongly about rebasing. If you are an experienced and full-time programmer then you should know how to rebase and merge, and understand when th

Disagree pretty strongly about rebasing. If you are an experienced and full-time programmer then you should know how to rebase and merge, and understand when the time and place is for each one, and I personally always rebase my local topic branches. I understand this is a bit subjective and may depend on local context, but essentially my view is this: When you merge, conflicts are resolved for a large number of independent commits all at once and crammed into a potentially large blackbox commit that is not directly related to either the work on main or your topic branch. When a developer makes a mistake in that merge (which happens often), it's hard to reason about their mental state and whether they fully grokked the state both both branches. Even worse is when there is a logical conflict, but the lines aren't near each other, so git just happily merges. By contrast, when you rebase, you are essentially going through the exercise of updating your commits for the current state of the world, and each conflict is resolved locally to where it was authored, including completely removing things that no longer make sense. The result is fully bisectable, and this property can be preserved along with the ability to see original author and merge times with existing timestamps and merging to main with the -no-ff flag. Obviously this requires some expertise with git, but it's not very difficult once you get the hang of it, and in fact leads to more disciplined thinking about how your changes will roll out. WRT to squashing, I think the value depends on the scale of the team and codebase you're working for. The larger it is, the more squashed you want things for posterity. However for small teams, as long as you keep CI building, finer grained history can be useful. This also depends on the size of your feature branches and deploy cadence, so YMMV.

aidos 3y ago
It’s irrational, but I always stand on the sidelines of these conversations being a little bit cross that people slag off rebasing. At some point someone pointed out that rebasing changed the history and if you change the history of a public branch everyone was going to have a bad time. That got turned into “rebasing is bad” and now people keep rolling it out the same old trope. It’s a tool, and a good one for managing your work. If you don’t know how to use it then you’re doing yourself a disservice. In terms of squashing, my rule is that I squint at the PR and if the commits are going to have value in a years time then I’ll merge commit otherwise I’ll squash. In 10 years of running my codebase I’ve never blamed and thought to myself “I wish there were more fine grained commits here” so it’s obviously working fine for me. As you say, do what works for your team but make sure you understand the tools and what they provide for you.
- heavenlyblue 3y ago
  You can rebase while keeping all of the commits in your feature branch, you will just be asked to resolve conflicts for each one of them (if any). I don't understand what the fuss is all about.
IlliOnato 3y ago
I think squashing or not squashing really depends on the quality of individual commits in the topic branch. Myself, I almost always "edit the history" of my topic branch before merging. Often enough some interactive rebasing and occasional commit-splitting is employed. I do it to turn my topic branch into a series of clean logical commits, so that each one can easily be reviewed on its own. I would not want to loose such history, so I avoid squashing unless it's mandated. When people don't have time\energy\skills\inclination for this kind of clean-up and their topic branch commits are a mess of random things reflecting their actual development process -- including errors, fixing these errors, random experimentation, etc., there is not much value in keeping such history, and squashing often produces and cleaner and easier to review commit. However, for me the end result of a development cycle is not just a good state of the code (functional, tested, documented), but a good history of that code too: reviewable and bisect-able. Git provides tools to maintain such manageable history, but does not do it for you.

aidos 3y ago

It’s irrational, but I always stand on the sidelines of these conversations being a little bit cross that people slag off rebasing. At some point someone pointed out that rebasing changed the history and if you change the history of a public branch everyone was going to have a bad time. That got turned into “rebasing is bad” and now people keep rolling it out the same old trope. It’s a tool, and a good one for managing your work. If you don’t know how to use it then you’re doing yourself a disservice. In terms of squashing, my rule is that I squint at the PR and if the commits are going to have value in a years time then I’ll merge commit otherwise I’ll squash. In 10 years of running my codebase I’ve never blamed and thought to myself “I wish there were more fine grained commits here” so it’s obviously working fine for me. As you say, do what works for your team but make sure you understand the tools and what they provide for you.

heavenlyblue 3y ago
You can rebase while keeping all of the commits in your feature branch, you will just be asked to resolve conflicts for each one of them (if any). I don't understand what the fuss is all about.

IlliOnato 3y ago

I think squashing or not squashing really depends on the quality of individual commits in the topic branch. Myself, I almost always "edit the history" of my topic branch before merging. Often enough some interactive rebasing and occasional commit-splitting is employed. I do it to turn my topic branch into a series of clean logical commits, so that each one can easily be reviewed on its own. I would not want to loose such history, so I avoid squashing unless it's mandated. When people don't have time\energy\skills\inclination for this kind of clean-up and their topic branch commits are a mess of random things reflecting their actual development process -- including errors, fixing these errors, random experimentation, etc., there is not much value in keeping such history, and squashing often produces and cleaner and easier to review commit. However, for me the end result of a development cycle is not just a good state of the code (functional, tested, documented), but a good history of that code too: reviewable and bisect-able. Git provides tools to maintain such manageable history, but does not do it for you.