this post was submitted on 14 Aug 2023
464 points (97.7% liked)

Programmer Humor

19551 readers
950 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

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] dukk@programming.dev 17 points 1 year ago* (last edited 1 year ago) (2 children)

Merge commits suck.

My biggest issue with GitHub is that it always squashes and merges. It’s really annoying as it not only takes away from commit history, but it also puts the fork out of sync with the main branch, and I’ll often realize this after having implemented another features, forcing me end up cherry picking just to fix it. Luckily LazyGit makes this process pretty painless, but still.

Seriously people, use FF-merge where you can.

Then again, if my feature branch has simply gone behind upstream, I usually pull and rebase. If you’ve got good commits, it’s a really simple process and saves me a lot of future headaches.

There’s obviously places not to use rebase(like when multiple people are working on a branch), but I consider it good practice to always rebase before merge. This way, we can always just FF-merge and avoid screwing with the Git history. We do this at my company and honestly, as long as you follow good practices, it should never really get too out of hand.

[–] GigglyBobble@kbin.social 14 points 1 year ago (1 children)

Merge commits suck.

My biggest issue with GitHub is that it always squashes and merges.

You are aware you're talking about two different pieces of software?

[–] dukk@programming.dev 4 points 1 year ago (1 children)

Yeah, I am. However GitHub, being the biggest Git hosting provider and all that, makes you use merge commits. FF-merges must be done manually from the command line. While this definitely isn’t a problem for me, many people out there just don’t care and merge without a second thought (which, as I said in my comment, results in having to create a new branch and cherry picking the commits onto there).

[–] themusicman@lemmy.world 3 points 1 year ago

You should check out the repo options on GitHub. It most definitely supports rebase merges, and you can disable other merge types if desired.

[–] GandarfDeGrape@midwest.social 3 points 1 year ago

Sounds like I just gotta get better with rebasing. But generally I do my merges clean from local changes. I'll commit and push, then merge in, push. Then keep working. Not too hard to track but I've found it's the diff at MR time that people really pay attention to. So individual commits haven't been too crucial.