Submitted 1 year ago by alphacyberranger@lemmy.world to programmer_humor@programming.dev
https://lemmy.world/pictrs/image/8586dcb9-d8b0-4b5e-b05e-3aba81756991.jpeg
I usually merge because I like to see commit history as it happened and because rebasing multiple commits with conflicts is more time-consuming than fixing it in one merge commit.
I do rebase smaller changes though to reduce merge commit clutter and like interactive rebase to clean up my local commit mess before pushing.
If the changes are small enough I just do rebase -Xtheirs main, and look to see if anything looks fucky (git diff main…).
I create a new branch locally with git switch --create, pull everything from main, sacrifice a small squirrel, and run the project to make sure everything still works.
You can just undo the last commit with git reset --soft HEAD~1
The little median in the middle is the dev who helps them fix their branch over screenshare
GandarfDeGrape@midwest.social 1 year ago
OK. Query.
Rebase or merge into current?
I personally never rebase. It always seems to have some problem. I’m surely there’s a place and time for rebasing but I’ve never seen it in action I guess.
dukk@programming.dev 1 year ago
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 often 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 1 year ago
You are aware you're talking about two different pieces of software?
GandarfDeGrape@midwest.social 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.
atyaz@reddthat.com 1 year ago
Always merge when you’re not sure. Rebasing rewrites your commit history, and merging with the squash flag discards history. In either case, you will not have a real log of what happened during development.
Why do you want that? Because it allows you to go back in time and search. For example, you could be looking for the exact commit that created a specific issue using git bisect. Rebasing all the commits in a feature branch makes it impossible to be sure they will even work, since they represent snapshots that never existed.
I’ll never understand why people suggest you should default to rebasing. When prompted about why, it’s usually some story about how it went wrong and it was just easier to do it the wrong way.
I’m not saying never squash or rebase. It depends on the situation but if you had to pick a default, it should be to simply merge.
Blamemeta@lemm.ee 1 year ago
What you do is create a third branch off master, cherry pick the commits from the feature branch, and merge in the third branch. So much easier.
yogo@lemm.ee 1 year ago
That’s called rebasing
BabaYaga@reddthat.com 1 year ago
I’ve definitely done this before…
GigglyBobble@kbin.social 1 year ago
If your cherry-pick doesn't run into conflicts why would your merge? You don't need to merge to master until you're done but you should merge from master to your feature branch regularly to keep it updated.
JDubbleu@programming.dev 1 year ago
This is actually genius. Gonna start using this at work.
rookeh@geddit.social 1 year ago
I’ve always merged. Rebase simplifies the history graph, but realistically I can’t think of a time where that has been important to me.
Maybe on some projects with a huge number of concurrent branches it becomes more important, probably less so for smaller teams.
NatoBoram@lemm.ee 1 year ago
It only matters if you want to be able to use the commit tree and actually find something. Otherwise, there’s no harm in using merges.
h14h@midwest.social 1 year ago
I try to structure my commits in a way that minimizes their blast radius, which usually likes trying to reduce the number of files In touch per commit.
For example, my commit history would look like this:
And then as I continue working, all changes will be
git commit --fixuped to one of those two commit’s hashes depending on where they occur.And when it’s time to rebase in full, I can do a
git rebase master --interactive --autosquash.dukk@programming.dev 1 year ago
This is the way! Small commits with descriptive commit names, then just fixup into a few feature commits. Makes rebase a breeze.
risottinopazzesco@feddit.it 1 year ago
Rebase. Merge into current leaves merge commits in the dev branches.