Using 'Git rebase' to Perfect Commits • Hacker News Board

Re: Using 'Git rebase' to Perfect Commits

#21

Post by Double_a_92 » Tue, Feb 08, 2022, 12:12 PM UTC

I still don't really understand why so many devs seem to have a need for this. For me every commit I make is a good one that I would like to keep in the history. Why should I need to reorder or rename or group any of my commits? All my work (of days or even weeks) is neatly containted within one branch, and that branch gets merged at the end. Why is that not ok? Why should I hide my work history into one "blob" commit instead of just having the Merge commit on the master branch?

The only use I could imagine is, if you have very short-lived branches (i.e. 1-2 days) with lots of random commits. Like e.g. "Oh I'm going for lunch, lets commit."

Re: Using 'Git rebase' to Perfect Commits

#22

Post by [deleted] » Tue, Feb 08, 2022, 1:24 PM UTC

Double_a_92 wrote: post #21

I still don't really understand why so many devs seem to have a need for this. For me every commit I make is a good one that I would like to keep in the history. Why should I need to reorder or rename or group any of my commits? All my work (of days or even weeks) is neatly containted within one branch, and that branch gets merged at the end. Why is that not ok? Why should I hide my work history into one "blob" commi…

[deleted]

Re: Using 'Git rebase' to Perfect Commits

#23

Post by colourgarden » Tue, Feb 08, 2022, 4:52 PM UTC

Double_a_92 wrote: post #21

I still don't really understand why so many devs seem to have a need for this. For me every commit I make is a good one that I would like to keep in the history. Why should I need to reorder or rename or group any of my commits? All my work (of days or even weeks) is neatly containted within one branch, and that branch gets merged at the end. Why is that not ok? Why should I hide my work history into one "blob" commi…

> every commit I make is a good one that I would like to keep in the history

This is certainly not typical.

When working in a team, you may need to push something half-finished so that someone else can work on what they need to. Or testing something before refactoring.

For these scenarios, rebase is very handy for cleaning things up before merging.

Re: Using 'Git rebase' to Perfect Commits

#24

Post by Double_a_92 » Thu, Feb 10, 2022, 9:36 PM UTC

colourgarden wrote: post #23

Double_a_92 wrote: post #21

I still don't really understand why so many devs seem to have a need for this. For me every commit I make is a good one that I would like to keep in the history. Why should I need to reorder or rename or group any of my commits? All my work (of days or even weeks) is neatly containted within one branch, and that branch gets merged at the end. Why is that not ok? Why should I hide my work history into one "blob" commi…

> every commit I make is a good one that I would like to keep in the history This is certainly not typical. When working in a team, you may need to push something half-finished so that someone else can work on what they need to. Or testing something before refactoring. For these scenarios, rebase is very handy for cleaning things up before merging.

Why can't the merged branch contain commits that don't compile? As long as it has a clean commit message, I don't see the issue. It's just part of the history. On that day you e.g. committed some broken prototype code so your teammate could improve it. So?

If I clean up something I only do it for new commits before they are ever pushed to remote. My rule is basically to never rewrite history, that someone else might already have checked out on their machine.