Think Twice Before Downgrading to a Free GitHub Account

[wikwocket]

For what it's worth, protected branches are pretty clearly listed as a "Github Pro" feature in their pricing page.

I agree that it'd be nice if they warned you about features you're using that will be turned off, but I don't think it's unreasonable to expect that people requesting downgrades understand which features are in which plan.

Maybe this could be suggested to GitHub's Paperclips project, to avoid future confusion?

[Ensorceled]

Agreed. But there were a lot of people celebrating GitHub’s recent free account changes who were saying you no longer needed the pro account; this is a good reminder that you may need the pro account after all and do that check.

[endergen]

I read this post as a sharing of a confusion/assumption made. Not everyone reads fine print or manual, but ha will read HN.

[xtracto]

Interesting, protected branches come free in GitLab. I never used Github to host my serious repos (I was using Bitbucket as soon as they started providing Git in addition to Hg).

I would suppose that as time passes by, Microsoft will improve the free offering avaialable on their service.

[dustinmoris]

Did someone really just write a blog post on not downgrading an account without knowing what you're doing? Yes, you should not do that. You also shouldn't buy something without knowing what you're paying for, shouldn't vote for something you don't know what it is, you shouldn't eat stuff which might be poisonous but don't know for sure, you shouldn't cross a street without looking, gosh you certainly shouldn't drive a car with closed eyes not knowing where you're driving. Let's remind everyone of these things regularly, as this stuff is apparently not obvious anymore in 2019.

[Tenhundfeld]

The OP clearly says, "It’s my fault for not reading the fine print more carefully."

They then further go on to say, "... when upgrading back to a Pro account, any branch protection rules you had before were permanently deleted when you downgraded to the free tier. They will all have to be recreated from scratch."

That is useful information, to me. People write blog posts about all types of things that are obvious to some and useful to others. Why be so nasty about this short post that seems to be useful to a lot of people? I guess that's 2019 for ya.

It's easy to ask snarky questions. That doesn't mean it's helpful or witty.

[Shish2k]

> shouldn't vote for something you don't know what it is

Isn't the whole point of democracy "a large enough volume of ignorance will average out to something sensible"? :P

[MarHoff]

But isn't that a new behavior? Before I subscribed 1-2 year ago I read small characters pretty carefully, and in my memories in such case the behavior was to lock the previously private repo in a read-only state. Switching back to pro would then have restored full functionalities and setting on theses privates repos.

Automatically making it public seems like a new behavior, could someone confirm/infirm my memories?

[collinvandyck76]

my guess is that the righteous anger you felt while writing this post will be converted to regret down the road, possibly years later.

[ausbah]

its never been "obvious" in any point in history

[moviuro]

FWIW, Branch protection looks like it's a free feature on Gitlab [0]

[0] https://docs.gitlab.com/ee/user/project/protected_branches.h...

[dsumenkovic]

That's right, it's available in both free (SaaS) and core( self hosted) tiers.

[sli]

If your account is downgraded automatically, Github will extort you for access to your private repositories. You don't get the option to just set them to public and stay on the free tier, Github simply forces you to pay up to get them back or lose them permanently.

Found this out when my old student account lapsed after I left college. Luckily, they screwed up and unlocked my private repos when attempting to charge me (there was no credit card on my Github account and never was -- nice work, Github) and I was able to pull my private repos and move everything to Gitlab.

Zero regrets. Extortion is never acceptable, especially when it's policy.

[zrobotics]

So if I don't pay the cable bill and my internet gets shut off, can I reasonably say I am being extorted by the cable company? That's a little hyperbolic. Plus, this isn't even how GH operates anymore, since they now offer free private repos.

[oliwarner]

I assume this is distant history.

Free accounts are now allowed unlimited numbers of private repos with limited collaboration.

But I would also not classify as removing access when you stop paying as extortion. You know when your account is paid up to. You would therefore know when you'd have featureful access to. It's not their fault you can't plan ahead is it?

[eugeniub]

I'm seeing people here chastising the OP for not fully knowing what he was getting into. But in all the excitement about the new free plan with private repos in January, GitHub failed to highlight other differences between the new free plan and the rebranded Pro plan.

We can blame the end user all we want, but GitHub could have prevented all of this.

[floatingatoll]

OP: Thanks for writing this up. I emailed your post as a downgrade UX bug report to GitHub Support. Hopefully they agree and fix it.

[pstadler]

Hosting private repositories on GitHub pages is another feature only available with the Pro plan. Figured this one out a few days after canceling my subscription.

[eugeniub]

I figured it out on the day my subscription lapsed, and someone created their own repository using my domain in their CNAME file. I had to wait until GitHub banned the user until I could set up the domain with GitHub Pages again.

[steve_taylor]

It’s free on gitlab.com and you can have as many as you want. I recently parked about 10 domains there.

[latchkey]

> I live in mortal fear of making a dumb mistake and losing irreplaceable source code.

Then store backups of your repositories somewhere else than GitHub.

[johnchristopher]

Exactly. Git and github aren't backup tools. I always feel like github (and others) added to the git workflow things that are bolted on top of it and tie you to their platform.

[leokennis]

Indeed. I consider any file I don’t have at least on two pieces of on equipment that I own (computer, NAS, external HDD etc.) to be already gone.

Cloud backup (Backblaze etc.) is for when my house is on fire. But the only backups I actually trust are the ones that I have 100% control over.

[black-tea]

It amazes me how many people just don't grasp the "distributed" part of git. No repository is special and it's trivially easy to make a new one somewhere.

[syshum]

But it is in the cloud this means never having to worry about backups /s

[d2p]

I downgraded too, and noticed GitHub Pages stopped working (the content is still there, but they don't rebuild - although they did for a little while after downgrading). It is clearly marked as a Pro feature, I just hadn't considered that the free private repos would be more restricted.

It's not a big deal to me, I'll probably just make the repos public.

[leethargo]

I have a free GitHub account and also have GitHub Pages for my blog, which is developed in one of my public repos.

Do you mean some specific additional features for GitHub Pages, such as a vanity URL, or building from private repos?

[Ristovski]

This answers a question I had I guess. I thought with the new free-tier stuff like private repos - GH pages would still work :(

[aequitas]

To some it might seem weird, but in cases like this having even your repository configuration in Configuration management makes sense, for example using Terraform[0]. Of course you have a chicken-egg problem for that first repo that actually contains your CI code. But if you just apply common sense that problem doesn't really exist.

With repositories it is just so easy for little configuration drift to slip in. A branch you forgot to protect. A user/group that should no longer have write permissions, etc.

[0] https://www.terraform.io/docs/providers/github/r/branch_prot... https://www.terraform.io/docs/providers/type/vcs-index.html

[amelius]

I think it's stupid that GitHub stores (meta-) data in a place that's not governed by git. Everything should be in git.

[copperx]

Are you suggesting that GitHub should fork git to add new features?

[thrownaway954]

honestly though... how many everyday devs actually use something like this?

[SeriousM]

Gitlab has private repos for free and the service is imho on par with github

[dsgriffin]

I agree, and quite like Gitlab, but Github's recent decision to allow free private repos has surely put a bit of a dent in Gitlab/Bitbucket's marketshare expansion - many people were using those services instead of Github just for that feature.

[giancarlostoro]

As does BitBucket which I prefer just because it matches what I use at work. I also keep a GitLab for backup type reasons.

[reledi]

There is less risk without protected branches than you think, especially if you catch and contain the problem early.

GitHub allows you to restore branches and commits are restorable from the ref log.

[jayeshsalvi]

There is a more serious impact of downgrading if you were hosting a static website from a private repository on github with a pro account. Apparently that's not supported with free account. My personal website went down as soon as I downgraded to free. I didn't mind making the repo public, so it was an easy fix, but may not be same for others.

[natfriedman]

Jared is right that we should alert users about this before they downgrade. We’ll add some UI for this.

https://twitter.com/natfriedman/status/1109880047207235589?s...

[theshadowmonkey]

Using gitlab and bitbucket for my personal repos on their free tiers have solved a lot of problems for me. Also, a lot of features are way ahead of github on these 2 platforms including CI/CD, Code reviews, and other tooling.

[el_dev_hell]

I am so glad I read this before downgrading.

Sorry to hear!

[ddtaylor]

Does this mean free accounts cannot have private repositories?

[richardwhiuk]

They can have private repos - it's just branch protection rules which are no go.

[sigi45]

What? What is he doing that it makes him fear code loss?

[d2p]

It's fairly common to do `git push --force` (or hopefully `--force-with-lease`) after operations like rebasing. This overwrites the remote history, so can easily lose work. Many people set some branches as protected, so they can't be force-pushed over accidentally.

[progval]

git push --force

It doesn't actually delete the commits, but you can't find them anymore if you don't remember the hash of the former head commit of the branch