r/git • u/OppositeFisherman506 • 1d ago
support How do you actually learn git properly after three years of add commit push and praying?
My entire git knowledge is basically four commands and a bookmark to that xkcd about deleting the repo and cloning it again.
It worked fine because I was mostly working solo. Now I joined a team in June that rebases and suddenly Git has become terrifying.
I keep looking at boot dev, learn git branching and the pro git book. Pro git is free and thorough but somehow I have opened chapter one three separate times and never made it past it.
At this point I feel like I know how to use git without actually knowing git. What did you guys use to properly learn it?
18
u/evanallenrose 1d ago
The team will have a process in place and they’ll tell you what it is. If you have the basics you’re 90% of the way there
2
u/OppositeFisherman506 20h ago
Yeah the basics are there. Rebasing is the scary part.
2
2
u/Buxbaum666 15h ago
There should be nothing scary about it. The important part is to commit your work often. Once all work is committed, it is extremely hard to unintentionally screw up anything in a git repository.
Conceptually, a simple rebase just changes the parent-commit-pointer of a given commit to a different commit. Hence the name, it changes the base of a commit. Because commits are immutable objects, however, this actually creates a new commit (or a chain of commits if there's one or more commits after it) and has that new commit point to the new parent commit instead. That means the old commit chain will still be there.
1
u/dogdevnull 44m ago
Learn how to back out of a rebase gone wrong. Learn how to use cherry-pick to get the same effect as a rebase. Squash into one commit before you rebase to an avoid cascading merge conflicts.
10
u/Buxbaum666 1d ago
What did you guys use to properly learn it?
I read and understood the "Git Internals" chapter (chapter 10) of the git book, the most important subchapters being "Git Objects" and "Git References". Once I understood that basically anything in git is either a reference, a tree or a blob, things started to really click for me. What's a branch (or tag)? Oh that's just a text file containing a reference (hash value) to a commit object. What's a commit object? That's just a file containing a reference to a tree object, a parent commit, author information, and a message. What's a tree object? That's just a file containg references to other trees and/or blob objects along with their respective names in the file system, basically a folder. What's a blob object? That's a file tracked by git.
What does git add do? It creates new blob objects for any changed files and adds them to a new tree object. What does git commit do? It creates a new commit object that points to said tree object previously created by git add, adds a reference to the last commit object in the current branch as parent object and then changes the branch to point to this new commit object.
At the lowest level, git is really simple and all commands just operate on this object database in some way.
2
u/Broad-Promise6954 ancient 1d ago edited 1d ago
These are indeed important (just want to put that in before the "technically" part).
Technically the tree objects don't get made until
git committime (or in the old days of the scripted version,git mktree, part of the old commit script). Also, "tracked" really means "is in the index", which ... is why you need to understand the index.1
2
u/OppositeFisherman506 18h ago
This actually helps a lot. I think my problem has been learning Git as a list of commands instead of understanding what those commands are doing to the objects underneath.
1
u/emaxor 1d ago
To be fair, you have to have a very high IQ to understand git. The design is extremely subtle, and without a solid grasp of theoretical physics, the nature of the directed acyclic graph will go over a typical users head.
There's also git's nihilistic outlook, which is deftly woven into its characterisation - it's personal philosophy draws heavily from Narodnaya Volya literature, for instance. The real git users understand this stuff; they have the intellectual capacity to truly appreciate the depths of these properties, to realize that they're not just useful- they say something deep about LIFE. As a consequence people who dislike git truly ARE idiots- of course they wouldn't appreciate, for instance, the humour in git's existential catchphrase "rev-parse --abbrev-ref HEAD" which itself is a cryptic reference to Turgenev's Russian epic Fathers and Sons.
I'm smirking right now just imagining one of those addlepated simpletons scratching their heads in confusion as Torvalds genius unfolds itself on their screens. What fools... how I pity them. 😂 And yes by the way, I DO use Arch linux. And no, you cannot see my WM setup. It's for the ladies' eyes only.
2
1
1
u/Buxbaum666 16h ago
Ok bro. Not sure what you're trying to say with your Rick & Morty IQ copypasta here, especially on a comment that was meant to demonstrate that Deep Down It's Not That Complicated™ but you do you.
27
u/serverhorror 1d ago
You read the gir book and the documentation?
Just like any other skill ... you read the actual manual.
7
u/wiriux 1d ago
RTFM
3
u/serverhorror 1d ago
Pretty much, but that seems like an insult nowadays...
1
1
-1
u/G0ldiC0cks 1d ago
There's really only one group I can think of legitimately offended by being told to read. It starts with ill, and they aren't the illest, I tell ya what.
(Except when they, of course, have any of the thousand and one qualifying conditions/circumstances/hardships resulting in an obstructed path to literacy and instead choose the lesser resistance as any reasonable person would. Humanism is hard and not very funny. 😞)
2
u/serverhorror 1d ago
You can call people stupid, their existence is a scientifically proven fact.
- New Study: A Lack of Intelligence, Not Training, May Be Why People Struggle With Computers https://scitechdaily.com/new-study-a-lack-of-intelligence-not-training-may-be-why-people-struggle-with-computers/
- Cognitive abilities predict performance in everyday computer tasks - ScienceDirect https://www.sciencedirect.com/science/article/pii/S107158192400137X?via%3Dihub
7
u/id-ltd 1d ago
You don't need to know it all.
There will be a few use cases that the team use - you'll see why and learn the commands required.
Your solo use case worked fine for you :)
3
u/hardcorerawk 1d ago
Very, very much this. You use what you need and learn as you need.
I was similar for years,
git {commit,push,pull}was everything I needed. Then I worked at a shop that did squash and rebase, so I asked why, and learned it (and loved it too, now I do the same for everything I run).1
u/No_Cattle_9565 21h ago
But understanding rebase, reset and reflog shouldn't take more than a few hours. The cli even tells you what to do most of them time
5
u/Boby_Dobbs 1d ago
Just learn the basics of rebase and merge. You're fine
3
u/Sulungskwa 1d ago
Understanding rebasing imo takes you from being 30% proficient at git to like 80%
5
u/waterkip detached HEAD 1d ago
I broke it a lot. I just made backups and performed actions. If it succeeded, did it again. If it failed, restored it from backup and tried something else. You get to know your tools when you deliberately do things a certain way because you want to know how they work. That means you also break it every now and then.
2
2
2
u/StevenJOwens 1d ago
I can't say I really understand git well and thoroughly, yet, but what I've found that works for me is learning about how it actually works, what goes on under the hood.
I've found too many handwavy explanations that either get it wrong, or leave out important nuances, or even worse, mislead.
Understanding the basic building blocks: .git/objects, hash references, etc, isn't that hard. The .git/index is under-documented but also pretty straightforward.
Next is understanding how those building blocks go together to make the bigger structures in git.
When you make a new commit, git creates a commit object. The commit object has a field that contains a hash reference to the previous commit, and a field that contains a hash reference to the top of a tree of objects that contain a snapshot of your working files at the time of commit.
Then, of course, there's the big daddy structure, "the commit graph", aka the big shape of how all of these commit objects fit together. There's a subtler thing here that you eventually learn, which is "thinking in graph". Learning the basic idea of a graph is pretty straightforward -- things (aka nodes) and connections between things (aka edges). Internalizing that and getting comfortable thinking in graph takes some time.
What most people do next, simultaneously with learning to think in graph, is get into the processes that manipulate those building blocks and bigger structures, i.e. creating commits, branches, merges, merge conflicts, pushes and pulls. That what I did, too. obviously, you need/want to learn these, because they're what you need to use, day to day.
However, I think that's a bit of a mistake, or at least it was for me. I think I would have been a bit better off if I started with a quick tour of what I call "the git metadata", aka "everything inside .git that isn't .git/index or .git/objects." The most important of these, from my understanding so far, are .git/refs/heads, .git/refs/remotes, .git/HEAD, and .git/config.
You need at least a cursory understanding of the git metadata to be able to talk about how each process/action actually interacts with and manipulates those building blocks and those bigger structures. Because those building blocks and bigger structures are in fact defined in large part by that git metadata.
This is where it gets harder to find concrete details, in my experience. Your ultimate resource is, of course, the git source code, but it's slow going (for me personally, that includes dusting off 25 year old C skills). But there seems to be a "dead spot" in the resources, a gap between the source code itself and tutorials that only tackle it at higher levels.
1
u/Embarrassed5589 1d ago
i watched youtube vids that gave me a good mental model for what a commit is, and how the history is actually a graph. It should become intuitive after you understand it and practice.
1
1
1
u/SpecialistFlow3613 1d ago
After each release, create a new fork of master (using a naming convention) and make your edits there. Each feature and addition would be worked on separately or by different people. After you are done, squash commits (combine them so there are less in the history) if needed before you merge into master. git checkout will switch between branches.
1
u/TorresMrpk 1d ago
Head First Git is a very good book. I hated Git before reading it but now like and appreciate Git.
1
u/arewhyaeenn 1d ago
This is going to be counter to what a lot of people will tell you here but: try a GUI like gitkraken, tortoise, etc.
These visualize the tree structure of the repository, and may help you get an intuitive grasp of what the stuff you’ve memorized has been doing.
My recommendation for learners:
1. DO STUFF in the command line.
2. VIEW WHAT YOUVE DONE in a GUI.
1
u/mechanicalyammering 10h ago
Didn’t know about these. Cool. I use github.com as a GUI but it is also not intuitive 😂
1
u/CornPop747 1d ago
You run into unique instances eventually. Then you can chat gpt it and it will explain what went wrong what you need to do to fix it the command and why. It's helped me.
1
u/Broad-Promise6954 ancient 1d ago edited 1d ago
I ended up digging deep into it, but this was back in the 1990s/early 2000s.
The Pro Git book is good but isn't the book I would have written. To my mind, the big stumbling blocks people hit are: "the index"; understanding how the commit graph works, including what it means to find a "merge base"; understanding what "git merge" actually does under the hood; understanding that "git rebase" is a series of merges, one at a time; understanding Git's "references" (branch and tag names); and realizing that "git pull" is just a convenience short-cut for two separate commands, "git fetch" and a second command of your choice (rebase or merge).
Once you know all of these, and add the fact that "git push" does not merge anything, you achieve a sort of Git Nirvana.
1
u/popsicle-physics 1d ago
Read the git book on the git website. Setup a test repo and play with it a bit. Then, most importantly, actually use it regularly.
1
u/joshpennington 1d ago
I did a ton of tutorials and half learned a bunch of commands. The only thing that truly got me to learn anything was real world daily experience for the last 10ish years. Just keep using it. When problems arise don't delete the repo and start over. I like to zip up the directory (if feasible) if I am doing anything crazy. I also learned how to tag commits as a bit of a backup when doing things that feel risky like a rebase that has conflicts or a weird merge.
Only thing I can suggest to get good at it is to just keep using it
1
1
u/stianhoiland 1d ago edited 9h ago
git add/commit/push is a great place to start and can last you a long time.
If you really want to go deeper, I feel like what you should understand is that git is just a graph where you're creating nodes and connecting them.
When you commit, you're just creating a new node floating about in empty space, and then connecting it to an existing node (its parent). What has happened now is that you can now walk that graph from somewhere else and arrive at your newly created node.
When you're using git, none of your commits are ever deleted. But what can happen is that single or sets of nodes/commits can get disconnected from the graph and become unreachable by walking the graph. This always happens because you told git to do so. And this will feel like you have just deleted your work! But those nodes/commits still float about in that space, just not connected to anything that you can reach them from. All you'd have to do to "get them back" is to tell them to connect back to the graph.
Every commit/node has a unique identifier (SHA) by which you can find them, no matter if they are connected to the graph or just floating about. And git has a persistent log of every (dis)connection it does, called git reflog. The reflog is a separate data structure to the graph, and it's just a chronological list, meaning there is no requirement for nodes to be connected to be able to reach them and display them. You can find them all there, chronologically, and you can't "lose" any commits.
Every time you reconnect nodes/commits, git clones the original commit and creates a new one, because according to git a node/commit's parent is part of its identity, so it gets a new SHA when the parent changes. But the file changes/work of that commit stays the exact same.
A branch is an easy alias for a commit SHA. That's it. Just a short ASCII name for a long-ass SHA.
The reason it's called a branch is that from any node/commit—for example the one you've given a cute name like dev or main—you can then walk the nodes backwards through their parents, and that walk will be a walk through a particular sub-graph of the tree.
It would also be nice to understand git's object store—which is just a fancy name for your work which git puts on your disk in simple files in .git/objects. But this is long enough already.
As a last note, you CAN tell git to ACTUALLY delete unreachable commits as a cleanup/maintenance/garbage collection thing—because EVERY COMMIT STAYS IN GIT, whether they're connected or just floating about, and eventually that might get unwieldy or thoroughly outdated. But you have to REALLY TRY to get git to do this and it never happens during normal operating—git's your graph, and you get to do whatever you want with it.
2
u/mechanicalyammering 10h ago
Broooo good comment. Helped me a lot. Did not realize this is basically checksumming.
1
1
1
u/jdigi78 1d ago
Use a GUI. Unless you absolutely have to work with git in a terminal there is hardly ever something you'll need outside of what a GUI like desktop plus can do.
1
u/Dapper-Message-2066 20h ago
Good luck! When you figure it out maybe you can explain it to me. Been using it a few years now and wish I could go back to TFS!
1
u/ejpusa 17h ago edited 17h ago
Really 90% is:
git add .
git commit “first commit”
git push
Codex (Claude) writes all your code now. You don’t even look at it. Just moving on to the next project.
The Reddit response: are you crazy? Are you on meds? Well, I guess, but it’s amazing. And it works.
Anything thing more then that, if you get stuck, just ask GPT 5.6 it will help you out.
Have been coding for a living for almost 5 decades, now I don’t write a single line. It’s 100% Codex for me. Very little tweaking now. This is 2026 AI not 2022 AI.
Git moves front and center now, it’s the management of your entire project — all by way of the Codex pipeline.
It’s a new style of programming.
1
1
1
u/Fragrant_Swimming_21 13h ago
There's a new kind of git tutorial around that you can get through in the actual editor with real workflows and real git: https://gitbybit.com
1
u/Reddit_is_fascist69 11h ago
Easy, just have your senior dev tell you to rebase your MR and then walk away.
You'll spend hours trying to figure out all the merge conflicts and you'll be an expert.
1
u/mechanicalyammering 10h ago
I had to make a big mind map, diagram, note doc thing. I had to retype all the stuff to make it stick. I still think it’s confusing as fuck and need to refer to my notes. They did not make the words easy to remember.
1
1
1
u/nikoladsp 1d ago edited 19h ago
I use smartgit,great tool since I never get used to do advanced stuff in terminal.Maybe because I work in unknown codebases a lot and afraid not to break something
0
u/ohaz 1d ago
There's 3 things you want to learn and luckily you can learn all of them locally!
First of all, create a new local repo (git init) Now, create a main branch if it does not exist
Ok, so these 3 options are what you want to learn:
- Git rebase because base branch has changed: create a branch, create a commit. Go back to main branch, create a commit (that changes the same file). Go back to your feature branch, rebase onto main. Make sure your commit lands on top of the new commit.
- Git rebase because you want to change the history of your branch: create a branch, change a file, create a commit. Change the same file, create a new commit. Start an interactive rebase (rebase -i main). Change the 1st commit to edit mode (replace the first word in the line with an "e" and close the file). Change something in that file again, then follow through with the rebase.
- Git reflog, so you can fix fuckups when your rebase went wrong. Run git reflog and take a look at the output. You can restore commits from before rebases because they are in that log and still exist. You can just check them out :)
-1
u/LetUsSpeakFreely 1d ago
95% of your day is add, commit, push, pull, and merge. You might need to do a rebase if you're working with other developers.
For everything else, you'll need to use Google an AI. Very few people remember the other commands at a muscle memory level.
-5
u/Klanowicz 1d ago
Try to understand (not remember) basics of git. Each commit is just a diff of 2 version of text files.
8
2
2
u/Low-Temperature-1664 1d ago
This is exactly the wrong way to understand Git and exactly the right way to get confused by it.
52
u/thecode_alchemist 1d ago
Give it a try https://git-explained.pages.dev/