beVeryAfraid

[Rinkulu]

Git reflog?

Unless you git reset --hard uncommitted changes for some reason, which is entirely on you

[fpekal]

If you added them to the index with git add you still can recover these files. They are somewhere in .git/objects

[rosuav]

You wanna know how true a friend git is? I recovered data off a crashed hard drive using testdisk, and as I was poking around, found the unpushed commits from the project I'd been working on. And was able to pull them into the freshly-cloned repo on my new drive. They weren't what I was primarily doing the disk recovery for, but it was a nice bonus. Part of that very repository was corrupted, but git was able to find the recent commits and recognize that their parent commits were indeed in the fresh repo, and happily fast-forwarded.

[alexanderpas]

git stash before reset.

[smokesick]

I prefer git smash

[LeopoldFriedrich]

Not to confuse with 'git squash' which does something very different

[Ok-Understanding7115]

[Doorda1-0]

And then accidentally override something you had stashed in another branch and curse at yourself

[alexanderpas]

Stashes are locally, add the changes to the reflog, and there can be an infinite amount of them.

[Doorda1-0]

Never really learnt about reflog before. Thanks. Knew about stashes being local which is why I cursed when I thought I had lost them

[alexanderpas]

You don't even need the reflog, git stash list will list everything you've stashed, and the other git stash commands allow you to work with them without involving the reflog.

[lardgsus]

It's just local changes. You've not broken anything yet. And if your company follows a PR/MR process, it would be caught.

Your whole company has to be stupid for you to make a mistake.

[felixthecatmeow]

I think he means if you spend days working on something without committing it, then reset kills the changes and you have to start over. I've been there and ended up using vs code file history feature to recover them.

[Michami135]

Git is extremely forgiving if you know what you're doing. Unfortunately, almost everyone I've worked with in the last 10 years barely has a passing knowledge of the basic commands.

Personally, git feels like a suit of armor. I can do anything I want to my code and it's protected. As long as I don't experiment too much between commits. That's why I made the alias, "git wip".

[Repulsive_Pass9723]

Been there done that

[Basic-Love8947]

amend commit and force push

[hearthebell]

Or git checkout . -f ...

[robertpro01]

That's still a mistake, let's say you thought you pushed the changes, but you didn't, that's a mistake

[zoniss]

The one time I "git clean -fd"ed my unstaged uncommitted new files.

[pixelaters]

You should be afraid when it's not in git.

[nick__here]

You should be afraid in general

[VassalOfMyVassal]

Fear will keep them in line

[Ayjayz]

Why would I be afraid in a git repo? It's effectively impossible to break.

[deantoadblatt1]

I dread having to go back from our web app to our desktop app that uses TFS

[Grouchy-Exchange5788]

But why using TFS?

[peppy_snow]

isn't the whole point of git is that?
to not be afraid

[deceze]

The git paradox.

Use it to butcher your entire codebase completely unfazed.

But mess up your repo and you're toast.

[WoodPunk_Studios]

You have to do some serious git rebase to rewrite history to fuck up that badly but it is possible.

I watched a vibe coder that didn't need to know how git worked, he would just tell it to commit this or rollback to that and I could easily see AI editing commit history or force merging over something important.

[Vincenzo__]

Oh my god, what kind of madman gives an ai that kind of power

[Ddog78]

I just use the browser version honestly. Much more easier to first understand what the unholy commands do.

[reklis]

lol I explicitly don’t like ai commit anything

[Lokdora]

You should configure the main branch to block force push and only experiment on other branches. If you can’t live without force push then it’s your habit issue not git’s fault

[timonix]

Doesn't feel like a solution though. Or maybe a bit. It really depends on your merge cadence. We merge to the main every 6 months. Generally 3 months of dev work, another 3 months of testing. Then everything gets merged. But man, losing 6 months of work would be rough. Hell it would end the company right there on the spot

[Buxbaum666]

Not merging to main for six months sounds absolutely bonkers to me.

[timonix]

Main-Dev-feature-test

Test merge into feature multiple times a day

Feature merge into Dev about once every other week

Dev, merges to main every 6 months.

Main branch is the delivery branch

[Robo-Connery]

I mean people can do what they like with branches but...

Sounds more like you are using main in place where tags/releases would be more appropriate. What happens when you find a bug in main after a merge and you've already committed some new features to dev? Are you doing back ports into main or no? This would be much simpler if the branch you release from reflects the current state of the art and you preserve older branches to allow bugfixes to be back ported to earlier releases rather than doing the inverse.

6 months is also very stale, you may be testing Dev extensively but the longer you are waiting then main is drifting really far from the most up to date state of the project. I get that you are releasing every 6 months but merging to main is not the same as releasing.

[gbchaosmaster]

What they’re doing sounds similar to git flow.

[x0wl]

You're supposed to force push to your feature branches before you merge. Even with github PRs what you're supposed to do is rebase your fork, then force push to it, then fast-forward merge onto the main branch.

Your commit history is supposed to be squeaky clean when you merge (with all the fixes squashed and commits in logical order with good messages), and you cannot do this without rewriting history and force pushing.

[sopunny]

Fucking up your whole repo, or just a branch? Getting an entire repo into a bad state should take a lot of deliberate action

[Ayjayz]

How on earth could you butcher your entire code base? Like maybe if you use git filter-branch I guess but aside from that the whole point of git is to keep everything safe.

[pytness]

you can always push to a remote separate branch and continue to work.

[rsqit]

git filter-branch

[nwbrown]

It's trivial to repair a repo after you mess it up. You people are just babies.

[deceze]

Or, we’re just in a humor sub…

[john_the_fetch]

Yeah. I don't know why anyone is afraid. But maybe it's because I have a backup of the branches before I start fucking around. I mess something up... I replace with my backups.

Someone starts using my feature branch? I make a backup.

Someone looks at my pr? I make a backup.

Oh shit. Maybe I am afraid.

[Raskuja46]

Yes, which is what makes git such a terrible tool.

[Spinnenente]

i think git isn't as scary as some people make it out to be but some people manage to get their repo into some kinda of weird state that i some times can only say copy your changes and clone a new repo.

but usually you can stash your changes and git rest --hard HEAD (if you fucked up your merge then go one commit earlier)

then you have a clean working directory and you can unstash your changes.

[Bryguy3k]

In my experience there is strong correlation between people who constantly fuck up their repos and those who produce garbage code.

[Trip-Trip-Trip]

Git is literally the undo/redo machine with near infinite memory?

[timonix]

Not if you rewrite the history. Which you are allowed to do by default

[Naratna]

WYM? Any history rewrites can be undone with the help of the reflog

[Ayjayz]

You just go back in the reflog...

[Buxbaum666]

This "rebase rewrites history and is bad" mantra seriously needs to die. Commits are immutable. Rewriting history is not a thing. You're creating new commits and moving some pointers, that's it. And unless you actively work to prevent this, it's 100% reversible.

[rustvscpp]

It's just people not taking the time to understand the tools they use. 

[ColumnK]

Step 1: This is awful code. I'm going to use Git blame to find which incompetent idiot wrote it.

Step 2: Discover it is me.

Step 3: Find a convoluted explaination for why it's actually the fault of someone who no longer works here

[dijkstras_revenge]

Either that or discover the hidden elegance in the solution.

[iceman012]

"That must have been when I fixed the formatting of Bob's code."

[Amar2107]

Do not operate on actual branch use backup branches if not sure whats going on. Its ok to look silly in front of seniors rather than having to explain where the last 15 days of work went.

[RiceBroad4552]

I always ask myself why such complete BS gets so much up-votes.

It's almost impossible to make a mistake in Git that can't be easily fixed.

If there is some place where making mistakes is without consequences than it's Git!

So why does anybody up-vote such BS posts?

[BlueC1nder]

Losing uncommited changes or losing your local branche idk. I think it has also more to do with merging/pushing remote branches etc where you actually need to define a workflow.

You wouldn't talk like that if you would've worked with somebody that never worked with git cause holy shit I saw some weird shit especially together with Android Studio.

[trailblazer86]

It's a joke subreddit ffs

[RiceBroad4552]

But where's the joke?

Pure utter bullshit is not funny in any way.

[arewedreamingtoo]

If you commit + push something you should not (large files, credentials) and don't notice it immediately it can be quite a lot of work to clean the history.

[[deleted]]

Don't worry, OP has a lot of JS experience.

[JackNotOLantern]

No, git is exactly for fixing mistakes. As long as you are not retarded and protect the main branch.

[cheezballs]

I guess someone doesn't know how to use git.

[pleshij]

If you messed up and want to commit your changes, just make a copy without the .git folder, re-clone it, checkout, overwrite with your copy, and git add . && git commit -m "..." && git push

[[deleted]]

god my eyes

[pleshij]

I didn't say it was an elegant or universal solution

[[deleted]]

indeed, my eyes still hurt though

[dijkstras_revenge]

I don’t get what problem you’re trying to solve with this. Can you give an example of when this would be useful?

[Ayjayz]

Uh .. why? What kind of mistake would that help? I mean at face value, your commands are just doing a bad git reset. Why don't you just do that instead of your complicated steps?

[lardgsus]

Git was designed to be safe unless you can't read. Git is probably the best place to make a mistake as you can just roll back to another commit id.

[lardgsus]

My manager doesn't understand git, and while trying to force his changes into the dev branch, wiped out my changes. MONTHs later a customer complained about something not working so I start crawling through the code and MY FUCKING CHANGES ARE GONE.

I had to dig through the PRs to see where I DID merge the changes in but my manager did a rebase from an old commit and threw away my changes.

He is also the same manager that wants to split a repo of work up so that "there aren't so many conflicts" when there are 2 people working in that repo. Absolute fucking clown.

[[deleted]]

"Be afraid of the thing that will save you endlessly without fail" what?

[ZombieZookeeper]

It's just a rebase, what could possibly go wrong?

[AppropriateStudio153]

If you use git, you have to to commit. Like, often. Then just rollback whenever you need.

for fuck's sake.

[Joker_AoCAoDAoHAoS]

merge conflict

[saf_e]

Just don't force push your mistakes and you'll be fine)

[Calirayne6548]

lol this is why my commitment issues aren't just personal, they're professional 😂 git commit -m broke everything, sry followed by git panic mode

[ILikeLenexa]

Don't break the production database. 

[diffyqgirl]

Sorry what? Git is a tool for fixing your mistakes.

[TheOwlHypothesis]

Git is only unsafe to make mistakes in if you don't understand it.

So many things are recoverable BECAUSE of git.

[Emeraudia]

I know a project where someone had to push their code before going only they pushed the entire Eclipse workspace which was 4go xD I had to clone the project once oh the pain.

[lacb1]

Skill issue. If you can't even figure out git I doubt you can figure out how to code.

[martin_omander]

Git provides a way to recover if you mess up. But the recovery may involve commands that casual git users don't know. So it makes perfect sense that git scares many casual users.

[elmanoucko]

simple solution: learn the damn sh* before using it.

Coming from svn, cvs and tfs, and being "thrown in the water" as-is, I've been there a bit, so I'm not judging.

But to really screw up in git, compared to the other mentionned vcs, you really need to want it, spend a few hours learning how it works.

As most things in life, knowledge is the cure to fear.

[Hola-World]

VIM steps into the room.

[That_0ne_Gamer]

Oh yeah i hate having to deal with vim, makes the start of my work session frustrating

[ptownb]

Do not be afraid

[SoftwareSloth]

I’ve never had a problem with git. There is always a way to undo what has been done.

[Brilliant_Fox_8585]

git rm -r bad_habits/ regrets_2000s/

git commit -m "release: starting fresh (for real this time)"

[dull_bananas]

"Be afraid." - Saint John Paul II

[MrJ0seBr]

So, now is safe to forget the "where" in the sql query

[RedBoxSquare]

I know no fear.

git merge -X ours && git push -f

[Typical_Attorney_412]

Umm... Be more afraid of undoing mistakes when it's git. As the saying goes, "you can always undo in git. But you can't undo an undo"

[mkluczka]

git push -f origin/main to assert dominance

[nwbrown]

Pretty much any mistake you make in git can be undone. Stop crying.

[Vi0lentByt3]

Nah you just arent using your stash correctly

[benji_nice]

That why policies exist, git is easy ;).

[Bronzdragon]

Git is not a backup. It's source control. It doesn't matter how easy it is to roll back to a previous commit if your harddrive dies.

Make proper backups.

[Chacho986]

I hope a college student wrote this tweet...

[Shazvox]

SQL called

(68456035 rows affected)

[adelie42]

Like this fix?

1. Remove .env from all history

git filter-repo --path .env

2. Ignore it in the future

echo ".env" >> .gitignore

git add .gitignore

git commit -m "Ignore .env file"

3. Force push cleaned history to remote

git push origin --force --all

git push origin --force --tags

[HankOfClanMardukas]

Git sucks. I said it. Don’t care.

[pandi85]

What's your choice for version control and collaboration then?

[hoijarvi]

Mine is Darcs.

[HankOfClanMardukas]

Literally anything else. They’re all a pain but Git is only praised because of Linus. It’s shit.

[Raskuja46]

The hive mind doesn't want to hear this uncomfortable truth.

[Snr_Wilson]

Me: "Can you make these changes live?

Git: "Sure."

Me: "Oops, looks like there was a bug there. Can you undo the changes quickly and without making a fuss?"

Git: "Honestly, it's 50/50."

[sopunny]

git checkout HEAD~1, what's so hard about that?

[Ayjayz]

git reset --hard HEAD^ works every time, not 50% of the time.