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...
For further actions, you may consider blocking this person and/or reporting abuse
Learn
xconcepts, notxcommands. Probably a reusable statement across many technologies.TEST
teste
Toast
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 :)
test
For many years trying to combine learning and writing code I decided that copies from stackoverflow is the best part of my job :D
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
rebaseto those unfamiliar with it. Rather than saying:It might be clearer what is happening if you say:
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 frommasterthatadd_patrickdoes not yet have, and rewinding to apply them to HEAD before replaying our commits inadd_patrick.For me personally understanding the
onorontowording 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
ontosome 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!
Now i get it...thanx
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!
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:
But otherwise, its super informative and well written article.
With git 2.0 introducing the
simplepush 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.defaultsetting is set tocurrent. 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 tocurrentbut set tonothinginstead (which means you'll have to explicitly add the branch).Especially, the last time when I'd worked on Ubuntu, simply doing a
git pushhad not worked.As far as I understood it, the "new" (git 2.0 is from 2014) default is simple.
From the git doc:
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
TEST
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
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.
Wooh! Did your post really get more than 3000 reactions in only two weeks?
That's awesome, congratulations!
Now I have to read it...
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
Awesome. A great in-depth tutorial.
Just one note - instead of
git checkoutcommand you could usegit switchcommand, 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 switchcommand, please visit -dev.to/irshadbluecast/how-to-switc...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 :)
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!
Great article!
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
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
mergeand have fixed it. Thanks for catching that!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!
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 :-)
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
rebaseandmerge(and their differences) are very important concepts to understand in git. You can'twithout doing a
mergeorrebaseat 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.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
codelines, but not as the blockPut 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 thanks so much I never took the time to really understand how Git works, then I googled when I messed up. You are so right about how important it is to understand how things work. No wonder we get in trouble when we Willy Nilly cut and paste code. Super Cool of you to share this brother!
Hi Nico, I'm a bit lost on how rebase works under the hood:
Am I getting this correct? :)
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 ;)
Thanks!
EXIF TEST
Great article! Thanks for all the work you put into this.
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!
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!
thanks, this was very informative!!
Holy **** dude. This is an awesome post! Thanks for writing
great job
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...
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.
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 :-)
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!
I love this, we definitely should learn about concepts and ideas
Great read --- thanks for sharing!
Thanks for this post, very clear and usefull
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 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
A very nicely written tutorial. Thanks for sharing.
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!!
Best
Great article, can I translate and reprint it
I've visualized it
dev-to-uploads.s3.amazonaws.com/i/...
A piece of art for git understanding.. Excellent
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
Appreciated the effort that went into this
Awesome article !!!
Excellent article, Nico!
Amazing tutorial ! I found this tutorial very easy to read and really instructive. I learned so much thanks to you ๐
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.
Looks like this article broke?
Thanks for that awesome article! This not only is my first comment, but also my first unicorn :-)
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.
Excellent tutorial man! This was super well explained.
Could some one explain What sequence of Git commands
could have resulted in this commit graph?
Could some one please explain What sequence of Git commands
could have resulted in this commit graph?
dev-to-uploads.s3.amazonaws.com/i/...
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!
LeonFlix for windows is a free multi-platform content streaming app. The app is available for a number of platforms excluding Android.
Awesome article; truly appreciate it. Definitely bookmarking this for reference.
test
Awesome. Shared it on Devopedia twitter handle.
Truly fabulous post!
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.