Coming from a custom Gitolite [0] setup where I was able to protect branches and reject commits and do other basic or complex stuff with ease, GitHub looks like a joke. Their "improved" permissioning made me laugh. It doesn't even show signed commits, tags, and branches! Simply put, I like the "Hub", I hate the "Git" in GitHub.
Coming from a personal computer with an operating system made later than the '70s where I can organize my collection of repositories hierarchically, I too find that Github looks like a joke.
I do not want my repositories to be all in a linear list, with my various chess projects, my various math projects, my various game projects, and so on all mixed up. And I do not want to resort to kludges like prefixing projects with chess- or math- or whatever as an inadequate workaround.
If your projects are public, you can create an org for each class of projects... tzs-math-demos/projectname for example.
It's not much better than prefixing, but it really isn't so bad... What gets me is the leftover cruft when I fork to make a patch to an upstream project.
This is voted down, but my organization found the Github pricing system awkward as hell, and we were competent enough to use Git without a condom, so Gitolite was a great fit for us.
Yes, charging per repository is nothing short of predatory. It means that every scratch project and every prototype needs to be deleted - or paid for in perpetuity.
It's even worse for agencies and contractors, since for them changing projects often is a natural part of business.
Even as a developer working on my first open source project I find the model a huge turn-off. I want to keep my repo private for now and it appears I have to pay. Instead I'm using Bitbucket which charges by the user -- far more reasonable model IMO.
Yeah, we're sort of in this odd space: GitHub has a lot of us "big tech" happy to be in a space with a lot of people collaborating, but we're having to spend pretty big in order to be productive.
That's exactly true. But even GH Enterprise still has insane pricing.
Hosting a git repo and a very very basic issue tracker is so not worth $2500/year. Not to mention that even this isn't a fixed price and it grows linearly with the number of employees.
GitLab provides the same service for free. Well, at the cost of "you reading the manual and installing it on a VPS", which takes between "minutes" and "a couple of days" depending on how deep you want to go.
A VPS that can easily - easily - scale to the needs of 100 people is "$5/mo".
Looking cool and having brand recognition will indeed earn you money, but everything has its limits.
> Well, at the cost of "you reading the manual and installing it on a VPS"
... And managing and maintaining that server and backups of it. $2500 a year starts to look pretty reasonable when you consider the amount it will cost you to put one of your developers on to setting it up and maintaining it. Not to mention the peace of mind of not having to worry about disaster recovery.
Setting up is a real cost, but I manage users on our corporate github and our self hosted gitolite; for github, the user gives me their username, and I add it (after looking up my password), gitolite I add their public key to a directory and their username to a file and git commit; git push. Not a lot of difference.
I don't worry about backing up the git repos, one of the promises of git is that every person who checks out the repo has a full copy, any of which we could use for a backup (helpful if we get a recent checkout).
Third party hosting hopefully has a good disaster recovery plan, but the disaster could be your hosting provider quietly went out of business and everything is offline.
Literally the only time I have had to administer my GitLab setup in any way was when my SSL certificate was about to expire. It's really very solid, and all of the user management can be done from the web front-end.
GitLab is easy to upgrade via apt-get/yum with the Omnibus packages. But if you want a maintenance free GitLab please consider GitLab.com or our GitHost.io service for single tenant hosting.
> It means that every scratch project and every prototype needs to be deleted - or paid for in perpetuity.
The same is true if you host yourself. Storage is neither free nor infinite. Sure you could scale your storage, but that costs, too. Unless you're absolutely strapped for cash, I think this just encourages good hygiene.
Scaling storage?
The highest public plan Github allows 125 repositories. Unless you have a lot of huge repositories, 125 repositories fit into a single smallish hard drive. Even with 10x redundancy, that's still cheaper than github.
Frankly, there are hard problems in internal IT, but hosting a bunch of git repositories is a non-issue.
To store all my repositories as private repositories on Github, I'd need the $200/month plan.
Yet all of this comes to less than a gigabyte, which is well under the limits of the free tiers at most major storage providers.
In terms of storage costs, Github for most projects is several orders of magnitude more expensive than other storage providers even if you ignore the free tiers.
It's worth noting, that if you have SSH access that includes filesystem access, you can use that as a git remote target, without the need for a GUI, if it's for personal projects.
I've done precisely that for personal projects in the past, as well as for a couple small teams as an intermediate step towards hosted git. I support GH mainly because they are supporting open-source... it's indirect, but I support the model.
As another alternative to GitHub, we are using GitLab CE on-premises. This is the open-source version and we've been pretty happy with it in a team of 50. And if you want support and some extra features, then the pricing is much more reasonable than GitHub & GitHub Enteprise.
Having used both GitHub and GitLab pretty extensively I could only recommend GitLab if self-hosted and cost are your primary requirements. That being said GitLab is an impressive product given the development forces behind each.
I'll make an effort to take notes over the next few weeks and put something up on the issue tracker. To be absolutely clear I think GitLab is pretty good I'd just prefer and recommend GitHub still if self-hosted and cost weren't the primary requirements.
I agree. Github works and really shines for "developer"-centric small teams.
You mix in larger number of developers, add in QA, testing, release, issue tracking states between them and it becomes a pain. Having to implements bots, API keys other stuff like that.
Not all tools work for everyone. What works for individuals and small teams doesn't work for larger teams.
I saw this twice both at a smaller company and larger one. Starting with Github. Hit pain points and then picking something else. In one case was about buying Jira + Confluence, because it was about issue tracking states. In another not sure yet. But lots of bots and rules and automatic pull requests and merges is becoming a pain and might end up with Gitlab or something else soon.
I don't think that's the case. I work at a startup with a fairly permissive commit policy (forgiveness > permission), and because of how Github is architected, we have to put policies in place about which branches someone can/should commit to in READMEs (branch X should always build, branch Y should is where code get staged for tested, and so forth), instead of within the tooling.
As someone at Google once said, "If your policy doesn't exist in software, it doesn't exist."
How can essential Git features be a mismatch? For example, the CI can sign release tags, and you can deploy them with confidence. GitHub is not a small company. Gitolite is developed mainly by a single guy. Okay, there's no pretty UI, but developing one nowadays is not a huge task. The way Gitolite can handle a significant feature set is very elegant! I'm surprised GitHub behaves like they don't know about the existence of Gitolite!
To reiterate: they host it for the Hub, not for the Git in GitHub! We dream for the day when GitHub will be capable of working with external Git repositories!
I've used this as an outsider to do some work with Microsoft and it's really slick.
I wish the Visual Studio Online team would look a little harder at Github and steal more of its Issues experience, and have something more lightweight than the backlog monster they've got now. I think it's not uncommon for VSO users to keep a Github sync of their code so they can use GH for issues and day to day code and VSO for builds and deploys.
I use VSO for the free private repos, but really it needs to be overhauled in a number of ways...a name change itself would go a long way. "Visual Studio Online" sounds like I'm actually going to be using an online version of VS like Office 365's online apps...but nope. It's a bit of a marketing nightmare. Even the guys from Microsoft were complaining about the naming making it hard to make people understand when I was at Build this year.
Isn't it just a version of TFS online using a SAAS billing concept?
Wouldn't "TFS Online" be a better description if you want to stock with the Microsoft unimaginative naming policy? At least it says exactly what it is.
My personal opinion is that Microsoft should just go with the internal names. They are more interesting and memorable for customers. They are often one word, rather than five. Visual Studio Team System Online 2020 Developer Edition.... Sorry, started snoring after 3 words.
The "inviting a person to the org" issue sounds like a failing on the GH side. Why can't you just invite someone by email and let them choose the account to use the invite with (or create one)??
You send me an invite. I choose to use it with my account that I set up while working at your competitor. Now your competitor potentially has access.
At least the way they do it now gives some control to the org as to who has access to their account. It's inconvenient but it biases towards making on boarding hard to make control and off boarding easier.
Also, GitHub wants to avoid the same person having multiple accounts. Their focus is the developer, not the org. So they want all your work to be associated with you.
I still have stuff on my account that is associated with Netflix and reddit. Because the account is tied to my personal account, those orgs can never "remove" my contribution.
This is pretty much the answer. GitHub identity <> Corporate identity. Jeff's portal helps join those two, so that permissions & legal can be handled automatically. If you ever contributed to a Microsoft Org owned repo, you'll get a bot asking you to sign the CLA and tagging your PRs DNM until you do. When I leave Microsoft, if I make any PRs later on (I'll probably end up using a few of these projects later on), they'll have removed me from Org and listed me as a non-MSFT, so I'd have to sign the CLA.
This portal is really nice compared to the previous system, which was send an email to someone and wait for them to get to it. :)
A malicious employee can simply send the code to the competitor. There is no need to set up an account that is controlled by the competitor to evade access protections.
How though? Can someone explain a situation where a GH organisation automatically gets access to another organisations' repos through a shared individual member?
At least they fixed the invite interface so that you can search for someone by name or email address.
Previously you could only add a user to your org by knowing their GH username. I was always paranoid I was going to typo and release my code to some random user.
In the past GitHub had a more open workflow (you just added people directly), but I think that was problematic...
For a while we hacked around this problem by letting third party associates "invite themselves" using a one-time use token in our portal, but we moved away from that since we no longer join externals to the org.
We're thinking of bringing it back, though, for "Outside Collaborators".
When working with open source, sometimes it is best to use the tools appropriate to the projects you are working on or people you are working with.
I work in DX/Evangelism at MSFT and a lot of work around containers, etc, at the moment is easier on *nix than it is on Windows (for me). I've got both machines as well as a Windows VM on the Mac if I need something there...
I think I remember about ten years ago somebody got fired from Microsoft for posting a photo of a MacPro (or two) being unloaded on the Microsoft campus. (Even though Microsoft was, of course, developing Office for Mac back then, so it was kind of obvious there had to be a couple of Macs around...)
My memory might be playing tricks on me here, but if it's not, things must have changed quite a bit.
I wasn't trying to make a browser politics statement in the post, but am glad to be able to work in the new Microsoft that is proud of whatever platform and tool works - including employees.
Personally I use Safari when I'm on battery all day (coffee shops, etc.), Chrome when I need multiple profile support, and I tend to split Chrome/Edge when in my Windows VM.
Recently minted Microsoft FTE here. Have Chrome and Firefox installed, do Linux stuff (Azure Cloud Solution Architect, customer-facing position). That "caught using the competition's product" thing doesn't match my experience here for the past month. At all.
I do sorely miss using a Mac (first time after nearly 10 years that I don't have one at hand, and it's a drag on productivity for me when I need to talk to Linux servers or run some tools locally), but I don't think anyone would blink twice if I brought my own Mac to the office, even considering that I'm at an European subsidiary.
The tool is really well done and impressive. Yes, it exists to work around gaps in GitHub's functionality, but it's not like we're going to self host git repos and use gitolite...
It's a scary place to be in when we're 1) dependent on a third party, 2) we have to follow GitHub and the API down the rabbit whole, and 3) we are just trying to enable our team to get going fast and hope in time GitHub can just give us all the right tools that check at least some boxes we need, i.e. very granular management to delegate decision making even more.
Any data that is stored on GitHub (ex issues, PRs) can be pulled down via the REST API. So, it should be relatively easy to build a migration tool or alternate UI if necessary.
Oh man... reminds me of svn2git migration I did, an integration of gitolite, deploying on-prem AD, jenkins, JIRA, Confluence and all working together a couple years back. Getting the LDAP query just right is 90% of it.
These days:
- JIRA - for internal, complex project management because the plugins are really good
- Confluence - wiki w/ plugins
- Asana
- Slack/FlowDock - waay better than digging through HipChat/Campfire, IRC
- Hubot - integrations/CLI for everything
- jenkins - for private CI
- Github enterprise - or maybe Gitlab if one can get away with it
- Google Apps for Work / Zoho - because of AD integrations
PS: When deploying a portal page whether internally or for a client, a bespoke 404 page with either a game or random funny images is the way to go. Maybe a humans.txt too.
[0] https://github.com/sitaramc/gitolite