Maybe I'm just a wizard, or I don't know what y'all are talking about, but rebases aren't special. If you use git reflog it just tells you where you used to be before the rebase. You don't have to fix anything, git is append only. See where the rebase started in reflog, it'll say rebase in the log line, then git reset --hard THAT_HASH

Pushing without fetching should be an error. So either they got the error, didn't think about it, and then force pushed, or someone taught them to just always force push. In either case the problem is the force part, the tool is built to prevent this by default.

Continuing after merge should be pretty easy? I'd assume rebase just does it? Unless the merge was a squash merge or rebase merge. Then yeah, slightly annoying, but still mostly git rebase -i and then delete lines look like they were already merged?

Is it ok to continue on a branch if you also merge back main into it? Like, branch gets merged into main on remote, local main pull, local merge main into local branch, push branch?

Specifically screwing up rebase. It is recoverable, but very annoying.

WDYM? Typically git rebase --abort will "just work". If you have specifically done something really wrong, just look into git reflog and then git reset --hard to whatever commit you were before the rebase.

Pushing your commit without fetching

Git won't allow you to do that if you set up your server properly. It will force you to pull first. I have [pull] rebase = true in my settings so that it always rebases my commits instead of merging them, which makes for much cleaner history.

Continuing on a branch even after it was merged.

This generally shouldn't be a problem, you can just rebase the branch afterwards and it will be fine (the common commits will typically just be dropped).

I’ll get chastised, but when I screw up a rebase I create a backup branch and then have an LLM do the fixing…

I’m not proud of it, but I’m a lazy man who doesn’t want to resolve the same conflict 32 times.

o7

Delete? Never.

mv git_repo git_repo.bad

Well, if you did commit it, but just hadn't pushed it yet, and then somehow lost that commit, then git reflog would be the tool for it.
Without a commit, sometimes you may have already staged some changes for an upcoming commit and can roll back to that.

But if neither of those are the case, then I can't really imagine how Git should help you there. You haven't told Git about those changes yet, so it's out of scope.
At that point, you better hope your editor's undo history goes back far enough...

Rebase the comment chain and force push!

Power users rebase with squashes and fixups multiple times a day. Especially if the job’s integration process isn’t enforcing long living branches.

Reflog is useful then, because you literally rewrite history every rebase.

It’s not often, but a bad git reset, or a messed up rebase of that branch that’s 8 months old that you’ve picked up again.

I only use it when I've royally messed up and the commit I need to get back is no longer referenced anywhere. Accidentally deleted a branch, finished a merge or rebase before realizing I messed up, that kind of thing, just use the reflog to find it again, get a branch pointing to it, then try again.

git log will only show you commits in your history. If you're only ever working forwards, this will contain all the stuff you'll ever need.

But if you're rewriting history, like with a rebase or squash or something, or you're deleting branches without merging them, then you can run into a situation where the official history of your branch doesn't contain some of the commits that used to exist, and in fact still exist but are unlinked from anywhere. So reflog is the log of where you've been, even if where you've been isn't in the official history anymore, so you can find your way back to previous states even if there isn't otherwise a name for them.

If all you care about is your current history, git can use the dates of commits just fine to see where you were on Thursday without needing the reflog.

When I'm not using git reflog, I'm not making big enough git screw ups.

It's mostly for undoing a rebase or merge you're not happy with.

I really only need it when I done fucked up.

Our company "architects" decided we needed 80% coverage minimum. On a mostly .Net 4.8 codebase. Hundreds of programs used in prod, with barely any tests in sight.
It's a fucking nightmare.

Why would you care about code coverage requirements on a branch that is currently in development? My work in progress commits might not build because they don't even compile, let alone have passing tests. The only time I care about the build passing and meeting requirements is when I'm ready to create the pull request.

Also code coverage is a useless metric, but that's a different story.

3 is not related to using git in any way. I'm not really sure what you mean in 4. I didn't mean making a lot of changes, I meant that you should not wait with committing until you have a finished feature / fix / whatever. Commit after each refactor, commit after adding a new testable unit. It's always better to have more checkpoints. If your team does code review, they will appreciate atomic commits too.

I mean, by definition, it does. It just involves parsing through the git log and a bunch of unintuitive, archaic commands.

idk but my dotfiles do:

alias undo="git reset --soft HEAD~1"

Anything you can do in Jujitsu you can do in git.. The big difference is a paradime change:

-instead of a working directory that has pending changes you need to add than commit, all changes are in a commit that is lacking metadata.

The system has better "editing" of local history to set that meta data. But once you push to a shared repo you run the usual risks of force pushing.

I'm not sold, rather git not do anything until asked and just run git status constantly but I don't have first hand experience.. I would theory it would be more likely to add a file you didn't mean to.. Unlike those who use windows guis for git and forget to add new files.

Went to tech elevator boot camp, was a decent experience even if I don't find myself doing exactly what I was expecting to do. Life is that way though.

Anyways, my first week I fucked some git stuff up so bad I became the go to guy when anyone had any git issues because I had to learn so much to undo my egregious error. I don't remember now exactly what it was but it took some serious git magic to sort.

Just saying that point 1 is very true. And yeah don't make mistakes in git.

Like accidentally committing multi-GB files and years down some poor mf (me in this case) has to figure out how to clear the files from history because the server is running out of space.

Short of manually deleting .git you can always find any commit, you can walk backwards through your reference lof if it comes to it, the only real risk is throwing out unstaged changes.

Hmm... I am using git for maybe 15 years... Maybe I'm just too familiar with it... and have forgotten my initial struggles... To me using git comes natural... And I normally pay a lot of attention to every single commit, since I started working on patches for the Linux kernel. I often rebase and reorder commits many times, before pushing/merging them into a branch where continuity matters.

Sure, I sometimes messed up with git, but a git reset , checkout, rebase or filter-branch (In the extreme cases) normally fixes it, but real issues are very rare. And I use git a lot... But only the CLI, maybe people have issues with GUIs?

Think of it like your browser history but for Git. It’s a list of the SHAs related to your recent operations.

And because Git is a content-addressable data store, a SHA is basically like a URL. Even if a branch no longer exists, if you know the SHA it pointed to then you can still check out the exact contents of that branch. The reflog helps you find that.