Well well well.

o7

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.

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.

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.

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, it is only because I a'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.

Because the git history will still keep it completely to be able to restore it once you go to a commit in which it wasn't deleted.

And you cannot tell git to completely forget about it as that requires a rewrite of history and this changes all commit hashes which are touched (and any future ones).

They most likely did in a later commit. However the commit adding it can not be removed as OP said. So in order for git to be able to work properly the file is still in the repository in case someone wants to check out a commit where it still was present.

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.

Hmm, I'm less afraid of force push. It does what it says on the tin. If I pushed a fuck-uo to remote and a reset is the simplest way out, you can bet I'm force-pushing that reset.

Force pushing is necessary when using rebases, and rebases are an essential tool, so you should not be afraid to force push under normal circumstances.

It's sweat