Do you know Git? Of course you do! Today, I’ve got a few of my favorite Git commands for you. When I was a junior developer, my tech lead...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for the mention and great detail on using Git :D
Haha never enough of Git 🙂
Im looking forward to the followup about git work-trees. With agentic now the mainstay, work-trees are becoming increasingly more invaluable
Haha, don’t tempt me! 😂
What/Co? Use something like
LanguageToolA best how to use git short document!
Ooooh, thank you so much! ☺️ Now I can just send this article to juniors instead of explaining all of this on a call every time. 😂
This is exactly how I started writing! So I didn't have to explain myself multiple times. 😂 Great article!
Thank you so much! 😄 Haha, I also wrote a few articles specifically for my juniors. But then somehow this whole writing thing took a rather unexpected turn. 😂
Sounds like we did much of the same thing!! It is a lot of fun. 🤩
Thats why is working so well
Git commands are basic, but really important for every developer.
I think this will be a valuable article for many people! 😸
I use aliases in my
.zshrc, for example,gc="git commit -S".It makes my daily Git workflow a little bit faster.
Do you have any similar tricks or customizations in your setup? I'm curious! 😸
Haha, you know what? I actually don’t! 😄 I know about Git aliases, but I prefer typing the commands manually so I don’t forget them, partly because then I can recite them from memory when explaining Git to juniors. 😂
But we do have a very funny Polish repo with Git aliases called “git kurwa” (“kurwa” is a Polish swear word 😅). So apparently we’ve found a very Polish solution to Git frustration. 😂
Actually, I don’t remember all the Git commands either. 😹
I only make aliases for the ones I use all the time.
And I had no idea git kurwa existed! Thanks for introducing me!
github.com/jakubnabrdalik/gitkurwa
"Git, kurwa!" 😹
Hahaha, yes! 😂 It was super popular in Poland some time ago. I think pretty much every Polish developer had come across “Git, kurwa!” at some point.
O pier*...... thats freakin' good......
Must tell it to my higher-ups........ haha..... we end up logging in to our internal VCSv one day to see full 4 pages of this kind of names..... woulod be hillarious........
zsh? Jesus, man, update to sth more modern.........zshis good, but there are shells that are more frequently updated, thus better (security-wise, etc)nice. this is super detailed so i will keep tab open and read it in evening
does nobody uses git fetch --prune (or git fetch -p) which fetch and also removes remote-tracking refs for branches that no longer exist on the remote.. i'm really curious cuz I often use it.
Thanks, Anmol! This is a great addition to the list too. I actually use git fetch --prune all the time, but somehow it didn't even occur to me to include it here. 😄
I use
prunealmost daily; thats great command.Hi Sylwia! 😂
git reflogis basically Git’s emergency contact. You hope you never need it, but the moment you accidentally nuke two days of work, suddenly it’s your best friend.Now I’m curious: which Git command has saved you from the biggest disaster so far? 😄
Haha, that’s a good question! 😄 I’d say
git reverthas definitely saved me from the biggest disasters.git reflogcan save your work, sure, butgit revertcan save production. 😂Your article deserves to be shared with anyone who uses Git… and should be declared a public service. I can't even begin to tell you how many mistakes I would have avoided if you'd had me read it when I first started using Git!
Thank you so much, Pascal! Coming from you, that’s truly an honor! 😊
The merge vs rebase section is the one that finally made things click for me, I'd been using both without really understanding why I was choosing one over the other. The diagram of commits being replayed with new hashes is such a cleaner way to explain why rebasing shared history is risky.
git stash is probably the one I reach for most often in my day to day, that moment where you're halfway through something and a bug report lands and you just need to put everything down cleanly without committing a mess.
One I'd add at this level: git log --oneline --graph --all — not a command that does anything dramatic, but seeing the branch structure visually in the terminal helped me understand what merge and rebase were actually doing to my history way faster than any explanation did.
Thanks so much for the comment! 😄 And yes, --graph is great!
I have to admit that even though I type probably 90% of my Git commands manually, I still like using SourceTree, pretty much exclusively to look at the branch and commit tree. 😂 I’m definitely a visual learner, so being able to actually see the history makes everything much easier for me.
That makes total sense, there's something about seeing the actual branch graph visually that just lands differently than reading a text description of the same thing. I end up using the Source Control panel in Xcode in a similar way, mostly for the visual history rather than because typing the commands is hard. Sometimes you just need to see the shape of what happened rather than parse it from text.
git refloghas rescued me from more than one moment of "well, that was unfortunate." 😂But your
git revertsection jumped out at me for a completely different reason. I've been writing a lot lately about durable AI memory and decision history, and Git keeps turning out to be a surprisingly good mental model.A revert doesn't pretend the original commit never happened. It preserves the original event and adds a new event saying, effectively, "this no longer governs the current state." That's very close to the distinction I've been working through between correction, supersession, and invalidation in AI memory.
Current state alone says what exists now. History tells you how it became that way.
Apparently the answer to half of my AI architecture questions continues to be: we solved a version of this problem decades ago with Git. 😄
Oh wow, that’s actually such a great observation! And yes, the more I work with AI agents, the more I feel like we keep rediscovering problems from good old software engineering. 😂
What makes it even more interesting is that in traditional software development, we’ve already solved many versions of these problems over the years. With agents, we’re suddenly looking at them from a new angle and still have so much room to figure out how those old lessons translate.
Great list! Though I can’t imagine
git merge,rebase, or evenstashbeing unknown to any developer on God's green earth. Those are basically the bread and butter of Git.Thanks! And that’s actually a very fair objection, one I’m happy to defend, because I do have a reason for each of those. 😄
First, junior developers often know
merge, but either haven’t heard much aboutrebase, or they’ve heard of it without really understanding how it works or how it differs from merging. That’s exactly why I devoted quite a bit of space to explaining the difference.Funny enough, recently even a senior developer on my team casually referred to “rebasing the branch,” and I was like, “But… we merged it there, didn’t we?”. Which actually mattered quite a lot in that particular situation. His answer was basically, “Yeah, I was just using it as shorthand.” I hope he wasn’t bluffing. 😂 But either way, imagine the confusion that kind of wording can create for juniors!
As for
stash, I also really hope everyone knows the basic command. 😄 That section was more about going beyond plaingit stashand showing things likestash list,apply, andpop.Alot of the ones that we rarely use are always the ones that end up saving our assess all the time. you think reflog might be useless? nah it just means you haven't screwed up enough lmao
when i started learning version control, i didnt think there was ever a UI and my default has always been through the CLI and i've always thought it was the default way to do version control for every developer... for large, complex changes, i rely on the Gitlens extensions.
until last year, i had a new member joining my team and he was using this blue UI thing i forgot the name of, i asked him what it was and he said it's just git commands with UI and i was like whatttt, they have that? lmao but hey, it gets the job done!
Hahaha, I wonder if that blue UI thing was SourceTree? 😄 I absolutely love SourceTree and I’m kind of addicted to it. 😂
To be clear, I run probably 99% of my Git commands from the CLI (although I’ll occasionally create a local branch from the GUI when I’m feeling lazy 😅). But I’m a very visual person, and SourceTree draws the branch and commit tree so beautifully that I can immediately see what’s going on in the project.
Yes!!! it was SourceTree!!! I've also thought about trying it out but then again, maybe I'm just lazy but I'm just not ready to try any new GUI for anything at the moment haha
Haha, I think if you don’t feel like you need it, there’s really no reason to force yourself to try it. 😄
Funny enough, SourceTree was actually introduced to me by a backend developer who also did pretty much everything from the CLI. He just liked having a visual representation of the branch tree too. 😂 So apparently there’s a whole secret society of “CLI for commands, GUI for looking at pretty trees” developers.
After 15 years of dealing with git, I learned
push --force-with-lease, wowHaha, that’s exactly the beauty of these lists! 😄 You can be coding for 15 years, know 90% of the stuff on the list, and there’s still that one command that makes you go, “Wait, WHAT?!” 😂
git reflog deserves more attention than it usually gets. Most Git commands are about changing the state of your repository, while reflog gives you a way to understand how you got there when something goes wrong. That makes it less of a daily workflow command and more of a recovery tool—and probably one of the best safety nets to learn before you actually need it.
Good framing, but worth to remember reflog lives inside .git, so it saves you only from yourself. When my SSD died the reflog died in same second, and what actually brought the thing back was a 13MB snapshot sitting on another machine. Local safety net and off machine copy are two different things, and most people have only first one.
That’s a very good point, thanks for the clarification! Of course, there are plenty of situations where reflog won’t save you: reflog entries expire (typically after 90 days for reachable entries, as I remember), the repository itself might be corrupted or lost, or the changes simply might never have been committed in the first place.
There are lots of nuances here, but if the repo is still alive and you’ve accidentally nuked something, it’s always worth trying your luck with git reflog. 😄
Yes, and expiry has funny detail in it. The 90 days is for reachable entries, unreachable ones go after 30 by default, and unreachable is exactly what you come to reflog for. So real window is shorter than people think, and it runs quietly while you postpone looking.
Exactly! Although my coworkers and I always joked that you usually have more than enough time anyway, because most of the time you reach for reflog about a minute after realizing you’ve just deleted your own work. 😂
Exactly! Especially when you accidentally click the wrong thing somewhere, or when a rebase goes very, very wrong. 😂 That’s when git reflog suddenly becomes your best friend.
Love this. I am one of those weird people that hate git clis, so i use this tool from the terminal. I also don't like using aliases so i am sure what i type and call.
This is such a useful reminder on how some of these commands work, thanks Sylwia!
Thanks so much! 😄 I’m the same! I type everything out, no aliases. Although I have to admit I do use SourceTree. I don’t actually click anything there, I just like looking at the branch tree. 😂
You're making me feel old! When I was a junior, Git didn't even exist. I started back in the day with Visual SourceSafe 6.0, then moved to SVN (good old TortoiseSVN), until Microsoft eventually pushed everyone to TFS.
I only really made the jump to Git around 2019 when I joined Bloomberg, and only switched my personal projects to it about two years ago after sticking with the MS ecosystem for ages.
Great list of commands, by the way. My favorite: cherry-pick!
Thank you so much, Sandro! And yes, that’s true, especially with older projects, SVN managed to stick around for years and years.
I’ve actually worked with Git since the very beginning of my career, but here’s the plot twist: I used TortoiseGit. 😂 As far as I remember, it was basically the Git-enabled cousin of TortoiseSVN. So apparently our Git histories crossed paths after all! 😄
I never memorize git commands for stuff like this. I only know commit, push, stash, branch, etc. I ask AI how to do this or that whenever I need to and copy the output into my terminal. But I remember screwing up everything multiple times. I remember taking several minutes to fix the last commit, while, as you said, I could just run
git commit --amend --no-edit. No idea why the AI made me open the editor every single time, and that, for some reason, opens nano, which takes me even more prompts to just figure out how to save it. Then I ask it to update it so that it opens VS Code or something, and I lose even more time, and I never do it successfully. This was really helpful for me. Really worth it. There is a reason why so many people (including me) saved it. This must have taken a lot of time to make. Wonderful work!Thank you so much! This is exactly what I wanted this article to be. 😊 I could have included dozens of Git commands, but these are specifically the ones I’ve found genuinely useful in real situations, so the list was very deliberately selected. And as you’ve seen yourself, an LLM can definitely help, but sometimes it takes you on quite a detour to get there. 😂
Great distinction between learning Git basics and learning the commands that actually make day-to-day development easier. The best Git lessons usually come from experienced developers sharing the small workflows and commands they rely on repeatedly. Looking forward to the rest of the list.
Thank you so much! And yes, exactly! In the beginning, you can absolutely survive without these commands, but they quickly become pretty essential if you don’t want to lose your mind working with Git every day. 😂
Commenting from the wrong side of this list: I'm a marketer who only touches Git because Claude Code keeps telling me to. Your reflog caveat is the one that got me. Vibe coding means hours of generated changes piling up while I never think to commit, so when I finally destroy something there's nothing for reflog to find. Committing often matters more when you didn't write the code yourself, not less.
Oh, exactly! 😂 And I think that’s one of those Git truths you learn very quickly once you start vibe coding: commit often, or learn the hard way. 😄
git worktreeis the one I'd add to this list — I resisted it for years becausegit stash+ branch hopping felt "good enough", then I tried keeping three feature branches checked out simultaneously in separate directories and my context-switch cost basically went to zero. No more stashing half-finished work just to hotfix main.The underrated combo:
git worktree add ../hotfix mainfor emergencies, thengit worktree removewhen done — your IDE never loses its index of your main working tree.Curious how many people here actually use worktrees daily vs. still doing the stash-dance?
Thanks so much! And yes, absolutely, git worktree is such a great addition to this list.
git reflogis probably the one that deserves more attention. It’s easy to forget about until you accidentally reset or rebase something and suddenly think your work is gone. I also like the distinction betweenresetandrevert—understanding when to rewrite local history versus creating a new commit to undo a change makes a huge difference when working with shared branches. These are the kinds of commands that become much more valuable once you’ve actually had to recover from a Git mistake.Exactly! And in those moments when something goes wrong and you need to fix it quickly, it really pays to already know what your options are instead of desperately googling Git commands while everything is on fire.
The
git rebase -i+git reflogcombo saved me last week after I force-pushed over a teammate's commit — reflog found the lost SHA in about 10 seconds. One command I'd add to this list:git log -S<string>(pickaxe search) — it finds the commit that introduced or removed a specific string, which is how I tracked down who silently dropped an env var check three months ago. Grepping history by diff content beats reading 500 commit subjects.Do you find interactive rebase actually safe to teach juniors, or do you steer them toward
git merge --no-ffuntil they've internalized reflog recovery first?Oh, that git log -S tip is great! 😄 I’d probably have reached for git blame and started digging from there, so I’m definitely keeping this one in mind!
As for interactive rebase, juniors usually come in already knowing how to work with merges, so I tend to introduce rebase fairly early. Of course, how quickly they actually start using it confidently varies. 😅 git commit --amend, on the other hand, they pick up almost immediately. 😂
Although I guess I should be speaking in the past tense here, I haven’t had many juniors around lately. :(
you asked for more at this level so here is the one that fixes the exact pain in your rebase section, resolve a conflict, continue, get it again in the next commit, and again.
git config rerere.enabled true
rerere is reuse recorded resolution. it remembers how you resolved a conflict and replays it when the same one appears. on a long rebase that is resolving something once instead of five times.
CONFLICT (content): Merge conflict in f.txt
Staged 'f.txt' using previous resolution.
three things i only found by testing it, and they change how you should use it.
it records on completion, not on git add. resolve, then abort, and it learned nothing. the next attempt conflicts identically. this bit me twice before i understood it.
it matches on the conflict text, not on the file. i taught it a resolution in one.txt, then created the same conflicting hunk in a completely different file two.txt on a different branch, and it replayed the one.txt answer into two.txt. that is usually what you want on a rebase and it is not always what you want. if the right answer differs between those two places, it will quietly give you the first one.
which is why i would not turn on rerere.autoupdate, even though every tutorial pairs them. i checked the index in both modes:
autoupdate off -> UU two.txt still conflicted, you must read it and git add
autoupdate on -> M two.txt fully staged, nothing asks you to look
autoupdate is exactly the checkpoint that catches a replay you did not want. leave it off and rerere still writes the resolution into the file for you, you just have to look at it before adding. if it did get it wrong, git rerere forget drops what it learned, then git checkout -m brings the conflict markers back.
second one, a small upgrade to your section 5 since fixup is already there:
git commit --fixup abc1234
git rebase -i --autosquash abc1234~1
first marks it, second reorders and squashes it, and the todo list opens already correct.
two sharp edges on that one too. bare git rebase -i --autosquash with no range fails outright on a branch with no upstream, so you need the base. and if the range does not reach far enough back to include the target, it does not warn you, it prints "Successfully rebased and updated" and leaves the fixup! commit sitting in your history. worth a quick git log --oneline | grep fixup! afterwards.
and both of these rewrite history, so your own rule from the rebase section applies to them unchanged.
great article, the merge vs rebase diagrams are the clearest version of that i have seen in a while.
Wow, thank you so much for this comment and all the examples! There’s a lot of genuinely useful stuff here. Actually, have you thought about turning it into a full post? I’d definitely read it!
git clean -Xfd(but watch out for ignored secrets)Hahaha, exactly! 😂 That’s why I’d be a little scared to teach this one to juniors, they’d keep coming back to me asking for new keys.
Good resource for learning and revision. Git is ever-evolving, and we have to refresh and relearn everytime. Resource control has always been a more essential skill to learn and master than coding in a real-time work environment in my opinion
Exactly! Even if you can now ask AI about anything, it's worth to have at least mental model of what we want to do . Thanks for the comment ☺️
Git cherry-pick is a lifesaver when you need to integrate specific commits from one branch into another without merging the entire branch. It's saved me from countless headaches.
Absolutely! 😄 I think git cherry-pick makes an appearance in my workflow at least once every couple of weeks. 😂
This article is a practical guide for people who already know the basics of Git (add, commit, push, pull) and want to learn useful commands for their day-to-day work. Good work 😀
Thanks, Tomasz! That was exactly the goal. Useful, practical tips you can actually use in your day-to-day work, no Git wizardry required. 😁
Great list! I was familiar with most of these, but git reflog was completely new to me.
Haha, I’m glad I’m spreading the word about git reflog! 😄
Great git article you have here. I wish I came across it before an interview yesterday 😂
Hahaha, that’s always how it goes! 😂 But hey, at least you’ll know it all before the next interview! 😄
good😀
Thanks 😊
Great rundown,The diagram made it click instantly. Bookmarking this one, thanks for writing it! 🙌
Thanks! Glad it was helpful 😊
Great article, Sylwia. I actually printed out the full Git structure from someone I follow on LinkedIn. If they end up sharing all their Git push details, I’ll send it to you as a DM on LinkedIn.
Oh, thanks a lot, Ben!!! Sounds totally interesting!
No problem, Sylwia :)
Thanks! The Git Command is clear and easy to follow!
Thanks a million! 😊
Nice overview! I'm using some of these (especially
git stash) but not all of them ...Same here! 😄 I use
git stashall the time, while some of the others, likereflog, maybe once a year. But when you need them, you really need them. 😂No matter how long you work with Git, it's always super useful to catch up on the basics.
Thanks for the brush-off.
Exactly! And as quite a few people mentioned in the comments, even if they already knew 9 out of 10 of these, there was still that one command that was new to them. That’s the beauty of these little refreshers!
I always use the UI of IDE.
That works for most everyday Git operations! 😄 But IDE UIs often don’t expose everything Git can do. For example,
reflogis one of those things you’ll often have to reach for the command line for.Merge vs rebase - I definitely used to mix those up! The history visualization difference finally clicked for me when I saw it drawn out.
So glad to hear that! Drawing it out really helped me understand the difference back in the day too. And to think that just a few comments above I had to explain why I included merge vs rebase in this list in the first place. 😂
Pretty Cool flow , I had a revision :)
Thanks! 😊 Exactly, even if you already know all of them, a quick revision can be helpful!
I am bookmarking it for later reading. Thanks for sharing!
Aaaah thanks 😊
console.log("WTF").... 🤣🤣
probably the most useful day to day command... LOL
Hahaha absolutely, the KING of debugging strategies 🤣
Thanks u soo much , its helpful content for me about Git.
Thanks a lot 😊
good😀
Thanks 😊
A best how to use git short document!
Thanks a million 🥰
Fun read. Enjoyed the writing style
Awww thanks ☺️
git rebasedoes not give you clearer history thangit merge. True however is that rebasing give you more linear history. This is not the same as clean history.