Learn Git in the Browser(try.github.io)
try.github.io
Learn Git in the Browser
https://try.github.io/
14 comments
I just wanted to chime in here to thank you for this. I found it very helpful, even after I did the CodeSchool course.
okay, I just spent my lunch time going over the tutorial. It makes me happy (and very thankful) that people like you are taking the time to create such great resources. Kudos!
Thanks for the tutorial. I appreciate that Git is complex and powerful, but I didn't need a tutorial for Subversion. Git is baffling. The error messages are cryptic and unhelpful. It deters the casual user. Can I suggest a list of the absolute, bare-bones minimum set of commands for a project where there will be no merging, just uploading by one person, and downloading by others?
Personally I would like git tutorials to include a lot more of common mistakes, and what to do when things go wrong. Getting up to speed with the basics of git for basic version control, branching/merging is fairly straight forward.
It's when things don't go as planned it's easy to feel trapped in a corner. e.g. did a git pull that causes a merge, how to undo that step and do a git pull --rebase instead. How to dig yourself out of doing a git merge in the wrong branch. How to revert the 4th last commit only etc.
It's when things don't go as planned it's easy to feel trapped in a corner. e.g. did a git pull that causes a merge, how to undo that step and do a git pull --rebase instead. How to dig yourself out of doing a git merge in the wrong branch. How to revert the 4th last commit only etc.
Use Mercurial.
There's http://hginit.com. Given your comment about "I didn't need a tuturial for Subversion", though, maybe you'll find that inadequate, too. As someone who tried using SVN before ever touching hg or git or its forebears, I found SVN baffling. To me, the DVCSes make sense. HgInit's "Subversion Re-education" page says:
> Mercurial separates the act of committing new code from the act of inflicting it on everybody else.
The fact that this isn't the case in SVN is mystifying to me.
I still struggle with git. In fact, I don't use it, largely because I still don't know how to use it. Note how I said that "the DVCSes make sense". I say that, because I can read "Understanding Git Conceptually" <http://www.sbf5.com/~cduan/technical/git/>--which a number of HN commenters have posted before--and I get it. The problem is not that I don't understand the concepts backing git. It's that I don't understand how these concepts map onto git's infuriatingly obtuse UI.
So use Mercurial. Because,
a) it's better (read: nicer to use), and b) when you use Mercurial, it comes with the benefit that you're helping inoculate the dev world against a DVCS monoculture.
If it helps, know this: I write as someone whose use case is largely the one you outline. I mostly find myself working alone, on a side project of mine where I'm the only committer.
Everything ramps up pretty sensibly and steadily from there, so that you're really only spending the mindspace to pay for the features you're really using.
For example, if you have a public-facing repo:
There's http://hginit.com. Given your comment about "I didn't need a tuturial for Subversion", though, maybe you'll find that inadequate, too. As someone who tried using SVN before ever touching hg or git or its forebears, I found SVN baffling. To me, the DVCSes make sense. HgInit's "Subversion Re-education" page says:
> Mercurial separates the act of committing new code from the act of inflicting it on everybody else.
The fact that this isn't the case in SVN is mystifying to me.
I still struggle with git. In fact, I don't use it, largely because I still don't know how to use it. Note how I said that "the DVCSes make sense". I say that, because I can read "Understanding Git Conceptually" <http://www.sbf5.com/~cduan/technical/git/>--which a number of HN commenters have posted before--and I get it. The problem is not that I don't understand the concepts backing git. It's that I don't understand how these concepts map onto git's infuriatingly obtuse UI.
So use Mercurial. Because,
a) it's better (read: nicer to use), and b) when you use Mercurial, it comes with the benefit that you're helping inoculate the dev world against a DVCS monoculture.
If it helps, know this: I write as someone whose use case is largely the one you outline. I mostly find myself working alone, on a side project of mine where I'm the only committer.
# Crystallize your changes in a revision marked with your
# commit comment:
hg commit
Everything ramps up pretty sensibly and steadily from there, so that you're really only spending the mindspace to pay for the features you're really using.
For example, if you have a public-facing repo:
hg push # read as "publish", if it helps.
> http://www.sbf5.com/~cduan/technical/git/>--which
... aaaaand HN is busted, and won't update the post when I try to edit that to fix the link.
That's http://www.sbf5.com/~cduan/technical/git/ for convenience.
... aaaaand HN is busted, and won't update the post when I try to edit that to fix the link.
That's http://www.sbf5.com/~cduan/technical/git/ for convenience.
I think if you spend more then 5 hours a week coding you should definitely get in depth knowledge. Git is different from classical version control system, which makes it hard to learn (e.g., why first commit and then push?) But when you get the hang of it most of it actually makes sense and you start to become more productive with git then you have ever been before. The trick is not to stop learning before you get about 80% of what's out there in your head.
People who spend less then 5 hours a week coding probably don't need git and I think it's stupid that people replace SVN everywhere with git. Git's power is the power user and the shell. I can only suggest to use GUI tools in that case. They don't allow you to do anything but its harder to break things as well. The problem here is not git though. At least not in my mind. The problem is that many people who don't know git very well try to apply it to use cases which are not git's strength.
In any case your concerns are valid. If I disagree at all it's with the path to solution.
People who spend less then 5 hours a week coding probably don't need git and I think it's stupid that people replace SVN everywhere with git. Git's power is the power user and the shell. I can only suggest to use GUI tools in that case. They don't allow you to do anything but its harder to break things as well. The problem here is not git though. At least not in my mind. The problem is that many people who don't know git very well try to apply it to use cases which are not git's strength.
In any case your concerns are valid. If I disagree at all it's with the path to solution.
It's not exactly what you're asking for, but I wrote a blog post that details the steps for creating a repo and hooking it up to github - http://nycda.com/blog/how-to-create-a-git-repo/ - I cover two methods - creating a repo locally first and connecting it to github, and creating a repo on github first and cloning it so you have it locally (personally, I always do the latter - I think it's simpler, but for completeness' sake I included both)
This is good as well: http://www.win-vector.com/blog/2012/07/minimal-version-contr...
Shouldn't git add -A be used as default instead of git add . ?
Hmmm, I think you're right. That's less dangerous, especially when people don't really know what they're doing. I'll push an update.
That said . should be specified per manpages:
> If no <pathspec> is given, the current version of Git defaults to "."; in other words, update all files in the current directory and its subdirectories. This default will change in a future version of Git, hence the form without <pathspec> should not be used.
That said . should be specified per manpages:
> If no <pathspec> is given, the current version of Git defaults to "."; in other words, update all files in the current directory and its subdirectories. This default will change in a future version of Git, hence the form without <pathspec> should not be used.
An update to the advice is going up that will show `git add -A .` instead of `git add .` and explain:
> You can also type `git add -A .` where the dot stands for the current directory, so everything in and beneath it is added. The `-A` ensures even file deletions are included.
> You can also type `git add -A .` where the dot stands for the current directory, so everything in and beneath it is added. The `-A` ensures even file deletions are included.
I've always found the git CLI really odd. For example, when doing a git diff, how would anyone use the following information that gets printed out?
new file mode 100644
index 0000000..cfbc74a
And you have all of these symbols that show up in the diff like "+[m" before a new line (why not just +?). I imagine there are good reasons for all of this, but I also feel like some of this should be hidden behind a --verbose flag or something.
new file mode 100644
index 0000000..cfbc74a
And you have all of these symbols that show up in the diff like "+[m" before a new line (why not just +?). I imagine there are good reasons for all of this, but I also feel like some of this should be hidden behind a --verbose flag or something.
Because git-diff produces a full patch [1] that can be applied to a file. It's a lot more than just showing lines added/lines removed. The two hashes are useful because it shows what two objects are being compared. It's the same as saying "Change #12 vs Change #13" (not really, but sorta).
[1]: http://linux.die.net/man/1/patch
[1]: http://linux.die.net/man/1/patch
So the use case is primarily to produce something machine readable rather than human readable (it's not that unreadable, but still). I can see that. Is there a human-readable flag?
Do you mean you get '+[m' instead of '+' in front of an added line? If so, this looks suspiciously like ecma formatting escapes (\e[XXXm).
Try if calling git diff --no-color, if this helps then something is broken on your setup. Another way i could see that happening is if you have color set to 'always' and then use some app that wraps git's command line output.
Try if calling git diff --no-color, if this helps then something is broken on your setup. Another way i could see that happening is if you have color set to 'always' and then use some app that wraps git's command line output.
j2kun means the stuff that shows up from TFA when using git diff:
diff --git a/octocat.txt b/octocat.txt
index 7d8d808..e725ef6 100644
--- a/octocat.txt
+++ b/octocat.txt
@@ -1 +1 @@
-A Tale of Two Octocats
+[mA Tale of Two Octocats and an Octodogphaker is correct, that's just an escape sequence that the JS terminal didn't handle (or handled incorrectly). Using --no-color you get:
diff --git a/octocat.txt b/octocat.txt
index 7d8d808..e725ef6 100644
--- a/octocat.txt
+++ b/octocat.txt
@@ -1 +1 @@
-A Tale of Two Octocats
+A Tale of Two Octocats and an Octodog[deleted]
Having git emit, by default, a diff that can't reliably be used by git to patch another repository seems ill advised.
Looks good. Another option:
https://www.git-tower.com/learn/ebook
I'm no designer but I would move the 'Advice' section to the top of the page below the command. I didn't notice the lower right hand side of the screen kept changing.
I feel like I was just doing what I was told rather than learning. Is this more for individuals with SCM experience or beginners?
I feel like I was just doing what I was told rather than learning. Is this more for individuals with SCM experience or beginners?
Absolute beginners.
Our advice box is something for people who want to learn more, it's not essential enough to be below the command before the output.
Our advice box is something for people who want to learn more, it's not essential enough to be below the command before the output.
On an iPad, I just get a blank white screen... Does the site use flash, or is there a problem right now?
We released this on July 4th 2012. I can't remember if we tested it for tablets & phone but generally I recall the jQuery Console plugin not being too fond of either. It's only more recently that console/editors have become more responsive to different environment/viewports.
To summarize, this is not a load problem, it looks like a display bug. We'll look into it but I can't promise this will work on your iPad anytime soon, sorry.
To summarize, this is not a load problem, it looks like a display bug. We'll look into it but I can't promise this will work on your iPad anytime soon, sorry.
No problem; I finally had time to open it up on my laptop, and it works fine in Chrome and Safari. I understand not doing any major updates for mobile/tablet users, but if would be nice to at least be able to see something :)
Found the bug. I did a maintenance update of jQuery on April 29th and they removed a (bad) $.browser method we used for some reason. Reverted and deploying so it should work on iOS from now on. Give it 5 minutes for the soft restart to kick in.
Looks like it has to do with the fade in we do on page load. I'll try to see if I can do a quick fix because it's kind of a silly reason for it not to work. :-)
What the heck is an octobox? Do you really want a git tutorial to use github-specific terms like that?
GitHub sponsored it, and I like picking fun examples. Is that so offensive?
It would be nice to explain what it means. Try googling "octobox" :)
After some consideration and re-reading the copy, you folks are right that people could be confused into thinking the word "octobox" is somehow a git concept or something important. I rephrased all the instances where we mention it in order to highlight the fact that we "decided" to name our directory that way. I think it should prevent confusion from now on.
Thanks a lot for the feedback. :-)
Thanks a lot for the feedback. :-)
That's great, thanks. I'm sharing it now.
It would be hard because it doesn't mean anything, it's just a name. I don't know, seems natural that one of our support docs about Try Git is the first result on Google for me. :-)
I get a bunch of lighting umbrellas: http://www.amazon.com/Interfit-INT484-36-Inch-Octobox-Softbo...
[deleted]
Cool for learning Git. However, not that great for the first time somebody uses a version control system.
Does anybody have a good tutorial for "Code Version Control for Dummies (while using Git)"?
Does anybody have a good tutorial for "Code Version Control for Dummies (while using Git)"?
We used this tutorial at a Girl Develop It workshop last year. It worked really well! I also learned jQuery via Code School on my own time the year before that. Keep up the good work!
Just sent this to a new co worker who just got into her first programming job. It's a great resource that helped me when I was starting.
Found this a really useful introduction to Git, thanks!
Glad you think so Mike. Did you have version control experience or Git experience prior to it?
Nice tool. I keep suggesting it to people wanting to learn git.
http://pcottle.github.io/learnGitBranching/?demo
I found the try.github.io tutorial very underwhelming -- it emulates enough of git to just fall into the uncanny valley. I also prefer visual learning -- hence I made the above!