Nothing beats https://bitbucket.org/ when it comes to free, unlimited, private repositories. It has seen the first hosted repositories of far more startups than github ever will. Which is special achievement in itself.
You should check out gitlab.com
Introducing unlimited private repositories
451–460 of 662 posts
Re: Introducing unlimited private repositories
#452It seems most users here don't have gitlab.com in their radar and only mentioning Bitbucket as competitor. I've recently switched all my private personal repos to gitlab.com which also allows unlimited private repositories because gitlab.com seems to have better UI and more features than Bitbucket (when not buying any additional Atlassian Jira etc. products).
Installation is easy, upgrading (even between major versions) is completely painless, you get integration with Gitlab Continuous Integration, the Community Edition doesn't feel artificially gimped to get you to switch to a paid plan, Gitlab is great at fixing security issues. I also love the UX and it's not missing any feature in my experience compared to GitHub/Bitbucket.
I'm not affiliated with Gitlab in any way but it's honestly one of the rare pieces of software I only have praise for.
Re: Introducing unlimited private repositories
#453Earlier quoted context omitted.
This was exactly the reason we used Bitbucket in the beginning, even if it was worse in some aspects. Github would have been simply too expensive (or restricting) with our "it's always in source control" approach, even for smaller prototypes. We're happy Gitlab users now by the way - and I'm curious how long Github will survive with their over-valuation as the alternatives get seriously better now - the lock-in and n…
Just wanted to add that if you don't want to run GitLab yourself our GitLab.com is free with unlimited private repositories but it also has also unlimited private collaborators https://about.gitlab.com/gitlab-com/
Re: Introducing unlimited private repositories
#454Earlier quoted context omitted.
If every organization went to free alternatives, not only would those free alternatives need a source of revenue to support the new business, I think you'd find they too will change their pricing structure to better fit the people that use their product. One thing I also have to mention is a majority of for profit organizations have no problem paying for services they use. HN is a special snowflake on the internet, i…
On Gitlab.com's homepage[0] there is a giant product listing showing you exactly what you are saying they need to have: A source of revenue (GitLab Enterprise Edition). [0]: https://about.gitlab.com/
Just my 2c anyways, happy to hear feedback on why I'm wrong :)
Re: Introducing unlimited private repositories
#455Earlier quoted context omitted.
care to explain why? I need to keep my API keys somewhere so I can roll them out to the machine. Keeping them in git is as good as any storage - what would you propose instead? A shared dropbox account?
What the hell? Are you defending a decision to keep keys unencrypted in a git repo?
If "A developer could have their GitHub account broken into" or "Someone could break into GitHub deeply enough that they could access private repos" are in your threat model, you shouldn't be using GitHub at all for anything, including code, because it would be straightforward to use that access to subvert your site in other ways. Which is to say, especially for small sites, that's not a useful threat model.
If "You might do a git commit to remove them, then push the repo somewhere" is in your threat model, then the answer is just "Don't do that" (or more precisely, "Make sure everyone on the team understands that can't be done without precautions"). The easiest way to don't-do-that is to have them in a separate git repo from your code. But either way, as projects grow, there's going to be stuff in your git history you don't want to be public (like, oh, git commit -m "Implementing this stupid feature because this customer is stupid") because human error happens sometimes. So if you want to publish a previously-private codebase, the only robust approach is to copy all the files into a new non-git repo and make a new commit.
And the other part of the cryptographer's reply is, where else are you going to store the secrets and what are its security properties?
Re: Introducing unlimited private repositories
#456I find it interesting that so many people here are unhappy with the change. Sure, prices will go up for a lot of organizations, but is $9/worker/month really a lot to pay for all the stuff GitHub offers? At Bay Area prices isn't that about 5 minutes of developer pay per month? For independent use it seems like a very positive change, in fact I'm guessing it's a direct challenge to GitLab. I was considering moving my…
Do you seriously believe that programmers everywhere in the world are making the same money as ones at Bay Area?
Re: Introducing unlimited private repositories
#457Earlier quoted context omitted.
I hope that any team using github to share passwords is driven to move away from that method because of this price change. That's a bad bad idea.
Why? If it is Encrypted in ansible vault or something it's not a terrible way to keep your creds.
Re: Introducing unlimited private repositories
#458Earlier quoted context omitted.
never store sensitive data like API keys in a repository. Or you can do that but encrypt it so that nobody which can view your repo (even if it's private) can use that data immediately. It's like storing passwords in plaintext in a DB. Every (DB) admin will tell you: Don't/Never do that. I've recently also have to do with this problems while doing server setup with a private repo. I'm using Ansible and Ansible Vault…
see, the whole repo is accessible to the members of the team that are allowed to see the secret - basically the two folks that have root on the machine anyways. There's very limited use in encrypting the repo. There are no SSL keys or any secrets that would require tight security. It's basically our newrelic and some other api keys for reporting services. Even if that repo would be breached you could only start sendi…
Re: Introducing unlimited private repositories
#459Earlier quoted context omitted.
All the production code here is on BitBucket. Forcing users to pay for privacy has always stuck in my throat as a business model. I think this change is due to GitHub feeling some heat from Atlassian and GitLab.
I have a lot of half-finished projects kicking around that I would love to start on github, but I'm concerned about privacy and it certainly isn't worth it to me to pay $7/mo rather than keeping them on my Dropbox. I haven't checked out BitBucket as I kind of thought GitHub was the only game in town, but will check it out. Would be nice to get these projects off my machine but not make them public. edit: ohh and I'm…
Re: Introducing unlimited private repositories
#460Earlier quoted context omitted.
> beware if your open source project needs a single private repository to share passwords Passwords emphatically do not belong in git. Your private repos should be maintained such that accessing them would not compromise your security.
if you share Ansible inventory files that are encrypted with ansible-vault, then this is not happening. But i still wouldn't want to have a public repository with the files and the metadata of servers that is clearly not meant for public consumption. Let me brig another example for OSS projects that could need a private repository: branches for security fixes that are not public yet.
A private git server would probably be better for that, but also wouldn't cost $0.