Programmer Humor

19623 readers

507 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

Keep content in english
No advertisements
Posts must be related to programming or programmer topics

founded 1 year ago

MODERATORS

[email protected]

1110

Rebase Supremacy (programming.dev)

submitted 7 months ago by [email protected] to c/[email protected]

232 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 6 points 7 months ago (2 children)

Bad take IMO,

At 10+ YOE, I use rebase almost exclusively. Branch from main, rebase to clean up commit history before putting up a PR. If commits are curated properly you don't run into conflicts very often. Branches really shouldn't be shared too often anyway, and the ones that are should be write protected.

Catastrophic data loss isn't really possible either with git since it's all preserved and you can git reflog even if you mess up.

The meme is right. Git good

[–] [email protected] 1 points 7 months ago (1 children)

When rebasing, it applies the changes without the commit history?

Does that mean that when you fast forward your main/dev branch and commit, you then add a single commit that encompasses every changes that were rebase?

[–] [email protected] 2 points 7 months ago* (last edited 7 months ago)

No, there are no fast-forwards with rebasing. A rebase will take take the diff of each commit on your feature branch that has diverged from master and apply those each in turn, creating new commits for each one. The end result is that you have a linear history as though you had branched from master and made your commits just now.

If you had branched like this:

A -> B -> C (master)
   \
     \ -> D (feature)

It would like this after merging master into your feature branch:

A -> B -> C (master) ->   E (feature)
  \                                    /
    \ -> D -------------------> /

And it would like this if you instead rebased your feature branch onto master:

A -> B -> C (master) -> D' (feature)

This is why it's called a "rebase": the current state of master becomes the starting point or "base" for all of your subsequent commits. Assuming no conflicts, the diff between A and D is the same as the diff between A and D'.

[–] [email protected] 0 points 7 months ago (1 children)

Years of experience don't really matter here, that's just call to authority, in this case yourself. You might as well be the worst git user ever after 20 years of usage, or the best after 2. We don't know that.

Anyway, what you're saying basically requires a perfect world to be true. Feature branch flow is perfectly fine, but you do end up with merge conflicts constantly, unless you have cordoned off areas of the repo for certain users. Two people working on unrelated features, both change a signature of some helper/util method, merge conflict. Nothing serious, can be fixed in a minute, and rebasing or merging won't help for either.

Merge is perfectly fine. And arguing about which strategy to use is one of those autistic debates we as an industry seemingly love to have. It doesn't matter, but you'll find people screaming at each other about it. See Emacs vs. Vi. Same crap.

[–] [email protected] 0 points 7 months ago

Merge is fine, but not knowing both rebase and merge is dumb. And I guess I've been in a perfect world this whole time in huge technical orgs lol.