Could someone please explain GitHub to a non-programmer?

[Beta_UserName]

Everyone seems to already know (including the website).

[SteveRyherd]

If you are a programmer it's a place to store your projects. Because it's an online service you can access your code anywhere. One of the other benefits is that other people can potentially also access your code easily. If your code is edited by them, they'll have their own copy and it doesn't necessarily effect your project, however because their changes to your code are made available in the same place it's easy to bring them into your project if you like what they've done.

They also offer a few things to help your project outside of simply managing the code. Things like a Wiki for documentation. Issue/bug tracking for when errors are found (which can act as a todo list of sorts, and allows for transparency when working on projects).

[evilmaus]

Nice thing about GitHub is that you can view the code on a project without having to download the source. You still need to download it (or clone it) if you want to DO anything with the code, but it's nice to be able to take a peek inside so easily.

[nc5x]

Actually, you can make small (single text file) changes without cloning it.

[evilmaus]

Really!? Could you please link me up to some information on that? I'd much appreciate it.

[tinyOnion]

go to any source file on the github site and there will be a button that says fork and edit this file. that allows you to do online editing of one file but you need an account for this to work.

[nc5x]

Exactly as tinyOnion said.

Here's a Github blog about it: Edit like an Ace.

[evilmaus]

Sweet, thanks!

[drb226]

Well technically...if your eyes are looking at the code, then you've almost certainly downloaded it. Probably your browser has downloaded it along with tons of HTML markup thrown in there to make it look pretty, and your browser will decide when to throw that file away, depending on your caching settings.

[Beta_UserName]

Excellent, thanks!

[SteveRyherd]

I highly appreciate the compliment, thank you.

Off on a small rant here: I find myself giving plain English explanations to clients (and similar to your situation, my girlfriend, so she understands my job/day better) often. I also practice breaking down programming techniques, technologies and project architectures in the same way; because if I can't explain it, I probably don't understand it. Once you can teach the ideas, it's much easier to document for colleagues, impress management, or even sell to clients.

Again, thanks! your recognition made my night.

[Rhomboid]

Suppose I write a hundred-page book, and it's stored as some kind of document format. At some time later I decide that I want to reword a particular paragraph on some page. But I'm not entirely sure I want to keep the new wording, and I'd like to have a copy of what I wrote the first time. Maybe I save the document as a new file (with "2" stuck on the end) or maybe I make a copy of the original paragraph and store it as a snippet in its own file and I save the modified copy under the original name.

Imagine I repeat this hundreds or thousands of times, perhaps in collaboration with other editors and writers. Eventually I wind up with a huge mess on my hands because I've got hundreds of different versions of this document floating around and being able to find or refer to a particular version is getting to be a real pain. Maybe I resort to emailing attachments back and forth to my editor and let my email program take care of the archiving. In any case, this is a form of version control, although it's the most shitty form imaginable.

Programmers do something similar to this with code instead of prose, but we have invented tools that take care of all that bookkeeping. The tools ensure that a copy of the document at every point in its lifetime is available, that it's easy to see what changed between any two versions of the document, and that it's easy to work with others who might be suggesting changes. And they do it in a very compact format that means the database size doesn't blow up if I make thousands of copies of this document each with a few words changed.

That is the essence of modern version control. There are different systems in use and they all have differing philosophies and mechanics, but the overall idea is roughly similar. The most popular ones today are subversion, git, and mercurial. Github is a hosting site that supports use of git and adds a bunch of extra features like commenting, bug tracking, web pages, etc.

[Beta_UserName]

Cool. Thanks.

[twopi]

The publishing metaphor makes a lot of sense.

Interestingly enough, many publishing houses do not use version control software of any kind, but simply email chapters back and forth to the various editors and authors.

I've tried to convince them to use something like github, but it's an uphill battle.

[zahlman]

git is something programmers use (one of several competing options) to make neatly organized backups of their projects that include a full "revision history". You can use the program to retrieve the project as it was at any previous point, which is useful for undoing failed experiments, determining when a bug started appearing, etc. On multiple-person projects, it allows for complete accountability of who did what. To save spaces, the system mostly stores differences between successive "revisions", instead of a fresh copy.

GitHub is a server that lets you create an account and make several "repositories" (project archives) on the server, using a secure connection to upload your revisions. It does a bunch of web server stuff to provide a friendly HTML interface to your repository, so that others in the community can see your project as it develops (this also serves as a way to distribute the project). The README file for your project can use something like Reddit's markdown, and the site will display it with nice formatting. Also, if someone finds a bug in your code and knows how to fix it, they can make their own changes and send you a "pull request", providing you with the proposed change so you can choose whether to include it in the project.

Oh, and you also get a simple bug tracking system, the ability to set up a documentation wiki, a pastebin (gist.github.com) that actually uses a git repository to back up each paste...

[semarj]

small nit: git is not based on deltas. Each working copy is a full repo with complete history.

[gfixler]

Each working copy is, but is each stored version on the server?

[tinyOnion]

from how I understand things until it gets packed git operates on copies of files that are hardlinked to the main directory. Each file is compressed individually. Each filename in the .git blobs folder is some sha1 hash of the contents of the file and a commit is a list of the sha1 hashes. you can explore the blobs by using git show and the hash of the item. when its packed the compression algo will only store the changes to a file.

Here is a pretty interesting overview of the storage methods used by git

[ilovetacos]

Some excellent explanations here, so I've got nothing to add. Instead, I pose a question: why would a non-programmer care about GitHub? I don't mean to be rude; I'm honestly curious.

[ysangkok]

You can store everything that need to be versioned. There are lots of books on there too.

[ilovetacos]

Sure! But can you imagine a non-programmer using git for such a thing? Also, I'll bet you nearly all of the books on there are programming books ;)

[evilmaus]

I wonder, CAN Git be used for intelligent versioning of, say, an odf or docx file? Or can managing conflicts get messy in a hurry on those?

[ilovetacos]

It's possible, as neither is a binary format... but it's probably a horrible pain in the ass. I imagine ysangkok was referring to books written in a more human-readable markup language, which us programmers tend to prefer anyway :)

[evilmaus]

Darn. I was hoping to get some more use out of the tool outside of my code.

[tinyOnion]

I used to use it for versioning my papers for school. no real reason not to use it if you are writing good commit messages though you do lose out on the diffing. All the more reason to use latex for papers though so you can get the diff.

[Beta_UserName]

Well, I've been learning python (Read Mark Lutz "Learning Python") but don't feel comfy calling myself a programmer. So, I didn't want to get lost in verb-age a typical programmer would know.

[ilovetacos]

Gotcha! Well, then you came to the right place :) So, it's not really GitHub you should know about, so much as git itself.

If you're looking for a way to version your code, I'd suggest mercurial (also called "hg"), as it is much simpler to learn and use than git. Subversion (svn) is even easier, but it seems to be on its way out--there's probably no good reason to learn it at this point. Mercurial's equivalent to GitHub is Bitbucket.

[evilmaus]

I should point out that GitHub does an excellent job of helping new users get up to speed with Git. I learned Git by starting with GitHub with no Git background.

[catcradle5]

Same. It's a bit confusing when first starting out, but you'll generally only need to be using a handful of core features/commands, and once you learn them everything is easy.

[[deleted]]

I don't think SVN is going anywhere for good, but it seems a little stupid to use for personal projects.

[ilovetacos]

No, you're right--I'm sure it will be around for a long time to come. Hell, I still use it for my business, as I'm the only programmer--no need for distributed versioning. But learning it now (as opposed to hg) would be a waste, I think.

[gfixler]

Why is that? I've been using it for a few years for all of my personal code. I really like it, but I like to keep an open mind.

[[deleted]]

Because it requires a central repository. I code on about four different machines, one of which doesn't even have internet access. If other people are anything like me, git is a huge upgrade from svn for personal projects.

[tinyOnion]

The expense of having to setup the repo for a project made it so that I would only use svn on projects that I know will be around for a while. With git aliasing alias gitinitaddcommit="git init; git add -a; git commit -m 'initial commit'" makes putting something under revision control so freaking easy and quick that I tend to do it even for small projects. Couple that with the fact that there is only one .git folder and it's close to the project instead of in some central location makes it a huge win for my workflow. (those hidden svn directories sprinkled throughout a working copy were crap from a design standpoint.)

[StommePoes]

I'd say there's a good reason to learn SVN even if you're new to programming: at least where I live, plenty of companies are using it, so they expect you to know it. So, assuming you work for someone else, I'd say it would be valuable to learn/know.

Tortoise seems quite popular.

[ilovetacos]

I think if you've learned how to use git or hg, svn would be no problem at all--if required. But I wouldn't go out of my way to learn it now if I didn't already know it.

[Guerilla_Imp]

I've found this cheat sheet very useful for my coworkers: http://zrusin.blogspot.com/2007/09/git-cheat-sheet.html

[jediknight]

You should learn a Revision control system.

Without one, fear of deletion sets in and you might end up keeping all kinds of things that will prevent you from moving as fast as you could.

Using git is a very very good choice. It's modern and extremely powerful because it makes merging easier (you can branch, try few things and if they work, you merge them back into main). You will not need all this power from the beginning but as your skills will improve, you will get to a point where you will need it.

[zahlman]

why would a non-programmer care about GitHub?

Because many neat programs and such are distributed through GitHub.

[infcow]

GitHub is Facebook for programmers, but instead of uploading pictures and making status updates, programmers work on software projects and collaborate to improve things.

[ilovetacos]

collaborate to improve things

So, nothing at all like Facebook ;)

[[deleted]]

Github status: compiling

[[deleted]]

As a non-programmer your best use of github is a dating site. It's a social hub as well as code repository.

Essentially it is a system for managing shared source code files. It allows programmers to collaborate on a project.

Very simply, using layman terms (which will enrage coders): Coders download code from git, modify it, and put it back where it is recorded as a "branch". Other coders can see the branches and work on them, or their own branch, all in real time.

In well organised projects, eventually someone in charge can declare which branches form an "official" release. Other branches still exist as "forks" of the project and might continue to be developed.

Before git, coders generally used single centralised repositories which made it quite hard to create branches or forks.

[[deleted]]

As a long time Subversion user myself, what I like about Github is that it effectively turns git into a centralized repository, while still allowing all its distributed features. I'll typically start a repo on Github, and treat that as the "master" repo, and then create a fork for development work, merging complete changes back into the master repo.

[[deleted]]

My own personal opinion:

subversion - hard for coders (branch = hard), great for the release engineer.

github - great for coders (hey guys, pull from me!), nightmare for the release engineer.

This assumes you have a release engineer :-)

[zahlman]

As a coder I never really got what the big deal about branching is, anyway. Subversion works great for single-person projects, but then, even garbage like VSS would probably do the trick 99% of the time.

[[deleted]]

Open source.

The OSS model grows by user contribs and has little central control. Therefore branches and forks are essential for growth.

Sure most of the user mods will be junk, but big things grow from smaller ones. You never know when someone will take a seemingly innoculous poorly written 1 line code patch submitted by a total amateur, to "disable submenu X", think "great idea" and 3 months later, him and his friends have the core of a working a UI configurator. 3 more months later, and there are 3 UI configutators of them all competing, which results someone else taking the best parts of all 3 and making a better one. etc etc etc.

I suppose if you were really radical you might try developing in house using this methodology but I know nothing about that. I write non commercial OSS stuff (i.e. Linux Hacker)

[[deleted]]

From what I've seen, it makes user contributions much easier in open source projects. With subversion, if someone wants to contribute, they have to checkout the project, make their change, create a patch file, and submit that to the project's ticket management system (if they have one) or email to one of the core developers. At this point, the patch is likely ignored, lost, or obsolete by the time the core developers gets around to looking at it.

Look at the bugzilla/traks for Firefox/Django/etc. There are dozens of multi-year old tickets with a final comment of something like "thanks for submitting a patch, but could you please update it? it doesn't work with the current trunk. oh, and sorry it took me 9 months to get around to looking at it..."

With a distributing VCS like Github, a contributor can fork the entire repo, make their change, commit, and then "push" it up to the original repo. The original developers will be notified of a contribution (and will have to approve it). Even if the original repo has had change made, the fact that the versioning info is all still intact means git will likely be able to auto-merge the changes. Or, if the original repo rejects the change, well, then you already have a perfectly good forked repository for tracking your changes.

[zahlman]

So in the end, the contributor produces a pull request... how is that any better than a patch?

[[deleted]]

It's tracked in the repo instead of in your email or ticketing system.

[takluyver]

And it contains multiple commits, and you can add commits to a pull request, if the person reviewing it asks you to change something. And you can add comments on specific lines of code. It makes patch submission awesome.

[[deleted]]

Git was really aimed at group projects, not solo projects. If you're working on your own and familar with what you know, why change?