Got 15 minutes and want to learn Git?
try.github.com
An in-browser github tutorial powered by codeschool
try.github.com
I have no clue how to use Git, and I've been trying to wrap my head around it for a while. Unfortunately, this is yet another tutorial that is very frustrating even though it's designed to target noobs like myself.
So, I added octocat.txt to my staging area. Success! ... Wait. Why do I care? What did I do? Staging what, for what? Huh?
I committed some random text. Or something. And I typed "-m". So does "git commit -m 'something random'" actually do something? What did I commit to? Arrrggg. Why did I -m !?
Then there's this one: git commit -m 'Add all the octocat txt files'
So it understands plain English? Was that the random text? Is that just some sample text as part of the Tutorial or does that actually work on Git? Oh man, I'm now more confused than when I started.
...
Anyway, for some reason, everyone who tries to describe Git already has such a strong understanding of it and it's oddities, that they are, for some reason, unable to lay it out properly for a noob IMO. I cannot figure out how anyone figures out Git, I assume there was some serious hand holding, because I'm just not grasping it and I usually "get" this stuff rather quickly. Maybe that's the problem, Git isn't something you can just pick up quickly, maybe I need to buy a huge Git how-to book like the old days.
Sincerely, Frustrated in Programming Land.
For a more in-depth guide, check out the Pro Git book @ http://git-scm.com/book. You can read it online for free.
I'm not going to post link to yet another git tutorial. I would rather recommend to start with something like Heroku, Appharbor or similar.
It is the problem, I think. Git isn't easy to use. It's a powerful tool designed by a very smart person (Linus) to manage a very complex project (the kernel). It's not a toy, and it's not designed for beginners. On top of that, the interface actually isn't that well designed, and is a pretty leaky abstraction layer that in many cases requires you to have some understanding of its internals [1]. But we're programmers, our work isn't always easy and the benefits of using Git or using any distributed version control system outweigh the alternatives (note that I'm not talking about Git vs Mercurial vs Darcs but rather about the previous generation of supposedly easier tools like SVN and CVS). So I really think it's worth struggling to master it and treat it like a first-class tool, that you're going to invest in because it's important, rather than try to find an easy way out.
I'm projecting on to you a little bit, and I apologize for that, but every time a Git tutorial hits the front page of HN, there are people expressing frustration or complaining that Git is too hard or too complex. Yeah, it's not perfect, but honestly, it's a damned good tool, and I think it's absolutely worth investing in. Most things worth learning are hard, and while that's not an excuse for poor tutorials (no comment on this one as I haven't tried it), I don't think programmers who take their profession seriously have much to excuse what seems like our almost constant desire for things to be easy.
Maybe the next generation of version control will be easier to use and have a more beautiful user interface, but Git is here now and there's an ecosystem around it supported by the network effects of its popularity, and I think that does end up outweighing the difficulty.
[1] That said, I think the inner core of its internals, ie representing revision history as a DAG of commits, is actually relatively simple, despite the poor interface. See this for what I think is one of the best intros to Git: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
I think git is a good fit for people who find version control theory interesting, a endeavor in itself, or have complex workflows. For the rest of us, who simply need to work together (sometimes offline) with multiple synced backups, the complexity of git is too much.
Hg, for its flaws, keeps the simple things simple. I think the constant push from above to use git is a disservice, and I wonder if there will be a backlash at some point.
The funny thing about Mercurial and Git is that they build on top of the same core concepts:
hg to git took several weeks, and I'm still learning.
I prefer git's handling of branches; hg never deletes a branch, just "closes" it, so you're left with a lot of mess if you do a great deal of branching. Other than that, I prefer hg.
In Git, these changes are called "commits".
Commits contain a change a user has made to the code and some additional useful metadata. This metadata includes the time the change was made, the user's name, a message to describe in general terms what the change was (that -m thing), and so on.
Git itself is a database that stores these commits. Each commit links back to the change before it, forming a chain.
If a single person is working on a project, this may be a linear chain of commits, but if multiple people are working on the same project, two people might make a change to the same text at the same time.
So maybe one person writes "The Nexus 7 costs £159", and another person writes "The Nexus 7 costs $199". If this happened, the chain would split; you'd have two valid changes made to the same text. The act of reconciling these chains is called a "merge". We might choose to use one version or the other, or to combine the two, such as "The Nexus 7 costs $199 (£159)".
That's basically it. The only other thing Git does is to allow you to give commits a human-readable name so you can refer back to them later.
Go ahead and try explaining a rebase without trying to broach the concepts of time travel. How about why having a local copy of all commits/branches/etc related to the repository is helpful, or even at all possible, without relating it to a simpler client/server version control system.
A project can be described in terms of the changes users make over time, and that lets us undo any previous changes all the way back to the beginning of the project.
I don't think that explanation is overly technical or difficult to understand, and the generic features of version control which you dismiss are precisely those that make it most useful - the above paragraph in my opinion encapsulates most of what is useful about a VCS. To extend the above to cover a rebase:
A rebase is just merging other people's changes with yours, so that you end up with a merged version of the files, but with details that mean it looks slightly cleaner in histories - it's not even something many people will ever have to do. As to why having a local copy is useful, who cares, it's a detail of how the VC works?
This really is not rocket science - while git can at times be frustrating if you hit a particular problem which it doesn't consider important like expunging files from history, the basics are very very simple. You really only need 3 commands for day to day use:
git pull (get other people's changes)
git push (send your changes to others)
git commit (commit a change to your local copy)
A rebase is the act of changing the parent, or base, of a commit. So instead of a change being made to version A, you make the same change to version B. No time travel metaphors need to be involved, and IMO only complicate a very simple concept.
The harder part is explaining why you'd want a rebase.
The section on commit explains what the '-m' option is:http://gitref.org/basic/#commit
It was too much of a learning curve to figure out how to deal with this change where Git was concerned, so i went back to mercurial which has a windows client and is easy enough to get my head round.
I do think that Git is probably more powerful as i see it in much more use in production out there, and at a guess i imagine that for version control it's probably more dependable and reliable than Mercurial - im not really qualified to say - but right now, i'm sticking to mercurial because at least i can wrap my head around it, and that's what matters, for now.
The explanation is given for both centralized version control systems, using SVN, as well as for distributed version control systems, using Mercurial and Git (and Veracity).
Give it a try. The digital editions (PDF/EPUB/MOBI) are free for download I think.
These are pretty good. It's when I saw these that I realized everything in git is named poorly:
http://marklodato.github.com/visual-git-guide/index-en.html http://ndpsoftware.com/git-cheatsheet.html
It would be interesting to read articles about how a single programmer uses Git, how a small programming team, how a distributed team uses Git. Similar articles about how a team producing art, or text (not programmers) use Git.
There's plenty of Git command tutorials already; let's hear about how you actually use Git.
Take Vim for instance. When I first got to it, I found only resources that are paraphrased with "this command does that. that command does that... nth command does that". Now, if only someone described buffers, tabs and windows to me (like in an article that was recently linked to here on HN), or told me that commands can be described as acronyms of verbs and nouns etc. I'd be much more proficient with Vim now.
For Node.js, I found some talks/presentations from its creator that really hit this spot.
I still haven't found anything like that for Git.
Mind sharing the specific ones which worked for you?
> I still haven't found anything like that for Git.
I shared a nice conceptual tutorial about git in a reply in another comment of the same thread. Here it is, http://news.ycombinator.com/item?id=4200426
Here it is http://youtu.be/M-sc73Y-zQA. He got cocky later on, so I don't like very much his presentations of a later date. In this one, he's pretty nervous on occasions. It's cute. :)
I just glanced at the git tutorial provided - it seems it is up my alley. Will check it out later on.
And just in-case I came across as an asshole, I liked your post and thought it was great :)
http://betterexplained.com/articles/intro-to-distributed-ver...
The idea is to build a mental model about what is possible vs. memorizing a bunch of specific commands. Once I wrapped my head around the concepts, the commands fell into place.
On my screen the text is light gray on white. Is that intentional?
Which browser were you using? (I just tried FF, Chrome, Safari) Thanks!
The staging area (aka the index) is where you put things before they become a commit. You don't always want to commit all of your changes at once. The index is there so you can commit the changes you want instead of just committing all the changes every time.
`git commit` means "turn the contents of the index into a commit". A commit is a set of changes that logically go together denoting a version of the repository. A commit needs to have a message describing what the commit does. If you just type "git commit", it opens up an editor for you to type in your commit message. If you want to skip the editor, you can just pass in the -m flag, followed by your commit message in quotes.
Are you familiar with the shell? Are you comfortable with the concept of a linked list? If not, work on those--even if you don't use Git, it's part of being a better programmer. But if you do understand these things, you can fairly easily get a very deep understanding of Git.
You first call it a staging area and then you clarify with an "index," but you never clarify what an index is?! The second paragraph doesn't improve the situation much.
Ultimately I think there is a language breakdown here. People who explain Git seem to be unable to do so without using Git-language, and it is very difficult to understand the Git-language without understanding how it is used.
So therefore it is a chicken/egg problem. You somehow need to know the language to understand Git, but to understand the Git you need to understand the language.
PS - I know you're trying to help; it is just one of those things where I am not even sure it can be explained in that way.
In any case, a staging area only makes sense in the context of trying to create a commit, and I think I did usefully define what a commit is. Maybe that part should have come first.
A Version Control System is a software system that uses files to save different versions of your source code (really, it can save any file, but it works best with source code). The system also lets you revert back to an old version of your code, so you can try something radical out on your code knowing that you have a safe version tucked away in your version control system.
A 'commit' is when you tell the VCS to take a "snapshot" of your files and then save that in its system. Git implements 'commits' with three-location system: the working index (the files on your computer), the staging index (Git's log of what files you want to change), and then the actual commit index (where all the versions are saved). When you stage a file, you tell Git to add the name of that file to it's internal log, telling Git that you want that file to be saved in a version. After you have told Git what files to save (by "staging" them), you can commit (with 'git commit') to save that snapshot of your staged files. Later on, you can revert to the snapshot through git commands.
Hope this helps!
Place yourself in the shoes of a subversion user, the workflow is very simple and intuitive given that:
1. the repository is a (remote) place where my project is stored
2. the local copy is where I modify my project
Now, with git you don't have a remote repository. Your local copy is itself a repository. Think about this for a second. Then...
If a commit doesn't push my changes to a remote repository, why do I care?
Well, if a commit allows me to have a local history of changes that I may not want to have in the remote repository, why do I need to stage my changes? Why don't I just commit them and be done with that? Isn't the files themselves a stagind area? Isn't this all redundant?
These are the problems a non-Git user faces. Why do I care about this complexity? In what whay does this make the process of making my changes accessible to others easier?
Answer: it doesn't.
Regular people are usually perfectly happy with their other VCS solutions. The ones that want them to see the light and start using Git for all its benefits must thing about what makes Git useful and explain that.
It doesn't matter that Git is important for large distributed projects. Most people aren't a part of large distributed projects.
No tutorial that I can remember does this. Not a single one.
I use TortoiseSVN, I'm not sure if you do. But when I want to commit in SVN, I bring up the commit tool, select the files I want to commit, write a message in the box, and click commit. But I have to do it all in one go. I can't close the commit window if I forget something, otherwise I have to make sure I copy out the message to paste in again, select all the files.
With Git, the staging area is the same as this commit box. It's just a bit more stretched out. Instead of selecting files to commit, and doing it then, you add files to the staging, and commit the staging area. It's a different way of doing it, but I've found it much better for myself. Instead of doing it all in one go, I can add to staging and keep working. Usually I keep open all the files that have changed so I remember which ones to add.
Regarding the remote repository, you still can have it remote. Simply instead of "commit" being the last action you do to push it to the remote repo, make sure "git push" is. I use bitbucket for this, so I know it's "safe" in case of computer death or something.
I have one more project using SVN and I want to move it to Git, for just me, I don't work in a team or anything like that. I like the staging area, it feels "lighter" and that commits are much less drastic, and diffs/logs are MUCH faster since it's all on your computer. Also, `git add -p` to craft your own commits.
Because you don't always want to commit every change you've made or every new file you've added.
> If a commit doesn't push my changes to a remote repository, why do I care?
If I have my code in a working state, I'd like to save that "version" somewhere, so I can make a whole bunch of changes without worrying about whether or not I can get back to a working state. This is true even if no one else in the world has to read my code. This is the entire rationale of version control in the first place! But if I can do it just on my own individual changes, that means I can go back to a closer savepoint and not have to play the whole level over again if I screw up ;)
> Well, if a commit allows me to have a local history of changes that I may not want to have in the remote repository, why do I need to stage my changes? Why don't I just commit them and be done with that? Isn't the files themselves a stagind area? Isn't this all redundant?
No, because you still don't always want to commit every change you've made or every new file you've added!
Maybe you want to commit while you have Vim open but you don't want to add a bunch of garbage .swp files to your repo. Maybe you did two or three different things that aren't related, so you want them to show up as two or three different commits in the history.
From the perspective of a Subversion or Perforce user, it's not something you really think about because it's not even an option that you have. You effectively don't even have version control on your own machine. Your company has version control, but you don't. And in my personal experience as a Subversion or Perforce user, I frequently feel lost at sea in that environment because it's virtually impossible for me to reliably do things like:
1. Get back to a working state newer than the one I checked out of the repository after making lots of changes everywhere.
2. Make completely unrelated code changes at the same time without mixing the changes together. Maybe one change is blocking on a code review. Maybe I found an unrelated bug and want to fix it separately from whatever other changes I'm making. Maybe I'm second-guessing a certain feature addition and want to put it on ice while I do other things. Maybe someone reported a bug and I want to fix it separately from what I happen to be working on at the time. Whatever the reason, it can live in its own branch and I can come back to it later. I don't have to create duplicate workspaces in my file system, Git just manages it for me.
3. Turn a large, complicated code change into a series of smaller changes, each with its own diff and description which I can review more easily.
These are things I do every day. I would do them if I shared my code with a small team or with the entire world. I would do them if I shared my code with no one at all. Git isn't just for large distributed projects. It's for decoupling version control from version sharing or version verification.
In practice, the purpose of something like Subversion or Perforce isn't to help you as a programmer, it's to help the canonical owner of the code you're working on to do certain things, like rollback to past versions or make policies that your code has to pass code review or something before you can "check it in". Git handles all that too--some of it more effectively--and it has the added feature that even you the programmer can get the benefits of version control, too.
> No tutorial that I can remember does this. Not a single one.
The purpose of a tutorial is to help someone learn how to use Git. If you're not interested in learning how to use Git, why are you reading tutorials? It would be much easier to just start a flame war on Hacker News and wait for someone knowledgable to respond. I guess you figured that out yourself.
Here, let me help you, from the examples section of `git help stash`:
"Testing partial commits You can use git stash save --keep-index when you want to make two or more commits out of the changes in the work tree, and you want to test each change before committing:
# ... hack hack hack ...
$ git add --patch foo # add just first part to the index
$ git stash save --keep-index # save all other changes to the stash
$ edit/build/test first part
$ git commit -m 'First part' # commit fully tested change"
It's literally called "git stash".
Aside from that, you can squash commits together after-the-fact. If it makes it any easier, you can squash a whole branch together all at once before pushing it out to other people. No one need be the wiser. The intermediate commits can just be temporary savepoints for your personal convenience.
The point is about convincing people to use Git by pointing them to tutorials and have them come back with blank stares and "why do I need this exactly?" questions.
Here's some problems I encounter everyday that git solves and SVN for instance doesn't.
1) I've been working on a feature since this morning but now there's a bug in production. I need to drop what I'm doing and come back to it when the bug is fixed.
2) I've implemented a feature but before I share it I want do some refactoring to clean it up. If I break something during the refactoring I want to be able to get back to the version that was working.
3) I'm working on integrating an old web API (SOAP hell) and I want to make a note of the workaround which is spread across several files. My tests aren't passing yet though so I don't want to share any code yet.
These are some examples of scenarios where git fits with _your_ workflow. This is where git really shines, not in the sharing of code (where it does also improve on SVN), but the ways in which it allows you to organise the pieces of code you're working on throughout your day.
Some guy at Harvard wrote a great tutorial[1] on understanding git conceptually. It has been on of the best git tutorials I have read myself.
[1] Understand Git Conceptually - http://www.eecs.harvard.edu/~cduan/technical/git/
Git is a simple, but extremely powerful system. Most people try to teach Git by demonstrating a few dozen commands and then yelling “tadaaaaa.” I believe this method is flawed. Such a treatment may leave you with the ability to use Git to perform simple tasks, but the Git commands will still feel like magical incantations. Doing anything out of the ordinary will be terrifying. Until you understand the concepts upon which Git is built, you’ll feel like a stranger in a foreign land.
The following parable will take you on a journey through the creation of a Git-like system from the ground up. Understanding the concepts presented here will be the most valuable thing you can do to prepare yourself to harness the full power of Git. The concepts themselves are quite simple, but allow for an amazing wealth of functionality to spring into existence. Read this parable all the way through and you should have very little trouble mastering the various Git commands and wielding the awesome power that Git makes available to you.
http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...
P.S. And the only way to get better with it after you learn is to use it everywhere. Which is a good idea anyway, because version control is incredibly useful.
This is a common problem in teaching, technical writing, and other forms of technical instruction.
Even when a good teacher or writer sets out to deliver material to total beginners, it's very tricky to truly enter the beginner's mindset and cast away a lot of the mental abstractions built up over the years.
I think one way to improve this situation is to focus on results and casually use features and techniques along the way rather than focus on features and techniques and have contrived examples to show off them off. The fewer technical terms or domain specific language you can use up front, the better. (I should note I've been very guilty of the contrived example approach, but this is what it's all about.. experimenting and learning what really works for learners :-))
Yes, exactly! You have to start with examples. Real problems and then suggest solutions. Too many teachers, I'd say the majority, start from the abstract explanation and only bring in the example in the end -if at all.
Good teaching shouldn't introduce too many concepts at one time, but giving incremental goals that require interacting with a few related concepts is ideal. Tediously spelling out all the details is good for a spec, but would hurt interest and motivation.
Hg is simpler than git in many ways. There's no "staging" for changes, so "commit" is just taking a snapshot of your files as they are right now. Simple.
And, since it's so simple, that means that you can write a really good tutorial for it, which Joel Spolsky did: http://hginit.com/01.html
Hg is plenty useful in its own right, and it doesn't really deserve to be training wheels for git as I've presented it here. But moving from hg to git is really easy; it makes git just seem like hg with a bunch more features.
Basically, git has a steep learning curve and people haven't found a good way to flatten it out a bit.
If you prefer a video, try "Getting Git" by Scott Chacon: http://vimeo.com/14629850
Coming from a Subversion & Perforce background, I was initially very confused by Git. There were two things that finally switched-on the old lightbulb for me:
a) Scott's book
b) Actively using Git for all of my personal projects (e.g. small school assignments and code experiments), without using a remote repository. If you defer learning about remote repositories for now, I'm sure the light will switch-on for you as well :)
I for one had a really hard time grasping Git, until I wiped my VC-mindset slate clean, it was primarily my upbringing in a development environment where Centralized Version Control was the king. I read up on Eric Sink's Version Control By Example. It's a great book to lay-out the fundamentals of Git. If you wrap yourself around the concept and not the tool, the use of tools (Git commandlines, Git GUI's) will come naturally.
It's specific to Mercurial, but git is very similar. If it's the overall concepts that are giving you trouble, that should be effective in removing those blocks.
The fact of the matter is that Git is incredibly powerful but also complex and hard to learn. This isn't a bash on Git at all. It's ok! Sometimes complicated things are just that, complicated.
I believe we'll have better guides and tutorials if people stop treating Git like it's easier or more simple than it actually is.
I use git personally to keep backups of my code and deploy sites I work on. I dont' work with other developers so my knowledge of git is workable, but probably super small.
Git gets complicated (but probably extremely useful) when working with bigger groups and tons of commits, branches and merges.
If you never need to merge, revert, or in general use any of the aspects of Git that make it special then it's totally reasonable to use something simpler like built-in OS versioning or a conceptually simpler VCS like SVN. But I guess there's no reason why Github would sponsor that, right?
Yeah, the Git command `revert` has a bunch of kind of esoteric flags, but once you understand that it can stomp on your working dir and/or your index, it's not that hard to use. I don't know what about reverting to a point prior to a merge would be difficult, unless you are in the middle of a merge at the time. Again, sounds like most trouble is caused by not understanding how to use what is a relatively powerful piece of software.
No one is stopping you from using the built-in OS versioning, SVN or Dropbox. IMO that would be a nightmare for anything beyond the most simple cases.
Designers can fix small things, like images, tweak html a bit etc. They dont need to know how to create/merge new branches etc..
I dont see that Git is trying to pretend that its simple but i can see how that interactive tutorial can be incredible useful to a lot of people.
this killed entire positive experience, in my view.
git checkout X
git checkout -b new-branch
git commit
git add; git mv; git rm;
git pull --rebase
git rebase origin/master
git push origin X
The problem is that people introduce the powerful features of Git that only a few percentage of people will ever use.
I strongly, strongly disagree with your assertion that "for simple cases Git is really simple to use and to learn". I've watched many programmers, artists, and designers who have used source control struggle with Git from day 1. I'm sorry, it's just not simple and if it were this topic wouldn't come up over and over and over.
Again, I say none of this as a slight to Git. Complicated things are complicated. That's ok, but pretending they aren't isn't helpful.
Git is a tool for programmers. There's no excuse for a programmer to be uncomfortable with the command line.
svn commit -m "Finally fixed bug #123!"
Tower.app is the only reason I've ever touched git, and the line-by-line staging and committing is nothing I would ever bother to do with a CLI.
I've known people in my team who can't do any work on the command line comfortably. I see this problem especially among people who work on Frontend and especially Java developers.
If a certain set of tools are making you dumber by the day, know it for sure that it will be automated or you will be replaced by lesser skilled cheap labor inevitably.
How does "not comfortable with the command line" translate to "dumber by the day?" If people get their training using IDEs and go on to be productive using primarily IDEs, how does being uncomfortable with the command line reflect on their intelligence in any way?
> know it for sure that it will be automated or you will be replaced by lesser skilled cheap labor inevitably.
Yes, the mundane, confusing use of the git command line is here to stay and the dumb "actually design and engineer an application" world of IDEs is going to be replaced by robots. You are a fucking genius. Only on the internet can such backwards and completely worthless logic be said because if you tried to say this shit to anyone in real life you'd be laughed out of the room.
I agree with you completely. Being familiar with the idiosyncrasies of the console does not make you smarter than people who aren't; you've just learnt different things.
You are a fucking genius. Only on the internet can such backwards and completely worthless logic be said because if you tried to say this shit to anyone in real life you'd be laughed out of the room.
You went off the rails here. You can disagree without being abusive. Downvoted, sorry.
>>How does "not comfortable with the command line" translate to "dumber by the day?" If people get their training using IDEs and go on to be productive using primarily IDEs, how does being uncomfortable with the command line reflect on their intelligence in any way?
Because the common characteristics of such people is to heavily depend on intellisense and auto complete to do almost any task. Tool generated code is so common in those communities most code is generally taken care by the IDE. Import statements, exception handling, try/catch blocks, loop generation in context of previous statements. The list endless...
When you are tuned to thinking this way you basically lose any touch on proactive coding. You stop thinking, the IDE starts thinking for you. You stop reading API because you know everything is about to be auto completed, anyway. Now the issue is you are offloading the job of thinking to the IDE. This is dangerous.
If a rookie can do what an expert can, just by using an IDE. I guess its time for the expert to fear for his job.
Lack of knowledge of command line utils is just one such case. You can either learn how to use awk/sed/Perl + Text processing utils. Or you can open up eclipse and endlessly re implement what the command line has to already offer.
When you start looking this from the larger perspective, refusing to learn tools designed to solve a problem in the proper way and taking short cuts, actually makes your life difficult on the longer run.
>>Yes, the mundane, confusing use of the git command line is here to stay and the dumb "actually design and engineer an application" world of IDEs is going to be replaced by robots. You are a fucking genius. Only on the internet can such backwards and completely worthless logic be said because if you tried to say this shit to anyone in real life you'd be laughed out of the room.
Definition of dumb varies. Definition of 'usability' varies. By your definition a programming language could be called dumb, a microprocessor and its interfaces can be called dumb, A pilots cabin and controls can be called dumb(As they are both not easy to laymen, and have never even made progress in that direction). A tool like git is not designed to be a toy or recreation software. Its supposed to manage text/binary versions in situations faced by individuals, small and large teams managing software projects.
Therefore it is designed to cover features in that direction, for programmers. Not for your ordinary user who needs to use the ATM to withdraw money.
Complaining about command line's usability being difficult is same as complaining about an Airplane's cockpit.
The cockpit is an interface (a GUI even) tailored for flying. The command line is an interface tailored mainly for administration and automation with a focus on text and files. A broom is tailored for cleaning the office and I use it when I have to. But what does this all have to do with what a programmer generally should be able to do?
I know the stereotype of the dumb Java/Eclipse programmer that apparently upsets you, and they certainly don't embrace the command line. But please, that does not imply that hating the command line turns one into a worse programmer.
> You are taking it personally.
(Not me, but:) You jump from not being comfortable with the command to getting dumber by the day, then eventually being obsolete. It's not really hard to read some elitism into that. Same for:
> A tool like git is not designed to be a toy or recreation software.
> Therefore it is designed to cover features in that direction, for programmers. Not for your ordinary user ...
Because that code can be easily automated... choosing not to is just wasting your time.
>>When you are tuned to thinking this way you basically lose any touch on proactive coding. You stop thinking, the IDE starts thinking for you. You stop reading API because you know everything is about to be auto completed, anyway. Now the issue is you are offloading the job of thinking to the IDE. This is dangerous.
False. You stop thinking about boilerplate code and API details and free yourself to focus on the actual problem at hand.
>>If a rookie can do what an expert can, just by using an IDE. I guess its time for the expert to fear for his job.
Do you consider writing good code an issue of speed typing? I have no idea why you believe an IDE would be able to make a beginner into an expert.
>>Lack of knowledge of command line utils is just one such case. You can either learn how to use awk/sed/Perl + Text processing utils. Or you can open up eclipse and endlessly re implement what the command line has to already offer.
Or you could use your IDE to write something that the command line doesn't do. Nice strawman.
I can never understand why people who are in the business of automating tasks (programmers) hate tools that automate tasks (IDE's), of all things.
>> Import statements, exception handling, try/catch blocks, loop generation
What "high-level language" are you using where this stuff isn't necessary?
1. The number of import statements in the typical code file in the typical Rails app is anywhere between 0 and 3, heavily weighted towards 0. Turns out you can metaprogram class-loading behavior in high-level languages and it just seems to work.
2. It's rare to find good places where exception handling is the best way to go in Rails, except for debugging purposes, in which case the default Rails behavior--to render the exception in a 500 if you're running in developer mode--is usually what I want.
3. Aren't try/catch blocks exception handling?
4. `.each do |e|`; `.map do |e|`. I can handle those on my own.
OK, there's serious shit you can't write in Ruby, but languages like Scala and Clojure are equally high-level, probably even more high-level, and yet have better performance and JVM integration.
Still, I understand there are legitimate reasons you'd use a language like Java, and given a language like Java, I can understand that you'd want an IDE to automate the drudgery. But I still don't like IDE's, because they're an ugly solution to a problem that doesn't need to exist. If I can concisely express what I want to do in my code to Eclipse, I should fundamentally be able to express the same idea just as concisely in the code itself.
1. And how exactly do they get away with that? What if you wanted to use a class that had a name conflict with a Ruby library class? Import/require are useful for namespace resolution. It seems that not having them would just be limiting your ability to name things cleanly.
2. Well sure, exception handling shouldn't be the rule, but how often you use them isn't usually a language concern (except maybe with Java and checked exceptions). Nonetheless, when you do use them, having your IDE give you shortcuts to write the boilerplate code is a plus.
I just try to avoid going around calling my classes things like "Fixnum" or "Array".
Seriously though, this kind of thing is all set up at the framework level, though you do sometimes have explicit requires for external libraries (gems) that you bring in. The Ruby standard library isn't that big, and Rails' libraries are named and namespaced intelligently and pretty much sit in the background without having to be explicitly invoked too much.
It helps that the main source of Ruby libraries is RubyGems, most RubyGems have a class or namespace named after the name of the gem, and there's a canonical source of RubyGems that doesn't allow you to use the name of gems that already exist.
> Well sure, exception handling shouldn't be the rule, but how often you use them isn't usually a language concern (except maybe with Java and checked exceptions). Nonetheless, when you do use them, having your IDE give you shortcuts to write the boilerplate code is a plus.
I guess Ruby exception handling just doesn't have much boilerplate code.
I mean, fundamentally, you're typing things to a computer and then the computer does what you typed. Why should that notion be uncomfortable to a programmer of all people?
Why can you not accept that someone could possibly hate working with a shell or git's CLI even after trying them out? I don't get it.
Maybe if someone added an EBNF grammar to the documentation...
"Just by operating from the command line you've already left the realm of "simple" in my opinion." It's all about the audience, people who are used to CLIs will find new CLIs that are similar to the ones they already know simple.
"I strongly, strongly disagree with your assertion that "for simple cases Git is really simple to use and to learn"
I've taught git to designers in 15 minutes and had them off and running for the next ~6 months. That said even after a few months of using it I still lack understanding of some of the core concepts.
Even the simplest form of source control involves checkout->change/add->commit->checkin. And this is regardless of any version control system you will ever use.
The only extra stuff there is branching and merging. And to be frank. I've never felt the individual need to do that. Its a different story if you have a big team and members working on several projects which merge at a time. Now that's difficult with any VCS, not just git.
But for individual development anybody should be able to do the checkout->add/change->commit>checkin easily.
With git you can share you current work to any arbitrary remote branch. The implications are your half baked feature can get pushed up and your coworker can do a checkout on the new remote branch. If they have suggestions they can make a change which you can cherry-pick off their branch into your branch. Also, you can branch off your current working branch, rebase master and merge their new branch in and push that up to master when everything works as expected. Try that workflow without breaking the central repo effecting everyone else's work in SVN.
So if you find git is hard or confusing just become friends with someone at github. ;)
After reading it, I have a much better understand of git, and can work myself (and others) out of pretty much any oh-my-god-I-destroyed-everything problem I run across. You haven't broken stuff for real until you need to use git reflog.
Link to book, free to read online: http://git-scm.com/book/
I did the tutorial mostly without looking at the filesystem so I could stop scrolling. But I know I missed a few helpful "extra" hints because they were below the fold next to the filesystem.
On the plus side, it piqued my interest. I've been meaning to get around to this.
git add "*.txt"
ls *.txt
EDIT: I'm wrong. Using quotation marks DOES make git fetch .txt files within subdirectories. As pointed out by cellularmitosis, git seems to do it's own "interesting" glob expansion.
but when you put quotes around "* .txt", that tells bash not to expand the glob.
so in the above case, '* .txt' is actually getting passed into git, rather than 'foo.txt bar.txt dog.txt' etc. I'm not a git user, but it sounds like git has special handling for "* .txt" which causes it to perform its own glob expansion, which happens to also include descending into directories. hilarity ensues.
EDIT: I can't seem to figure out how to type * .txt without triggering the italicized formatter, so I had to put a space after the asterisk. urgh.
I wouldn't think this is so much an error as they _want_ you to use '*.txt' to add the files in the subdirectory along with the files in the root. They could have touched better on the difference between quotes and no quotes though.
Let me explain what's happening.
What you are looking at is actually part-git, part unix-shell-y.
You did ls * .txt
Let's try something way crazy, type echo * .txt
What do you see? All of your txt files right? But that's just echo, not ls.
Ahh. Here's the clinch. When you do " * ", that's called either shell "expansion" or "globbing" depending on your shell. Basically, the shell says "ok, before I run your command, I'm going to look at it and see if I need to do anything on my end"
This is why you can do
$ n=0
$ echo $n
In your example, the shell has hijacked the star in "ls * .txt", replaced it with all of your txt files, say (a.txt, b.txt) and then ran ls.
That means that ls ACTUALLY got
ls a.txt b.txt
---------
So git add "* .txt" works differently, what gives?
Well, when you put things in double or single quotes you are telling the shell "hey, don't do your usual stuff here". The single quotes are more extreme. If we go back to our n=0 example we can try two more things:
$ n=0
$ echo $n
$ echo "$n"
$ echo '$n'
So when you do
git add "* .txt"
In most reasonable, sensible programs, the program will look for a file named "asterisk dot t x t" in this case.
But alas, our friends at git have decided to be tricky. The ' * ' syntax for git is similar to gitignore-like syntax (http://www.kernel.org/pub/software/scm/git/docs/v1.7.10/giti...)
"Awesome", you exclaim! Not so fast. It's not the same.
So git add '!1' doesn't work. git add 'one/ * * ' doesn't work, only git add ' * ' seems to work.
Why is it so hard? Good question! I haven't any idea. But we can commiserate together ... you know, over twitter.
Have a good one!
From the blog post[1]:
"If you know of a developer, designer, or other knowledge worker that would benefit from using Git but that hasn't made the leap just yet, send them over to try.github.com when they have a spare 15 minutes."
As a developer, it would be nice to know how well this tutorial really works for non-developers. To me, it seems that the tutorial introduces way too many concepts and details in a very short time for a non-developer to understand.
For example, there are a lot of people that work daily with a computer but freeze completely when faced with the task of using a command-line interface. Yes, clicking on the command does write it in the console but you still have to know to press the return key to actually execute the command.
I'm not saying people shouldn't learn Git, I'm just wondering what the target audience and purpose of this tutorial is.
However, I think there's something to be said for showing people how they can be immediately productive with a tool before really understanding everything that's going on underneath. With just a few commands someone can start using git successfully, and that's all we were trying to communicate with this tutorial.
I can't speak for GitHub (I'm from the Code School team that built this), but we were very cautious not to introduce too many concepts in that course (you can see below someone saying it's too basic, yes, that's the point), simply the absolute basics we thought people would need to know to understand Git. We also did our best to not introduce Unix concepts, which open another can of worms.
The point is that a very large amount of people working on and around the web today are terrified of the command line. There are plenty of tools that attempt to abstract away the Git command line interface, and our goal with Try Git was not to do that. To give people the real Git experience and try to ease them into it.
I'm sure we can improve it over time to ensure that fewer people "freeze" in front of a command line. You're right that we may need to be more explicit as to what people should do after entering a command, but we need to stay as consistent as possible with the actual command line.
Please feel free to give more feedback, I'll be going through everything that's posted here.
— Olivier Lacan
Now that I checked the tutorial again, there seems to be a "Press enter to submit commands" help text before the command prompt. If you just added that, great, since that would have been my first suggestion anyway :)
As a developer using Git daily I can only guess what the most problematic parts of this tutorial are for beginners. I hope you get a lot of good feedback and data from all the people visiting the site!
And is git much use to people who mainly work with large binary files? Well, I'm not sure (translation: "no") - but perhaps if they don't expect very much from their source control system, they won't be disappointed when git fails to deliver on its promises as well as it does for text.
I liked the approach of Ruby Monks where they give you a task and let you guess the syntax. If you got stuck you then look at the solution.
I don't mean to make less of try git, or any other interactive tutorial. We live in a wonderful time where we are able to learn powerful tools without even installing them, so I almost feel bad about making this criticism. But I think current tools could be improved by removing some of the wizardy feeling and allowing users to play around and trying to figure out stuff on their own.
I don't think everyone (and certainly not myself) was able to understand the value of Git at first glance and decide to invest time and effort into learning about its inner workings.
Normal Code School courses and Ruby Monk challenges are made for people who already have somewhat of a vested interested in learning. Something that pushes them to challenge themselves beyond a simple demo/interactive tutorial. People like that are (sadly) a limited subset, we're trying to broaden that.
The concept of a single folder containing multiple versions of your stuff is a big deal; the fact that you can't simply navigate to a branch as if it's a different folder--that you can't "see" all your files at once--is a non-trivial thing to punch through.
I can kind of sort of use Git already but frankly I don't understand what half of the commands do nor do I understand the point of them.
Technically the only commands I would assume you need are:
- Get repository - Merge repository (with comment) - Get history/comments
But Git has dozens of different things it can do that expand on the above and learning it all is time consuming and there is no one single place to do so (and no the documentation isn't a good place because it isn't a intuitive way to learn).
The biggest hurdle of using Git is that Git has its own vocabulary for things; and there is nothing "common sense" about that vocabulary. Even people who attempt to explain it assume you know another version control so use vocabulary from that.
Doesn't speak too highly of Code School in general.
I just finished the course.
Great job guys!
http://help.codeschool.com/discussions/code-school/3731-try-...
I love when sites do something like this in order to give potential users a quick taste of a language or technology. I already learned Git using the Pro Git book, but this would have come in handy as an introductory lesson.
This also reminds me the of the awesome tryruby.org
It wasn't until I went through Michael Hartl's Rails tutorial that I actually learned Github, master/branches, etc., and understood what are commits and pushes.
I think they should focus on scenarios instead. Short stories like: "Bob's code is working well but he wants to try something that might be completely misguided. He knows better than to mess with his working code....." Then at the end of the story a command is introduced. Also, some kind of indication of what Git is actually doing when you issue that command. When you tell Git to branch, what actually happens to the file system? When you say git status, what is it actually looking at?
And please, don't start a tutorial on Git without introducing the three area paradigm (working, staging/index, commit)
Here's a talk by Scott Chacon of GitHub. http://www.youtube.com/watch?v=ZDR433b0HJY
It's over an hour long and very detailed.
Like most things in software development, learning by doing is the best option because most people don't have photographic memories, and having a reference is usually essential.
Luckily, we all have one huge reference available to us, for free (more or less), with a thriving community who are more than happy to help: The Internet.
This tool is, nonetheless, a good starting point.
The other day I tried to merge only some files from a new "experimental" branch and failed hard. I then realized I had it all wrong about how to successfully commit and manage branches.
And felt so lame :) The sad part is that I am the only one trying to use a CVS at work.
TL;DR : I still need to learn Git, so thank you everyone trying to "teach" it.
I did some programming training a while back and found that there seemed to be way more people interested in the basics. I'd be curious if something like Git would be different.
would be cool to actually run githug under that website :)
I have a tough time wanting to pay for a course at a place like code school when I know if I go through the docs/tutorials I'll get it. It's not that I don't think the experience is better, or even (for a certain definition) worth the money. I feel like it is an unnecessary indulgence.
I suggest you check out the first level of that course when it comes out. I doubt you'll think it's an unnecessary indulgence. In the meantime our Node course is good example: http://node.codeschool.com
Win 7, Opera 12.
I am curious which JavaScript errors you're seeing, though, skrebbel. I don't see anything amiss in the developer console on Safari 5.1.7.
While it certainly isn't as bad as some other sites, I think it is naive to suggest that nobody has ever been downvoted on HN for having an unpopular opinion.
Also, having them automatically adding files to the directory was kind of confusing. Sometimes I would type a command and something new would appear in the file system as a result of that command. Other times, I would type a command and something new would appear in the filesystem that I suppose was expected to be used for a subsequent step. It would have been nice if these things would have happened in isolation from each other. That way I could run the command, see what happened, and then perhaps click "next" to move onto a different scenario with a new set of files I could add to the repository.
This guide is like starting the "Couch to 5K" fitness program but knowing that, if you stick with it, eventually you will have to compete in a marathon.
I'm at the point where you do a git checkout clean_up and then nothing at all happens. You just get the prompt back. If I try git status same thing.
I've reloaded the page multiple times, but same problem.
Maybe Code School needs to work out a few more bugs?
However, it requires giving an app 'try-git' access to your private and public repositories... so afterwards, probably a good idea to edit your profile, click Applications, then remove the try_git app.
What? I don't know if this is allowed later and everything is sandboxed.