git status
git log
git reflog
git reset
git merge
git cherry-pick
git rebase
I strongly disagree with this one.
Git is one of those constants in our developer-live that is bound to stay for a long time. Probably longer than most other tech/tool that most of us use and learn on a daily basis.
The fundamentals of git aren't that complicated, the datamodel isn't any more complex than what you get taught in an introductory datastructure course. And once you understood it, you can leverage it to create an actually readable and usable commit history instead of the unreadable mess that your average enterprise project is. In my opinion, it's well-worth the trouble of taking an afternoon to understand git beyond the commands you've mentioned.
Agreed
> the datamodel isn't any more complex than what you get taught in an introductory datastructure course.
Also true. The problem is that people love to shoot themselves in the foot by overcomplicating normal use of git That's all fine, until you try to push to someone else's repo and things start to crack.
So as a person who had to maintain a fairly large project, and had to fix a lot of madness from developers I nowadays suggest everyone keep their git adventures to a minimum.
You can just git add without commit. The changes will be saved to index and live till git decides to GC its files (so few months). Extracting those might be PITA (as requires playing with more arcane git commands) but you can't really lose data
git stash is also lifesaver if you need to quickly jump to branch to do something else
Lastly there is "git commit --amend" way of just incrementally changing the current commit but that requires some self-discipline (or hooks preventing your from) to not amend pushed commit and then having to fix that.
... although these days rebase is mostly handled on the server. By the time your PR is reviewed its already behind main so server side needs to rebase it anyway before merge can be done.
If you do rebase to squash commits, most projects prefer you didn't
I've been using rebase to fix bugs in earlier commits (on a feature brannch that hasn't yet been merged into main) so that you don't end up with broken commits in the history.
I've also been using filter-branch to retroactively apply autoformatting to all commits in the branch.
Alternatively you can squash the merges before pushing but this still requires rebasing.
Or perhaps I bothered to read the documentation and I know more than you.
But that list of commands isn't really far off for daily/weekly use, I'd only use stash and rebase over that most of the time
Yuuup. For anyone reading this who thinks of Git as a bunch of magic commands, go read all of gittutorial, gittutorial-2 and gitcore-tutorial. That last one is particularly important to read & follow along with. It gives you Git's underlying data model, which makes it much easier to reason about what the UI-level commands are doing.
I even used that knowledge once to recover my boss's lost data at a previous job! He had git-added a new file, and then lost it (git-clean/git-reset/something) before committing. I knew from reading that tutorial that git-add is sufficient to add it to git's object store, so we managed to find the right object using file timestamps and git-cat-file to retrieve it.
https://git-scm.com/docs/gittutorial
-> ᛯ date >> asd
[23:57:10] ^ [/tmp/a] {master *}
-> ᛯ git stash
Saved working directory and index state WIP on master: bf5a0f8 fix
[23:57:13] ^ [/tmp/a] {master $}
-> ᛯ git pop
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: asd
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (4f46bc00a3d6032c2726f04540a44656090e05ca)
[23:57:16] ^ [/tmp/a] {master *}
-> ᛯ
If it's not so trivial, create a local temp branch so you can cherry-pick it or merge it back in later, or maybe convert your temp branch into a more enduring one.
Stashes are pseudo-commits with no branch context, and are more of a conceptual burden then they're worth.
do whatever you need
git stash pop
done
> Stashes are pseudo-commits with no branch context, and are more of a conceptual burden then they're worth.
They are literally just commits like everything else. They just land in refs/stash, where branches/tags live.
Man the shit people say about how git works while not knowing how git works...
It's essentially a temporary branch with some syntactic sugar to manage
You can even just convert it to normal branch
git branch cake stash@{0}And your overall tone was uncalled-for. Cheers.
git diff
git log
git blame
git bisect
A major advantage of version control is being able to navigate history.
This, at least in my opinion, is easier to use than the -p flag for git add or git reset, and provides much finer grained control over staging and unstaging compared to those commands.
But how about logs you may ask. Well, that's what we have tig for: