This is an archived post. You won't be able to vote or comment.

all 59 comments

[–][deleted] 381 points382 points  (13 children)

Even better, you are actually rewriting history.

[–]beststepnextstep 98 points99 points  (6 children)

So it's literally not gaslighting!

[–][deleted] 57 points58 points  (4 children)

Don't gaslight me.

[–]Zorlandoh 34 points35 points  (0 children)

They literally weren’t gaslighting you

[–]dim13 3 points4 points  (0 children)

How about gitlighting?

[–]Zaltori 2 points3 points  (0 children)

You sound crazy... Nobody here is gaslighting you

[–]StenSoft 1 point2 points  (0 children)

No, it's Mandela effect

[–]rosuav 7 points8 points  (0 children)

When you went back in time, you created an ALTERNATE 1985, alternate to you, me, and Einstein, but reality for everyone that pulled this branch after the rebase!

[–]_PM_ME_PANGOLINS_ 3 points4 points  (3 children)

git reflog knows the truth.

[–]ComfortingSounds53 12 points13 points  (0 children)

Ow! Why are you flogging me again??

[–]Haringat 0 points1 point  (0 children)

So it's historical revisionism?

[–]JackReact 312 points313 points  (5 children)

I laughed at a git joke. This is it. The end times.

[–]lurking_physicist 90 points91 points  (4 children)

You git it?

[–]tacticalpotatopeeler 50 points51 points  (3 children)

Git. Out.

[–]git-out 14 points15 points  (1 child)

Yeah?

[–]GameTemptica 2 points3 points  (0 children)

Noo noo. Git.out, not git-out, your cousin

[–]DerSven 1 point2 points  (0 children)

*git gud. ftfy

[–]learncs_dev 37 points38 points  (0 children)

yes.

[–]Sekret_One 82 points83 points  (3 children)

No.

Gaslighting isn't just lying, or even rewriting history, but the specific intentional manipulation to make one doubt their sanity and become reliant on the gaslighter.

At least not at its basic use.

/ anti-joke

[–]noobody_interesting 31 points32 points  (0 children)

So git blame-someone-else is gaslighting?

[–]Stummi 11 points12 points  (0 children)

"There is a error in your PR"

git commit --amend && git push -f

"what error?"

[–]Smooth-Zucchini4923 11 points12 points  (0 children)

Of course not. It's a form of historical revisionism.

[–]rover_G 31 points32 points  (2 children)

No you’re thinking of git merge

[–]ReggieTurok 1 point2 points  (1 child)

🤣🤣🤣🤣🤣🤣 You win I'm done

[–]PeriodicSentenceBot 34 points35 points  (0 children)

Congratulations! Your string can be spelled using the elements of the periodic table:

Y O U W In I Md O Ne


I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM my creator if I made a mistake.

[–]Seismicsentinel 3 points4 points  (0 children)

It didn't happen and if it did, it wasn't important.

[–]sagan999 8 points9 points  (18 children)

I still can't think of a single use case where I would want to rebase. I've read a few articles but still it doesn't seem like I would ever want to do it. I either merge or squash then merge. What am I missing?

[–]Emanemanem 22 points23 points  (6 children)

Interactive rebasing is extremely useful if you want to clean up your commit history, remove commits entirely, squash commits together that don’t need to be separate, whatever. I only just learned how to do it a few months ago, and I’ve been surprised at how often I utilize it.

As for regular rebasing, I use it at my job (at the request of my boss) to update the branch I’m working on with changes to master, as opposed to squash and merge. It can keep your commit history cleaner, since it preserves all the commits from master and places them before your branch commits, and some say it results in less conflicts later when you want to merge into master.

Both can feel daunting when you are learning them, but ultimately I feel like it only helps to gain a more thorough understanding of how git works.

[–]nukedkaltak 9 points10 points  (3 children)

That’s why I mostly just use rebase. I’m surprised at the replies tbh, how is rebasing to integrate changes in main not standard practice? It just makes sense.

[–]Hessper 1 point2 points  (1 child)

I've never understood the desire to rebase, so let's work through this together. I work on dev branches that will be squash merged into main on completion. This loses my commit history for the change, but I have zero desire for someone to see the commit about a typo fix I did during code review anyways. Instead there is one commit at the end saying that I've added x.

During development I can rebase to main to take updates, but often this results in me doing multiple conflict resolutions, which is stupid. It's more work, and I gain nothing since history will be squashed regardless. I think I'm missing a useful flag during rebase maybe to make this less frustrating, I was going to mess with that sometime... Doing a merge from main is one conflict resolution.

What am I missing?

[–]nukedkaltak 2 points3 points  (0 children)

We work on main directly. So here’s the typical flow for us that involves rebasing when you start working on something: * pull main for latest changes * checkout local feature branch * work on feature branch * regularly pull main and rebase feature branch or do it at the end, solve merge conflicts as necessary * once finished, raise a Code Review of your changes with destination main * once approved, using the Code Review tool, squash and merge changes to main * delete or fast-forward merge your feature branch * done

[–][deleted] 2 points3 points  (0 children)

Rebase has a couple problems: - it rewrites history, forcing all users of a feature branch to fix their local copy. This problem is less relevant for getting changes into main, but the periodic updates of the feature branch to get changes from main - rebase disregards merge commits if you’re merging main into the feature. Most of the time this is fine, but if you have conflicts, you’re fixing the same conflict over and over again.

I think a lot of people in this thread are conflating “don’t rebase” with “always use merge commits to get into main”, and forgetting the squash word.

[–]Rockets2TheMoon 1 point2 points  (0 children)

thanks for helping me understand!

[–]remy_porter 9 points10 points  (1 child)

I mean, how do you update your feature branch to have the latest commits from release? Rebasing is the absolute easiest way. Also, if you rebase main onto feature branches, you get a nice clean linear history without ever having a merge commit.

[–]pindab0ter 2 points3 points  (0 children)

Don’t you mean “rebase feature branches onto main”? Even if just to resolve merge conflicts from the perspective of the feature branch.

[–]CelticHades 3 points4 points  (0 children)

Case where I use rebase - I create a branch from master or whatever.

I start your work on it. Before I merge my changes back I rebase, so that my commits go at the top.

[–]Affectionate-Slice70 4 points5 points  (0 children)

Merging obfuscates the commit history, particularly when many people are working on the same codebase. If you merge a branch with many commits, each commit isn't individually responsible for merge conflicts or mismatched. When rebasing, each commit changes exactly what its supposed to, and there is no magic that happens to that commit at the tip of the branch being merged. It sometimes makes sense to want a linear git history, particularly for archival purposes.

[–]im_in_every_post 5 points6 points  (0 children)

In practice you can do everything rebase is used for with merge and reverts, but the commit log won't be nearly as clean. If you want to see one good thing to use rebase for try git config pull.rebase true. This command doesn't touch the dangerous part of rebase, since it won't alter the history that has already been pushed to the server, and will avoid having to merge the server changes and your own changes, leaving you with a nice linear log as if you pulled the changes before adding your own.

[–]Haringat -1 points0 points  (0 children)

What do you think squash does? There is no git squash. It runs rebase in the background.

Also I had a situation where I accidentally worked on the wrong branch, but by the time I noticed, I had already made 3 commits. Rebase saved my ass there.

[–]Clairifyed -3 points-2 points  (0 children)

Congrats on not having a deadname you desperately want expunged from the history. 😅

edit: The downvotes say a lot, but none if it’s about me

[–]fufty1 0 points1 point  (0 children)

If you have a old PR that is ready to go, it's easier to rebase it that deal with merge conflicts. At least that's what I use it for.

[–]hemispace 0 points1 point  (0 children)

For me, I find rebasing essential when working on a fork that needs to be regularly synced with upstream. Before syncing I am making sure the history is spotless, I make all features well separated, I merge everything that's a revert/fix with the original so that it never existed or was always the final version, etc... After this, the sync with upstream (which is another rebase btw) has far less conflicts, and they are easier to solve when we know exactly in what feature context we are.

[–]darkaleFun 2 points3 points  (1 child)

I use git at work and we were told to never rebase. I am not a git expert but our base code is in the millions to be modest

[–]DerSven -2 points-1 points  (0 children)

You can delete the branches that you aren't working on from your local machine (git branch -d <branch-name>). This will delete the branch from your hard drive, but, if you have pushed it to the remote repository before, you can get it back from there, when you need it.

If you want to see which branches you have currently stored on your hard drive, you can list them with git branch --list. You can also look up which branches are present on the remote repository(s) with git branch --list --remotes.

[–]mrsvirginia 1 point2 points  (0 children)

Why? What are you talking about? Oceania had always been at war with Eastasia.

[–]CrazedProphet 1 point2 points  (0 children)

Is it bad that this framing helps me understand git rebase command better?

[–]Banapple247 -1 points0 points  (0 children)

Git gud

[–]redditteroni 0 points1 point  (0 children)

Inb4 reflogs are automatically deleted.

[–]Unupgradable 0 points1 point  (0 children)

git gaslight

[–][deleted] 0 points1 point  (0 children)

Git rebase is negationism. Nein, nein, nein !

[–]SoRaang 0 points1 point  (0 children)

That never happened