Hacker News new | past | comments | ask | show | jobs | submit login

How does Github save time over the predecessors like self hosted a Git or SVN repository?



This is reductionist, I am not the first to fall in line to support github here, but lets expand on what github is instead of assuming.

Github is, primarily, managed source code hosting- but it has more components, so lets break them out:

1: Source code hosting

2: Web view

3: Issue tracking

4: Project management tracking

5: Search

6: Authentication and identity (oauth2 and "applications")

7: Documentation rendering

8: Web hosting (a-la github pages)

9: CI pipeline (github actions)

SVN replaces point 1, and poorly. How many hours do you need to manage an SVN server? Very few I would wager but it at least behooves to ask the question. And it certainly behooves to understand that you're not replacing 1:1; you're replacing many things with one, and managing the above yourself can be done cheaper, but poorer, so that "poor" imitation could cost more time for using it too.

It's a very nuanced topic but an interesting one, and reductionist questions like this are not helpful.


Pull request management, code reviews, CI flows, github actions, github does have many features that other git clients don't, certainly not a self hosted git or SVN repositories, and those features save a lot of time just in the ease of initial setup.


Permissions. I specifically remember talking to Tom and Chris about how that was really the main point of rage that spawned the idea of GitHub (and its original slogan “Git hosting: No longer a pain in the ass”).


Did you spend 5 hours per week per employee managing permissions in git?


Setting up and managing keys, spinning up new repos, etc. would suck up an inordinate amount of time. This was especially true when I worked at consultancies. Blocking developer work with “Sorry gotta wait on Todd to add you to the server and set you up on Git,” when Todd would avoid it like the plague because it sucked would lose a lot of time.

If you averaged the time out, it may not have hit the five hour per week mark, but it combined with other time savers (linking Git directly with the issue tracker for example instead of having to figure out how to cross reference them) easily did/does.


> Setting up and managing keys, spinning up new repos, etc. would suck up an inordinate amount of time.

The claim was 5 hours per employee per week. I found that it took far less than 50 hours a week when working at a 10 person company. And if it did, I'd question the competence of whoever was doing that maintenance.

I'd pin it at closer to 3 or 4 minutes per employee per week, with maybe 8 hours of setup once. That's still a bunch of work, but it's a whole different ballgame.


Maybe not managing permissions directly. But I could easily see a number like that, or higher, being plausible if you consider clean up from junior devs accidentally pushing to development/main branches thinking they were on their feature branch. Which is an issue directly solved by permissions.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: