7 ms·

Try Git

140 points by Ethan_Mick 12y ago

gsands 12y ago
"So now that octodog is part of the family, octocat is all depressed. Since we love octocat more than octodog, we'll turn his frown around by removing octodog.txt." Interesting analogies they use in the tutorial.
- minot 12y ago
  If anyone from Github is reading, I'd change > Since we love octocat more than octodog, we'll turn his frown around by removing octodog.txt. to > Since we love octocat more than we love octodog, we'll turn his frown around by removing octodog.txt.
- olivierlacan 12y ago
  I confess: pro-cat propaganda was sneakily inserted in Try Git.
vog 12y ago
I like it that the command line is a bit "realistic" but allowing to get the last command via arrow-up. Unfortunately, there is no tab autocompletion, which makes it really a hassle to enter "git add [specific file]" and similar commands. I also like the idea of simulating the timing, such that the commands don't always return immediately. However, I'm a bit surprised about the exact timing values. For example, "git init" took quite some time while "git status" was really quick. In reality, it is the other way around.
- Gazler 12y ago
  I wrote something a few years ago that does a similar thing using a real command line. https://github.com/Gazler/githug https://github.com/Gazler/githug
- blaze33 12y ago
  > a hassle to enter "git add [specific file]" `git add .` worked as well and clicking the command autoenters it at the prompt.
- insertnickname 12y ago
  Maybe it's just slow... `git status` should be quick in an empty repo.
- farnsworth 12y ago
  It's all very slow for me right now - every command hits the server, which is disappointing.
- tsm 12y ago
  The truth is both are blazing fast, but at least on my machine git status is a hair faster: $ mkdir baz $ cd baz $ time git init Initialized empty Git repository in ~/src/tmp/baz/.git/ real 0m0.015s user 0m0.002s sys 0m0.008s $ time git status # On branch master # # Initial commit # nothing to commit (create/copy files and use "git add" to track) real 0m0.012s user 0m0.002s sys 0m0.003s
  - joelg236 12y ago
    Interestingly, for me git init took 0.045s, while status took 0.005s. I wonder what factors into this.
    - TimWolla 12y ago
      For an existing repository: Size of the repository, as well as the number of files in the folder. A single git status on a 1.7GB git repository takes about 9 seconds with a warm disk cache on my workstation.
nmc 12y ago
Nice! This strongly reminds me of: http://pcottle.github.io/learnGitBranching http://pcottle.github.io/learnGitBranching
s-macke 12y ago
When I see such a tutorial I am always thinking of those online Linux emulators. You can write tutorials for such terminal programs and use those emulators for real examples.
daok 12y ago
Interesting but quite limited. In most case you will need to get information about conflict, complex merging scenario, squashing, rebasing, etc. This is a nice intro, but would be more complete with more real life scenario. For those that do not want to type, you can click the command and it will writes it into the console for you.
- weaksauce 12y ago
  This was built by code school and sponsored by github... if you want more advanced git tutorials, code school offers them for some money.
zaidf 12y ago
Thing about git is that it is relatively easy to get started and harder to learn the more "advanced" stuff. This isn't always true with other technologies because once you get started, you can figure out the advance stuff incrementally. Not true for git in my experience because even if you know the basics of having a branch, committing, pushing it can take a while to really understand how merges, branches, conflicts work.
- solutionyogi 12y ago
  It depends. If you don't know the git data model (DAG) and learn it by using commands, you have to explicitly learn the 'advanced' stuff. If you learn the git data model and fully understand how everything is simply a DAG, there is nothing advanced about it. However, grokking the git data model may take sometime.
_kst_ 12y ago
Interestingly, when I did a "git commit" with a different commit message than the one they provided, a following "git log" showed their canned message, not the one I used. (Not surprisingly, they're not really giving you shell access.)
lloydde 12y ago
I tried unsuccessfully to find the repo and issue tracker for try.github.io at https://github.com/codeschool?query=git https://github.com/codeschool?query=git and https://github.com/github?query=git https://github.com/github?query=git . 1) I don't think providing the message (-m) on the command line is a good habit for beginners. 2) https://try.github.io/levels/1/challenges/7 https://try.github.io/levels/1/challenges/7 is a wild card operation followed by a `commit -m`. Prior to the commit there should be another `status` or interactive commit (no -m), see (1) above.
- olivierlacan 12y ago
  The current version of Try Git isn't open-sourced. You can contact us (Code School) directly to report any issues: http://www.codeschool.com/support http://www.codeschool.com/support 1) That's true. Although sending beginners into a less/vi commit interface that is even more bewildering than the basic shell is not a good way to concisely introduce people to a new tool. The hardest part of teaching is what you chose not to teach. 2) We purposefully used the GUI file browser (My Octocat Repository) at the bottom to avoid having to systematically do `git status` in order to check the state of the repo.
  - ibrahima 12y ago
    Hmm, yeah, I always felt that was weird as a default since most beginners probably don't know vi/vim. Now I have to wonder why the default doesn't just take input on stdin for the commit message. Well, I guess you lose the ability to edit previous lines so maybe that's it. I guess nano as a default would probably be reasonable.
  - lloydde 12y ago
    > 2) We purposefully used the GUI file browser Adding this artificial element furthers concisely introducing people to a new tool? If you are going to teach a CLI then stay in the command line. Also, you didn't solve the problem as the GUI file browser doesn't show the status of the files either.
  - JoshTheGeek 12y ago
datamatt 12y ago
As nice as this tutorial is, I don't think git is ever really going to have widespread appeal outside of (semi-)professional SWEs who are forced to use it due to community size and ubiquity. The commands are simply too badly thought out and the staging, pushing, pulling, merging process is too complex. E.g. want to switch branches? git checkout. Wtf why not "git switch-branch" or something. Want to send your code to the master? Is it git push? git pull? Well, its sort of both but hey.
- minot 12y ago
  Please have your people try SourceTree[1]. It has a beautiful interface on the mac (Windows version is a little behind). It is backed by Atlassian, the makers of JIRA and Confluence so you know it won't just go away tomorrow. If your people are scared of the terminal for some reason, SourceTree is a good place to get them started using Git. [1] http://www.sourcetreeapp.com/ http://www.sourcetreeapp.com/
shurcooL 12y ago
Personal story. I remember there was a time where "learning how to use git" was something I really wanted to do for a _long_ time but never committed to it. Running into this online tutorial, as limited as it may be, was the day I said "that's it, I'm gonna learn how to use git." I was successful. It was just enough of a push that I needed at the time.
- olivierlacan 12y ago
  Thanks so much for sharing this. I wrote Try Git with a lot of help from my co-workers at Code School and Matthew McCullough from GitHub. Knowing it impacted just one person the way it impacted you makes me incredibly happy.
  - shurcooL 12y ago
    Happy to share. Thank you for making it! I'm pretty sure I've mentioned this to John Britton at one of GitHub meetups. He played some part in making that from the GitHub side, as he does education stuff with them. That was about 3 years ago. Since then I've got a nice software engineering job in San Francisco, and I've been trying to make as many open source contributions in my free time as I can: https://github.com/shurcooL https://github.com/shurcooL 1,737 total in year of contributions (not counting private) hehe. Learning to use git was an eventual step of the journey, but your work certainly played a part in enabling all that, so thank you. :)
tomjakubowski 12y ago
I suppose this poor fellow won't be able to use GitHub Pages. https://github.com/Try https://github.com/Try
- JoshTheGeek 12y ago
  I've wondered for a while how they deal with situations like that. For instance, when they implemented stars, there was likely a user named stars, but then they reserved /stars for their new feature, presumably removing that user. I just wonder if they emailed the user and said, Hi, we need your username for a new feature. Thanks, GitHub.
dang 12y ago
https://news.ycombinator.com/item?id=7709173 https://news.ycombinator.com/item?id=7709173
magd 12y ago
The app doesn't work. I typed "git init" and it did nothing.
- magd 12y ago
  It has problems with mac/chrome.

140 points by Ethan_Mick 12y ago

"So now that octodog is part of the family, octocat is all depressed. Since we love octocat more than octodog, we'll turn his frown around by removing octodog.txt." Interesting analogies they use in the tutorial.

minot 12y ago
If anyone from Github is reading, I'd change > Since we love octocat more than octodog, we'll turn his frown around by removing octodog.txt. to > Since we love octocat more than we love octodog, we'll turn his frown around by removing octodog.txt.
olivierlacan 12y ago
I confess: pro-cat propaganda was sneakily inserted in Try Git.

vog 12y ago

I like it that the command line is a bit "realistic" but allowing to get the last command via arrow-up. Unfortunately, there is no tab autocompletion, which makes it really a hassle to enter "git add [specific file]" and similar commands. I also like the idea of simulating the timing, such that the commands don't always return immediately. However, I'm a bit surprised about the exact timing values. For example, "git init" took quite some time while "git status" was really quick. In reality, it is the other way around.

Gazler 12y ago
I wrote something a few years ago that does a similar thing using a real command line. https://github.com/Gazler/githug https://github.com/Gazler/githug
blaze33 12y ago
> a hassle to enter "git add [specific file]" `git add .` worked as well and clicking the command autoenters it at the prompt.
insertnickname 12y ago
Maybe it's just slow... `git status` should be quick in an empty repo.
farnsworth 12y ago
It's all very slow for me right now - every command hits the server, which is disappointing.
tsm 12y ago
The truth is both are blazing fast, but at least on my machine git status is a hair faster: $ mkdir baz $ cd baz $ time git init Initialized empty Git repository in ~/src/tmp/baz/.git/ real 0m0.015s user 0m0.002s sys 0m0.008s $ time git status # On branch master # # Initial commit # nothing to commit (create/copy files and use "git add" to track) real 0m0.012s user 0m0.002s sys 0m0.003s
- joelg236 12y ago
  Interestingly, for me git init took 0.045s, while status took 0.005s. I wonder what factors into this.
  - TimWolla 12y ago
    For an existing repository: Size of the repository, as well as the number of files in the folder. A single git status on a 1.7GB git repository takes about 9 seconds with a warm disk cache on my workstation.

nmc 12y ago

Nice! This strongly reminds me of: http://pcottle.github.io/learnGitBranching http://pcottle.github.io/learnGitBranching

s-macke 12y ago

When I see such a tutorial I am always thinking of those online Linux emulators. You can write tutorials for such terminal programs and use those emulators for real examples.

daok 12y ago

Interesting but quite limited. In most case you will need to get information about conflict, complex merging scenario, squashing, rebasing, etc. This is a nice intro, but would be more complete with more real life scenario. For those that do not want to type, you can click the command and it will writes it into the console for you.

weaksauce 12y ago
This was built by code school and sponsored by github... if you want more advanced git tutorials, code school offers them for some money.

zaidf 12y ago

Thing about git is that it is relatively easy to get started and harder to learn the more "advanced" stuff. This isn't always true with other technologies because once you get started, you can figure out the advance stuff incrementally. Not true for git in my experience because even if you know the basics of having a branch, committing, pushing it can take a while to really understand how merges, branches, conflicts work.

solutionyogi 12y ago
It depends. If you don't know the git data model (DAG) and learn it by using commands, you have to explicitly learn the 'advanced' stuff. If you learn the git data model and fully understand how everything is simply a DAG, there is nothing advanced about it. However, grokking the git data model may take sometime.

_kst_ 12y ago

Interestingly, when I did a "git commit" with a different commit message than the one they provided, a following "git log" showed their canned message, not the one I used. (Not surprisingly, they're not really giving you shell access.)

lloydde 12y ago

I tried unsuccessfully to find the repo and issue tracker for try.github.io at https://github.com/codeschool?query=git https://github.com/codeschool?query=git and https://github.com/github?query=git https://github.com/github?query=git . 1) I don't think providing the message (-m) on the command line is a good habit for beginners. 2) https://try.github.io/levels/1/challenges/7 https://try.github.io/levels/1/challenges/7 is a wild card operation followed by a `commit -m`. Prior to the commit there should be another `status` or interactive commit (no -m), see (1) above.

olivierlacan 12y ago
The current version of Try Git isn't open-sourced. You can contact us (Code School) directly to report any issues: http://www.codeschool.com/support http://www.codeschool.com/support 1) That's true. Although sending beginners into a less/vi commit interface that is even more bewildering than the basic shell is not a good way to concisely introduce people to a new tool. The hardest part of teaching is what you chose not to teach. 2) We purposefully used the GUI file browser (My Octocat Repository) at the bottom to avoid having to systematically do `git status` in order to check the state of the repo.
- ibrahima 12y ago
  Hmm, yeah, I always felt that was weird as a default since most beginners probably don't know vi/vim. Now I have to wonder why the default doesn't just take input on stdin for the commit message. Well, I guess you lose the ability to edit previous lines so maybe that's it. I guess nano as a default would probably be reasonable.
- lloydde 12y ago
  > 2) We purposefully used the GUI file browser Adding this artificial element furthers concisely introducing people to a new tool? If you are going to teach a CLI then stay in the command line. Also, you didn't solve the problem as the GUI file browser doesn't show the status of the files either.
- JoshTheGeek 12y ago

datamatt 12y ago

As nice as this tutorial is, I don't think git is ever really going to have widespread appeal outside of (semi-)professional SWEs who are forced to use it due to community size and ubiquity. The commands are simply too badly thought out and the staging, pushing, pulling, merging process is too complex. E.g. want to switch branches? git checkout. Wtf why not "git switch-branch" or something. Want to send your code to the master? Is it git push? git pull? Well, its sort of both but hey.

minot 12y ago
Please have your people try SourceTree[1]. It has a beautiful interface on the mac (Windows version is a little behind). It is backed by Atlassian, the makers of JIRA and Confluence so you know it won't just go away tomorrow. If your people are scared of the terminal for some reason, SourceTree is a good place to get them started using Git. [1] http://www.sourcetreeapp.com/ http://www.sourcetreeapp.com/

shurcooL 12y ago

Personal story. I remember there was a time where "learning how to use git" was something I really wanted to do for a _long_ time but never committed to it. Running into this online tutorial, as limited as it may be, was the day I said "that's it, I'm gonna learn how to use git." I was successful. It was just enough of a push that I needed at the time.

olivierlacan 12y ago
Thanks so much for sharing this. I wrote Try Git with a lot of help from my co-workers at Code School and Matthew McCullough from GitHub. Knowing it impacted just one person the way it impacted you makes me incredibly happy.
- shurcooL 12y ago
  Happy to share. Thank you for making it! I'm pretty sure I've mentioned this to John Britton at one of GitHub meetups. He played some part in making that from the GitHub side, as he does education stuff with them. That was about 3 years ago. Since then I've got a nice software engineering job in San Francisco, and I've been trying to make as many open source contributions in my free time as I can: https://github.com/shurcooL https://github.com/shurcooL 1,737 total in year of contributions (not counting private) hehe. Learning to use git was an eventual step of the journey, but your work certainly played a part in enabling all that, so thank you. :)

tomjakubowski 12y ago

I suppose this poor fellow won't be able to use GitHub Pages. https://github.com/Try https://github.com/Try

JoshTheGeek 12y ago
I've wondered for a while how they deal with situations like that. For instance, when they implemented stars, there was likely a user named stars, but then they reserved /stars for their new feature, presumably removing that user. I just wonder if they emailed the user and said, Hi, we need your username for a new feature. Thanks, GitHub.

dang 12y ago

https://news.ycombinator.com/item?id=7709173 https://news.ycombinator.com/item?id=7709173

magd 12y ago

The app doesn't work. I typed "git init" and it did nothing.

magd 12y ago
It has problems with mac/chrome.