Git is such an essential part of my development workflows, it almost fades into the background of everyday work for me.
This is a sure sign, that I should notice and care about it more :) After all, mastery is a process and not a state you arrive at. It’s always a good idea to tend to the tools of your craft.
So, for the sake of pushing (heh) myself to discover things I don’t know yet, I’d like to share a collection of facts I wish I had internalized about Git sooner.
.git is just a folder with files
The .git directory, directly where you initialized your repository contains all your local Git data.
You don’t need GitHub or GitLab to use Git. Just having a local repository is enough.
Pull is fetch with a merge
Fetch is a command which gets data about remote branches. A merge brings the remote changes to your local repository.
A pull tries to do both for you.
Each commit is a diff
It contains the changes compared to the previous commit.
Added lines and removed lines for each changed file added to the commit.
You can use Git for binary data, but watch out for file size
In general, you shouldn’t add stuff which can be reproduced from your code to Git. Something like compiled assets or binaries probably don’t belong into your Git repository.
That said, you can use Git to track images and other non-textual data. It’s not just for plain text files.
If your binary files are large and changing, check out Git LFS.
You can amend commits
If you have created a commit, haven’t pushed it to a remote repository yet and want to edit it, you can do so with amend.
Git Gui exists
If you want to create fine-grained commits, review what file changes are staged and be selective, git gui is a neat command I like to use.
You can also use it to edit a previous commit - the amend stuff from above.
A branch is just a pointer to a commit
A reference, tracked by reflog. When you add a new commit to a branch, the pointer moves to the newest commit automatically.
But a branch isn’t much more than a fancy name following a chain of commits.
HEAD is just a pointer as well
It points to the branch or commit your working directory state is based on.
And once again, reflog tracks its movement. Mostly, it’s useful to see where you are compared to other branches.
Check out
git log --graph --oneline --all
and you’ll see a neat overview of where HEAD is, where other branches are and how commits relate to each other.
Careful with --force commands
This is something I learned the hard way - you have to watch out and be very careful when there’s a --force involved in the Git command you are typing in.
Chances are, the safeguards you are trying to disable with it are in place to protect you and your work. Be sure that you know what you do!
Rebasing isn’t magical
I’ve been stepping around learning to rebase for a while, but once I did I wondered why I didn’t learn it sooner. It’s very neat when working in a team setting, and makes for way smoother development workflows than haphazard merging back and forth.
If you haven’t taken the time yet, you can learn everything you need to know in this great article.
Taking time to learn the basics
I think my Git skills drastically improved, back when I took the time to learn all basic concepts.
This cool article by Ian Miell helped me a lot, even after years of using Git. If you haven’t taken the time for Git basics yourself, check it out!
Git is probably just part of your problems
And finally, if you feel like you’re struggling with Git, chances are that the dev workflows you have in your team just could use some work.
If you are working with people who are not careful with how everybody uses Git, you will run into regular merge conflicts - guaranteed. It’s good to know the tool, but it’s also important to get everybody on board to use it in a responsible fashion.