Learn git concepts, not commands

Nico Riedmann on June 02, 2019

An interactive git tutorial meant to teach you how git works, not just which commands to execute. So, you want to use git right? But you don't j... [Read Full]
markdown guide

Learn x concepts, not x commands. Probably a reusable statement across many technologies.


This reminds me of the site "learn X in Y minutes". I visit that site every few days haha


Learn x concepts, not only x commands.
Probably a Best reusable statement across many technologies.


Still we need to learn commands but not only commands. So Learn Concepts , not only Commands :)


Nice post, thanks.

For another perspective I could also suggest the "Git from the Bottom Up" jwiegley.github.io/git-from-the-bo...
which starts from how the repo is built inside (blobs and trees). Opened my eyes at some point - and also allowed me to explain Git to others better :-)


Thanks, did not know that one yet! Added to my reading list


One of the best articles about Git. You've really put a lot of effort in producing this awesome article. Thank you so much for your contribution to the developer community. Actually, This is the best and intensive article that I have ever encountered on the internet. Nice job!


Great write up on crucial concepts to understanding how/why to use various git commands. There is one semantic distinction that I find helpful when talking about rebase to those unfamiliar with it. Rather than saying:

We re-base our add_patrick branch on the current state of the master branch.

It might be clearer what is happening if you say:

We re-base our add_patrick branch from the current state of the master branch.

That is to say, we get a new base set of commits for our branch from another branch. So, as you describe, when we run the command git rebase master [add_patrick], we are taking all commits from master that add_patrick does not yet have, and rewinding to apply them to HEAD before replaying our commits in add_patrick.


For me personally understanding the on or onto wording for rebase as it's also used in the git reference actually helped me when I learned about it originally.

I take my changes, which where originally based on some branch HEAD, and I put them onto some other branch's current state (or state of the same branch)


Like I said, it is semantics, but I've found that slight change in wording useful for some when helping them understand rebase.

Agreed - I completely misunderstood this at first because “rewind and rebase onto” sounds like “take my work from ‘add_patrick’, add all those commits “onto” ‘master’ (which doesn’t happen & wouldn’t really make sense) before moving the divergence point & continuing on the current branch.

The key point to understand is that you get all new commits from ‘master’ so your current branch is up to date with it (kinda like a git pull), then reapply the commits from ‘add_patrick’ again from that new point of divergence from master, but still on ‘add_patrick’ itself.

That confusion on my part aside, I found this to be a fantastic overview! Thanks!


One caveat you should mention is that "git push" doesn't always work on some git installations, especially POSIX ones like Linux. You may have to qualify with the remote repository for it to work:

git push origin master

But otherwise, its super informative and well written article.


With git 2.0 introducing the simple push strategy as default setting, I was under the impression that you generally wont need to qualify the remote you're pushing to, as long as it's set as upstream and has the same name as your local branch (which it is if you don't go out of your way to have it differently).

Or am I wrong about something there?


Yep, it considers the current branch (origin/master) as the default if git config --global push.default setting is set to current. This is usually set by default on windows and ios, so simply doing "git push" might work but on some linux distros, this setting isn't set to current but set to nothing instead (which means you'll have to explicitly add the branch).

Especially, the last time when I'd worked on Ubuntu, simply doing a git push had not worked.

As far as I understood it, the "new" (git 2.0 is from 2014) default is simple.

From the git doc:

When neither the command-line nor the configuration specify what to push, 
the default behavior is used, which corresponds to the simple value for push.default: 
the current branch is pushed to the corresponding upstream branch, but as a safety measure, 
the push is aborted if the upstream branch does not have the same name as the local one.

Of course it may still be that some distro installations either install older versions, or install with a non-default configuration. Somewhat recently having set-up my work laptop on Ubuntu 18.04 I do not recall having to set the push configuration


This is crazy good. Super informative and the visual aids definitely help. Thanks for sharing! 👏🏼


Hey! I am so new to GitHub...where am I supposed to be typing these commands...at the command prompt, possibly? I am trying to follow this tutorial. I ran into a 'GitHub Desktop.' Now I'm confused as to whether I use this or do it some other way.



Yes, those go in the command line!

There a few graphical git clients that I hear are nice. The github desktop one, tower git and a lot of my colleagues use what comes with their IDE (we use intellij idea for java)

But for understanding what is going on I think you'll learn more using git from the commandline.

The tools abstract a lot of things away trying to make things easier to use


I think I prefer the command line anyway. Thanks so much!


Wooh! Did your post really get more than 3000 reactions in only two weeks?

That's awesome, congratulations!

Now I have to read it...


What an effort you have put on this post. It's almost felt bad to call it as a post. It seems like a book or wiki very least.
I was just getting there by doing it and you helped me greatly. I also really loved the useful tips. Thank you so much.


Thanks for nice writing. It is awesome for understanding git to me.
And I want to share with my friend and colleague, Could I translate with my language and share it?
I will refer this origin post too.


What a great idea, please do that!
The more people it gets to help the better.
What will you be translating it to?

I guess you'll want to fork the git project so you have the md source for your translation.

I'd be more than happy to link to your translation as well, or include it as branch of the repo when you're done!


One of the best tech articles I have ever read. Thanks for the effort


Great Article! I really loved it. Could you add a section about the reset command?. The different options it has and the difference between them


This is the tutorial I needed back when I first started out with git as a junior dev, I struggled way too long just learning off commands rather than trying to understand the concepts, will be bookmarking for future thank you!


Congrats Nico!

I've added a bonus at the end of the post which inspired you.

I'm really happy ;)


Wow. Thanks!

For the shout-out in your article, the inspiration and your great articles in general :)


Hi there! Nice post.

I think that you've made a mistake here:

"Should you ever realize in the middle of resolving conflicts that you actually don't want to follow through with the merge, you can just abort it by running git commit --abort"

I think you probably wanted to write: "git merge --abort".



Yes, I did mean merge and have fixed it. Thanks for catching that!


I do not understand local repo. You have a local clone and several staging which are just different tagged revisions of the remote repo. If there are more than one user you need to keep everything in the remote repo and push/pull frequently. short lived branches etc. but everything lives remotely. Not a single add without an immediate push.

And the remote servers like gitlab/gogs handles conflict by leaving a pull request for the admin to accept/reject, much better than rebasing long lived branches with outdated code :-)


I do not understand local repo.

When working with a clone of some remote repository, what you have is a git repository on your local machine that is a copy of the remote at that point in time. All work you do is in your local repository, which, to your point, you should constantly keep in sync with the remote repository.

Also, I agree 100% with not wanting long-lived branches, but rebase and merge (and their differences) are very important concepts to understand in git. You can't

keep everything in the remote repo and push/pull frequently

without doing a merge or rebase at some point, whether implicitly or explicitly. Every pull from remote causes a merge of some sort. All commits, including pull requests (when accepted), have to be merged into your trunk somehow--whether with a merge commit, or by being rebased then merged. The author does a great job of illustrating the distinctions and benefits of both.


Such a great article! Thank you for such a concise and nicely written post on some of the concepts of git - will certainly share it with others that are attempting to understand git and demystify some common questions!


Great article! Thanks for all the work you put into this.


Great post! But you have some markdown formatting errors 😃


Oh, thanks for pointing that out! Completely missed those!

I've applied a quick fix to at least make these parts readable, but I'm really unsure as to why those parts don't work.

All of them are multi-line code blocks with three back ticks

    `` `
    `` `

However only the first few seem to work (here? both on github and my blog those are rendered fine).

Does anyone have an idea what might be wrong?


Did you get it to work properly? There is a space in the three back ticks. Maybe that is the problem 😃

Didn't figure it out at all yet...
I've changed to having 4 spaces as indentation and that somehow results in things at least being rendered as individual code lines, but not as the block

Put the space in the sample above, because I didn't know a way to escape the back-ticks inside the code-block to show how they actually are..


Like everyone else, I have to say this was fantastic. Thank you! I'm comfortable w/ git, but I tend to stay in the areas I'm comfortable in (so maybe I'm not that comfortable w/ git? ha). I learned so many more things and solutions to problems I have come across. Great work!


Nico, I'm writing a serie about git behind the scenes and I'm using this post as a reference for this writing.Thank's for this material!


After reading lots of articles here, this is my first comment. I really have to thank you for that awesome work! You are my first unicorn :-)


This is one of the best tutorial articles I've read. You are a great teacher. I hope you write some more I'll be in the look out! Thank you


Thanks :)

Glad you found it helpful!

Sadly I'm a horribly slow writer, but I have a few things I'm working on


I love this so much! It's so true too, and as Ben said is great advice across many technologies!

This definitely needs sharing! Thanks!


Holy **** dude. This is an awesome post! Thanks for writing


I'm saving the commands anyway but now I understand them, so many thanks !
Git has so many subtleties.


Great post and well said. Along the same lines, I started "Build GIT, Learn GIT" -> kushagragour.in/blog/build-git-lea...


Great post, very straightforward and informative!


This post is amazing and highly recommended bookmark to anyone using git.

Thank you for your time and effort on this article and for writing in an informative and engaging way.


A very nicely written tutorial. Thanks for sharing.


Wow, this is super helpful! I've been looking for something like this for months!



This! This is the best git article/lecture I've encountered throughout my 8 years of web development!


It's actually ridiculous how helpful this entire post is. Thanks for the work you put into this! Definitely shed some light on git concepts I wasn't all too familiar with.


Unbelievably helpfull in understanding core concepts


I haven't read the entire article (yet), but it's been a wonderful tutorial so far. Git's documentation is very dense, and thus confuse most of the sometimes. Thanks!


Excellent tutorial man! This was super well explained.


Minor typos:

"on it's own" -> "on its own"

There are ~3 other "it's" vs. "its" errors.


Thanks for catching those! Guess not being a native speaker has to show somewhere.. ;)

Given that there were actually quite a few more and the formatting is off if I just copy-paste the markdown here for some reason, I've only fixed the mistakes in the git repo of the tutorial


Thanks for that awesome article! This not only is my first comment, but also my first unicorn :-)

code of conduct - report abuse