Hacker News Reader

Comment by placatedmayhem | Hacker News Reader

Rebase has become so integral to my workflow, it's hard to imagine living without it. I intentionally avoid merge commits, including configuring git pull to rebase rather than merge. I find it so much easier to commit a bunch of tiny iterations while doing local testing, rebase and squash them, then post them for review. As a bonus, I frequently push after each of those small commits to a feature branch so I don't have to worry about losing work if my drive dies.

View on HN

Personally, I actually stopped using rebase or advocating it's use (because noobies mess up their history all the time with it). I just commit whatever, then when the code is merged to trunk/dev/master/whatever I use `merge --squash`.

Reviews are very rarely happening on the commit level, so having lots of small "meaningless" commits (lint fixes, fix spec, add thing) hasn't been an issue but having squashed merge commits (effectively a rebase that squashes everything) has made release management so much easier for our team.

It also has the benefit of just less cognitive overhead of micro-managing my feature branch commits that are WIP or currently in-review.

This is my workflow as well, it's great. Github is configured so merging a PR into master will automatically produce a squashed commit.

My rule of thumb, always rebase unless you hit a series of merge conflict while rebasing. Then either merge, or squash your branch then re-run the rebase.

We require linear history on our shared mainline branches so the squash workflow works great for us using Github as well. Another benefit is the "show changes since last review" option when reviewing a PR - it's been a while but I'm not sure if this is possible with a rebase-based workflow.

Thanks. I thought it was just me.

> Rebase has become so integral to my workflow, it's hard to imagine living without it.

Same. I use it to reorganise branches before submitting change requests or merging:

- Combing or splitting commits so that each commit contains a small unit of a logical change

- Reordering commits to related changes are near each other

- Reordering commits so changes that are depended on by later commits occur earlier.

- Rewording commit descriptions to have a lengthy explanation, if needed

- Removing small commits that fix minor typos

It's a great way to turn the commit history of a project into one of logical changes, rather than a simple temporal log of every change.

(I had a colleague who was so used to CVS and couldn't get his head around not using version control as a time tracking device.)

> It's a great way to turn the commit history of a project into one of logical changes, rather than a simple temporal log of every change.

This seems a bit like an unhealthy obsession. I would be curious to know if the benefits of having a perfect git history outweigh the costs. A temporal log of changes is good enough for me.

It's not an obsession, and the commit history isn't perfect by any means.

But don't underestimate the value of a good commit history, especially if you are using git blame to understand a change from several years ago. Wading through small typo fixes gets in the way.

Git encourages you to use branches, and rebasing allows you to squash simple typo fixes and minor changes, so you can review a change with a few commits that are easier to understand instead of a dozen.

Used with cherry picking, you can also move commits to other branches. I often find that bigger features changes turn into multiple branches and PRs, which is easier to review.

The cost isn't very much. Maybe a few minutes at most reorganizing a branch.

It also forces me to review the branch before submitting a PR. Sometimes I catch issues or use that as an opportunity to split into multiple PRs.

This all makes sense and I don't doubt that it's worth it for you, I guess I just personally don't lean on commit history that much.

I use git blame to find who touched the code, but not necessarily why. And during reviews I spent most of the time looking at the totality of the code changes (along with tests and PR notes) rather than deducing what's going on by looking at one commit at a time.

Overall I see the history as a log, which is only an artifact and not a product on its own.

Specifically, more atomic commits make rollbacks easier when issues with a change are discovered after merge (e.g., in integration and user acceptance testing). In the very active code bases I've worked on, generating a rollback commit for a single commit is far more straightforward than having to deal with a merge commit that potentially includes other merges (e.g., with `git pull`'s default behavior). In fact, GitHub's pull request UI has it as a single button.

Wouldn't these types of changes more commonly be caught while testing against a branch?

Also in many cases I would think that the fix ends up being even smaller (or bigger) than a single commit (the commit isn't actually atomic).

Maybe the codebases I've worked on weren't active enough for this to be a common problem. But also, having too many cooks in the kitchen may be a part of the problem here too.

This might be obvious, but it's worth checking out git commit --amend. Then you can be regularly committing, but to the same commit.

Depending on the workflow and collaboration in branches in teams, amending may not be ideal. Amending changes to an existing commit will generate a new sha checksum, thus resulting in a diverging history if the branch is often pushed to the remote Git server. That's one of the rare cases where "git push --force" makes sense but also requires awareness for other collaborators on the branch - they need to run "git fetch && git reset --hard origin/branchname" every time, and best "git stash" to temporarily remove any local changes, with running "git stash pop" afterwards.

One reason to regularly push commits can be to trigger CI/CD, security scanning and dev/staging deployments or review apps.

GitLab team member here - before joining GitLab in 2020, I was a Git/GitLab trainer. https://www.netways.de/en/blog/2018/05/24/releasing-our-git-...

I've completely replaced my use of --force with --force-with-lease. It does the same thing, except it will abort if the upstream branch has been updated since your last pull. This pretty much prevents the concerns about clobbering others' work.

After reading this comment about "git push --force-with-lease" in https://stackoverflow.com/a/53011907/1821348 my workflows with "git fetch" first would not work with "git push --force-with-lease", behaving as if "git push --force" was run. Theoretically - I need to do some testing here.

Thanks for the pointer into learning something new :)

For sure, it doesn't work with every workflow. But I think it would for the OP's described workflow.

And I am currently waiting for my GitLab backpack for contributing something (very small, but apparently it counted!) so thank you to the team for that!

Thanks for sharing your ideas, appreciate the thoughts to learn new perspectives :-)

And also thanks for contributing, every contribution counts and helps :-) Maybe see you at a future hackathon :) https://about.gitlab.com/community/contribute/

--amend if you have a modification to your most recent commit.

--fixup if you have a modification to an earlier commits

rebase --autosquash amend the fixup(s) to the commit(s) they belong too.

(Of course you need to know what you doing. Otherwise you create conficts tedious to resolve in the rebase)

--amend would interact with the remote system poorly if there's a push with each commit.

You have to force push, but you have to do that when pushing a rebased branch as well. In either case it’s a history rewrite. It’s not a big deal unless other people have pulled that branch—if they have they will need to reconcile things on their end as well.

> Rebase has become so integral to my workflow, it's hard to imagine living without it

I'm the same. I commit frequently. A lot of those end up being `--amend`, but a lot of time I will rebase and squash/reorder/etc. In fact I'd say the majority of time I push changes I've rewritten my local history at least once.

According to any git history you'd find from me on the server, you'd think I never accidentally commit syntax errors, break unit tests, and that when I do big structure changes or refactors I get it the way I want it on my first attempt.

> including configuring git pull to rebase rather than merge

It annoys me a bit this isn't the default -- at least for teams that work from a single centralized git repo (eg: almost all corporate dev, and the majority of open source). I've done it for years and have never had any issue with it.

It doesn't rewrite anything but your local (non-pushed) history, which is totally fine. (Unless you are working with multiple remotes, in which case it causes chaos, which I think is why it isn't the default).

Are there other drawbacks?

then there's autosquash and similar

honestly the commit graph as a first-class value yields a lot of ideas in my mind, we should be investigating compute at the subtree layer more often.

Reply on news.ycombinator.com