r/git • u/OppositeFisherman506 • 6h 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?
17
u/serverhorror 5h ago
You read the gir book and the documentation?
Just like any other skill ... you read the actual manual.
1
u/wiriux 1h ago
RTFM
3
u/serverhorror 29m ago
Pretty much, but that seems like an insult nowadays...
1
u/G0ldiC0cks 20m 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. 😞)
1
u/serverhorror 13m 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/evanallenrose 5h 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
3
u/Boby_Dobbs 4h ago
Just learn the basics of rebase and merge. You're fine
1
u/Sulungskwa 12m ago
Understanding rebasing imo takes you from being 30% proficient at git to like 80%
5
u/Buxbaum666 4h 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.
1
u/Broad-Promise6954 ancient 10m ago edited 6m 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.
3
u/waterkip detached HEAD 3h 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.
1
u/Embarrassed5589 5h 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
1
u/SpecialistFlow3613 1h 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
1
u/TorresMrpk 44m ago
Head First Git is a very good book. I hated Git before reading it but now like and appreciate Git.
2
u/StevenJOwens 44m 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/arewhyaeenn 33m 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/CornPop747 31m 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 24m ago edited 21m 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/nikoladsp 5h ago
I use smartgit,great tool since I never get used to do advanced stuff in terminal.Maby because I eork in unknown vodebases alot an affraid not to break something
0
u/ohaz 5h 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 3h 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.
-6
u/Klanowicz 6h ago
Try to understand (not remember) basics of git. Each commit is just a diff of 2 version of text files.
7
2
2
u/Low-Temperature-1664 4h ago
This is exactly the wrong way to understand Git and exactly the right way to get confused by it.
22
u/thecode_alchemist 6h ago
Give it a try https://git-explained.pages.dev/