Hacker News new | ask | show | jobs
by daniellarusso 1811 days ago
One of the repos I interact with, the team rebases all their local branch commits to master.

It is very difficult to read the commit history and get a sense of anything except Jira issue codes.

One needs to look at the individual files and read the code to understand what the commit was for.
2 comments
nerdponx 1811 days ago
This is why the best Git workflows IMO involve rebasing and squashing the branch down to a couple of well-defined "logical commits", then merging that (with --no-ff of course) into master/main/trunk.

This forces individual programmers to think somewhat carefully about leaving a sensible commit history behind.

link
CuriousCosmic 1811 days ago
I think that's a consequence of rebasing. If you just merge instead, you can use the branching/merging to get a sense of complete features/changes.
link
nerdponx 1811 days ago
Right, I think there's a bit of subtlety lost here. "Squash and merge to trunk" is very different from "rebase on every pull on a feature branch" which is very different from "rebase and fixup/squash before merging to trunk" etc.

On a feature branch, whether you constantly rebase against master or merge from master probably should depend on the nature of the feature branch and what exactly has been happening on master. And it ultimately doesn't matter that much.

In my experience, as long as branches are ultimately merged to master with --no-ff, you can almost always recover a sensible commit history, and you should almost always end up with a sensible, tidy master to base new branches off of. If you rebase with squash/fixup on the feature branch before merging, all the better, because then you get nice "meaningful" commits on the feature branch. But even if that doesn't happen and the feature branch is a mess, at least you could write a meaningful merge commit message.

Maybe things get hairy with huge teams or huge projects that could necessitate a different workflow. But most developers are not working on projects like that.

link
CuriousCosmic 1811 days ago
Yep I agree. I tend to rebase my feature branches into a sensible history and then merge that in as I find that leaves the cleanest history that is still easily navigable.

I wish this workflow was better supported but since it isn't most people just default to squash and merge or rebase and merge.

link