loading...

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.

 

How about just:
Learn concepts, not commands.

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

Thank you guys, have been looking for this information for a long time, glad to join your community. 192.168.1.1

 
 
 

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!

 
 

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

 

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

 

Very interesting information, I really like it because it can add insight for me more broadly, thank you very much for this extraordinary information

tutu app

 

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

That's awesome, congratulations!

Now I have to read it...

 

yes, it's really true! And my congratulations too!
jiofi.local.html

 

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.
Sorry!
Angie

 

Hi

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!

 

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.

 

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

 

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!

 

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!

 

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".

 

Thanks!

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

 

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

 

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 :)

 
 

Awesome. A great in-depth tutorial.
Just one note - instead of git checkout command you could use git switch command, which is easier to change branches in git and also aligns with the concept of switching and the command for it.

To read my tutorial with more detailed examples on how to use git switch command, please visit -dev.to/irshadbluecast/how-to-switc...

 

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

    `` `
    {code}
    `` `

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..

 

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!

 
 

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!

 

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!

 

Great effort of you explaining these concepts, I think its quite frustrating when one is starting out as a developer to learn these things but they are quite valuable and needed so we find articles like this one very useful.

Thank you very much, Nico ;)

 

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.

 

Hi Nico, I'm a bit lost on how rebase works under the hood:

  1. So first it goes to the common ancestor
  2. Applies all the commits made on add_patrick branch to master
  3. From this then it finally creates a new commit on add_patrick branch that incorporates all the changes it previously merged with master (point no 2) to the branch

Am I getting this correct? :)

 

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

 

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 :-)

 
 

A very nicely written tutorial. Thanks for sharing.

 

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.

 
 

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

 

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

Thanks!!

 

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

 
 

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.

 

Great read --- thanks for sharing!

 

Thanks for this post, very clear and usefull

 

thanks, this was very informative!!

 

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...

 

Unbelievably helpfull in understanding core concepts

 

Great post, very straightforward and informative!

 

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!

 

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, we definitely should learn about concepts and ideas

 

LeonFlix for windows is a free multi-platform content streaming app. The app is available for a number of platforms excluding Android.

 

Excellent tutorial man! This was super well explained.

 

Great article, would love to have some gifs in it for better understanding 😄

 

Anything in particular you got in mind there, where you think it would help?

I've been thinking about turning it into a mix of presentation and hands on tutorial at some point.
And maybe when I do that, the visuals might be something I get around to improving.

 
 

Awesome article; truly appreciate it. Definitely bookmarking this for reference.

 
 

Eventhough is it long , this tutorial is good when you tell the reader by using the picture. Now I understand the concepts and flow. Thanks you very much.

 

Appreciated the effort that went into this

 

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

 

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

 

A piece of art for git understanding.. Excellent

 

Believe me, this is not 36 min read, I'm a human and it took me a few days.
But this is a great post.

 

this is the exact opposite of "pragmatic programming", which is, "just do this and it should work and don't ask why and even I don't know why and how it works and what it is but just do it."

 

Awesome Post Thanks !! This is the best article I found on the internet. Helped me a lot !

 

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!

 

Could some one please explain What sequence of Git commands
could have resulted in this commit graph?
dev-to-uploads.s3.amazonaws.com/i/...

 

Great article, can I translate and reprint it

 

Could some one explain What sequence of Git commands
could have resulted in this commit graph?

code of conduct - report abuse