Lifehacker saying such things does not surprise me as their quality of writing and target audience is much less hacker news in 2013 and much more mainstream. It would almost be more suitable to just relink the article to help.github.com as some others have mentioned.
Gawker now exists as a network that posts articles designed to get that advertising revenue in, the whole Reddit witch-hunt a while back serves a point.
If you're learning Git from a Lifehacker post, you're not going to learn much.
Massive shame, it used to be a great site for productivity tools. Kotaku too, now that's reduced to the low hanging fruit of gaming news, and don't get me started on Gizmodo.
This post is so apropos for me (at least the title is) -- I'm perfectly fine with the Git part of github, but was struggling with the other parts of it. For example, trying to figure out how to make a versioned release. The download link they provide gets you the latest version from the repository. Took me a bit of searching and looking at other projects to realize that if you tag a release, it can make that available too.
But now trying to get that to show up in the project page (using their auto page generator) -- I ended up having to hand edit the html code, because I wanted the web page to have a list of specific releases. But even their source download link isn't fully intuitive. For example, mine shows up as "https://github.com/derekp7/snebu/archive/1.0.tar.gz, but it downloads a file called "snebu-1.0.tar.gz".
Oh, and to get the readme file to utilize their markdown, you have to call it reamde.md, instead of readme.txt. And I'm looking for where my users can leave feedback or discuss things, other then opening an issue in the issue tracker. But they don't have any mailing lists or forums (I guess most projects set up a separate forum, and link to it from the readme.md file or the gh-pages page).
What I'd like to see is a document going over the entire lifecycle of all the features offered through github, including documenting the standard practices for items that they don't provide (such as the forums thing). Anyone got any pointers?
One alternative for the uploads is to make an orphan branch similar to gh-pages, populate it with your tar.gz file contents, tag it, then delete the branch. It will show up like a normal tagged download without having extra messy branches in your repo.
Well, of course you need to give the markdown extension to files which should be rendered as such. How else is Github supposed to know which files are markdown?
Github Pages is strictly for hosting static files. Thus, it's not meant for discussion between users. You're better of renting a VPS and hosting your project's website on it.
Yes, i understand the logic behind that, but had a difficult time finding the specific extention documented. That was just a recent example for illustration. What I'm trying to find is a full user manual for github. Not little tidbits scattered all over. Does that exist, and I'm just not finding it? I just keep feeling I'm missing a lot of functionality somewhere. Or maybe im expecting it to be a full alternative to something like Sourceforge when it isn't intended to be. Thanks.
A complete introduction to Git can be found at http://learn.github.com/p/intro.html. I know you mentioned that you're comfortable with Git, but some of the information there may be of some use.
GitHub has a series of help articles, which could be regarded as a manual of sorts. They're at https://help.github.com/
For how popular github is, it does have a surprisingly frictional client set up process, for Windows users at least (although this is partly due to git itself). I can talk a non-technical person through setting up an SVN repo using Tortoise no problem. With git it's something I just have to do for them.
I think it speaks to how amazing a service github is that the more complicated set up process doesn't put anyone off.
Ha, I just looked and it came out immediately after the last time I set up git/github on a windows machine the old-fashioned way. So it looks like my comment is probably invalid now. The next time I use git for a project I'll be sure to check it out. Thanks.
GitHub is fantastic if you have an UNIX/Linux background. I can understand the scary felling of someone that uses Windows on daily bases (for example) and suddenly have to work with SSH, GIT, Markdown, etc. I love GitHub but I don't think it is made for ordinary people. One day maybe it will be.
Any tutorial for Windows users with git should probably introduce cygwin or powershell while they're at it. Git in a GUI can only get one so far and having to deal with cmd.exe for anything is a nightmare.
A typical Windows users might only deal with GUI stuff, but I've seen many break down to use a command line to root their Android phone (via adb and fastboot) that would have no reason to use a command line otherwise. Just need a good reason to use it and shown they don't have to fear it.
What's the relation between Git and Markdown on the one hand and Windows on the other? SSH, yes, but the others? And there's nothing about Unix that limits its use to extraordinary people — I use it, as well as Git, Markdown, ssh, and even Emacs.
I just cited markdown as complement to git. Git is a command line tool as is SSH (don't talk about GUIS for Git, that is not the case). I never said Unix is used exclusively by extraordinary people only (Ubuntu and others are an example), but the majority of people still use Windows.
Have an Unix/Linux background makes it easier to get started because you already know what they are talking about.
My personal opinion? Windows sucks (just to be clear, that is me).
This is a really good article. Personally, I don't use Github for the same reasons - the over-whelming complexity of GIT and its terminologies. I currently use an SVN (Tortoise SVN) to keep my work in sync.
I've gotten as far as creating repos, branching, merging and pushing them to github. Oh, and not publishing my livejournal passwords in my repo. Anymore.
But yeah, not the most beginner-friendly thing in the world, and most of what's on github i'll probably never even touch. I forked a repository but i still don't know how to submit a pull request. I don't even know how to delete it. Feh.
There's a lot of documentation on the web for Git, but the Git/Github integration can get a little hairy if you get out of sync.
The pull request workflow depends on what you're working on (Personal project? Company project? Massive open source project?), but Red Hat has a pretty good overview of a fairly standard system that most people should be familiar with:
Thanks, this is one of the best one-page workflow examples I have seen for Git and Github. Sometimes all the docs are so focused on the power of each command, that they neglect the big picture of how to apply them in real world workflows.
To be fair, if you're going to lifehacker to help you set up github, you're probably not motivated enough to go tearing through github's faq. Quite frankly, you're probably not motivated enough to finish the lengthy tutorial they posted.
Agree completely. I'd extend that to say that if you're relying on Lifehacker to help you set up Git/Github, this statement is probably false:
"Nevertheless, it's good to learn the old-fashioned way otherwise your options in the simplified software won't make sense."
The Github app goes to great lengths to make the interaction with Github more intuitive than the CLI Git client. Yes, your options are more limited, but I work with several pseudo-technical users who use solely the Github app. You can switch branches, checkout, publish, delete, and merge through the Github app. The Github app even stashes automagically if you switch branches with uncommitted changes. The only area that gets sketchy are conflicts, but many of the people at whom this article is targeted will never encounter a conflict, because they're the sole developer.
In any case, I can see absolutely no reason that a casual developer should move past the Github client to the Git CLI client if they have no specific need.
I sort of regard lifehacker as a web site for teenagers and hobbyists nowadays, so I'm not particularly surprised at the quality and tone of their technical work.
Wait, we're using software first released in 2005? Holy crap, we may as well be using quill pens.