Programmer Humor

19618 readers

783 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

Feyter@programming.dev

anzo@programming.dev

BurningTurtle@programming.dev

pylapp@programming.dev

218

Rebase Supremacy (programming.dev)

submitted 7 months ago by JPDev@programming.dev to c/programmer_humor@programming.dev

193 comments fedilink hide all child comments

(page 2) 50 comments

sorted by: hot top controversial new old

[–] tatterdemalion@programming.dev 3 points 7 months ago (2 children)

Rebase feature branch, merge commit into main (NO SQUASH).

load more comments (2 replies)

[–] jaemo@sh.itjust.works 2 points 7 months ago

Fuck a merge commit! Rebase ervray day bay bayyy.

[–] jjjalljs@ttrpg.network 2 points 7 months ago (9 children)

I used to only merge. Now I rebase. The repo is set up to require squash and rebase when going to main.

All the garbage "spelled thing wrong" and "ran formatter" commits go away. Main is clean and linear.

load more comments (9 replies)

[–] sirleonelle@sh.itjust.works 2 points 7 months ago (1 children)

I'll go one further: use git rebase --interactive

[–] natecox@programming.dev 2 points 7 months ago (2 children)

I remember learning about how to use this back in the day and what a game changer it was for my workflow.

Today I like to do all of the commits as I’m working. Maybe dozens or more as I chug along, marking off waypoints rather than logging actual changes. When I’m done a quick interactive rebase cleans up the history to meaningful commits quite nicely.

The fun part is that I will work with people sometimes who both swear that “rewriting history” is evil and should never be done, but also tell me how useful my commit logs are and want to know how I take such good notes as I go.

[–] swordsmanluke@programming.dev 2 points 7 months ago

Argh. I hate that argument.

Yes - "Rewriting history" is a Bad Thing - but o argue that's only on 'main' (or other shared branches). You should (IMHO) absolutely rewrite your local history pre-push for exactly the reasons you state.

If you rewrite main's history and force your changes everybody else is gonna have conflicts. Also - history is important for certain debugging and investigation. Don't be that guy.

Before you push though... rebasing your work to be easily digestible and have a single(ish) focus per commit is so helpful.

review is easier since concerns aren't mixed
If a commit needs to be reverted it limits the collateral damage
history is easier to follow because the commits tell a story

I use a stacked commit tool to help automate rebasing on upstream commits, but you can do it all with git pretty easily.

Anyway. Good on you; Keep the faith; etc etc. :)

load more comments (1 replies)

load more comments