GitHub Icon


GitHub is where millions of developers gather every day to collaborate on open source software.
115 Stories
All Topics


Hosting SQLite databases on GitHub Pages

The benefits of such a setup are numerous, especially for small sites and side projects:

Hosting a static website is much easier than a “real” server - there’s many free and reliable options (like GitHub, GitLab Pages, Netlify, etc), and it scales to basically infinity without any effort.

The how is also super interesting:

So how do you use a database on a static file hoster? Firstly, SQLite (written in C) is compiled to WebAssembly. SQLite can be compiled with emscripten without any modifications, and the sql.js library is a thin JS wrapper around the wasm code.

There’s more to the story, and the resulting solution is also open source.


A web-based RSS reader running entirely from your GitHub repo

The feed is hosted on GitHub Pages (which means it’s public to all) and is static until it gets rebuilt. Building is done periodically via a GitHub Action; configuration is via a YAML file (It’d be cooler if you could import an OPML instead). Even if it’s not something you’d use, I think this project is interesting for two reasons:

  1. It’s part of a “GitHub as Stack” meta-trend
  2. It promotes RSS, which is one of the web’s great treasures


Disadvantages of Pull Requests

In this post, Tomas Wróbel lays out 10 potential drawbacks to the typical PR flows:

  1. More long living branches, more merge conflicts
  2. The reviewability of a change decreases with size
  3. Short feedback loop makes programming fun
  4. Reviews tend to be superficial
  5. Merging is blocked by remarks that shouldn’t be blocking
  6. It’s easier to fix than to explain the fix
  7. Developers are slower to adapt the responsibility mindset
  8. PRs discourage continuous refactoring
  9. Negative emotions and outright pathology
  10. How do you switch to branches with migrations

Daniel Stenberg

What if GitHub is the devil?

Daniel Stenberg answers critics who believe curl shouldn’t be hosted on GitHub (for various reasons) by asking himself the question: what happens if GitHub “takes the ball and goes home”?

No matter which service we use, there’s always a risk that they will turn off the light one day and not come back – or just change the rules or licensing terms that would prevent us from staying there. We cannot avoid that risk. But we can make sure that we’re smart about it, have a contingency plan or at least an idea of what to do when that day comes.

Whether or not you agree with Daniel’s GitHub-related conclusions, this statement is 💯% true and we should all be doing similar analyses before adopting any 3rd-party offering.


An uptime monitor and status page powered by GitHub Actions

Okay this is pretty stinkin’ clever.

  • GitHub Actions is used as an uptime monitor
    • Every 5 minutes, a workflow visits your website to make sure it’s up
    • Response time is recorded every 6 hours and committed to git
    • Graphs of response time are generated every day
  • GitHub Issues are used for incident reports
    • An issue is opened if an endpoint is down
    • People from your team are assigned to the issue
    • Incidents reports are posted as issue comments
    • Issues are locked so non-members cannot comment on them
    • Issues are closed automatically when your site comes back up
    • Slack notifications are sent on updates
  • GitHub Pages are used for the status website
    • A simple, beautiful, and accessible PWA is generated
    • Built with Svelte and Sapper
    • Fetches data from this repository using the GitHub API

Maxime Vaillancourt

Automatically labeling GitHub notification emails with Gmail filters

Maintaining a GitHub project with other people creates “many email notifications about various things.” But they don’t all hold the same importance. Maxime Vaillancourt shows us how to use Gmail filters and labels to better manage all the emails coming from GitHub issues, etc.

I receive many email notifications about various things that happen on there: direct requests to review a particular piece of code, feedback on pull requests I’ve opened, pull requests merged by their authors, people directly mentioning our username in a comment, issues closed by their authors, etc. I receive hundreds of emails every single week.

…using Gmail filters, we can automatically add labels to GitHub notification emails based on their content. This solution takes less than 10 minutes to implement, and the long-term return on investment is quite appreciable.

Automatically labeling GitHub notification emails with Gmail filters

Ezekiel Sikelianos

How we open sourced

GitHub open sourced this long-lived private project. Learn about the why and how in this post…

Last week we open sourced all of GitHub’s product documentation, along with the Node.js web application that powers it. Check out our new public repository at

This post tells the story of why we wanted to open source the docs, what tools we built and open sourced along the way, and how we worked to make the project welcoming to external contributors.

Romain Barissat

A GitHub Action to maintain mono-to-many repos

Romain Barissat:

I made this to be able to open-source parts of our monorepo while keeping the rest private.

The result is a tool that allows you to have one monorepo that is the source of truth for as many other repos as you want. It could also be used to create “workspace” repos if you onboard a freelance and you don’t want to give him access to your whole mono-repo.

We are using nx as a monorepo tool, here is an example of it using the Copybara Action

Based on Google’s Copybara project.


The GitHub CLI goes 1.0

If you haven’t given the new gh a look since they announced the beta earlier this year, a lot has changed:

Since we released the beta, users have created over 250,000 pull requests, performed over 350,000 merges, and created over 20,000 issues with GitHub CLI.

It’s available for all major operating systems and if your development workflow goes through GitHub you will undoubtedly save some time and typing by adopting it.

GitHub Blog Icon GitHub Blog

"Set the default branch name" feature has landed on GitHub

Following Git 2.28’s highly sought after ability to configure init.defaultBranch comes GitHub’s support at the platform level.

You can now set the default branch name for newly-created repositories under your username. This setting does not impact any of your existing repositories. Existing repositories will continue to have the same default branch they have now.

But even if you do nothing…

On October 1, 2020, if you haven’t changed the default branch for new repositories for your user, organization, or enterprise, it will automatically change from master to main.


GitHub's public roadmap

Two days ago on this repo appeared on the top starred repositories first timers list on Changelog Nightly

In this repository, you can find the official GitHub public product roadmap. Our product roadmap is where you can learn about what features we’re working on, what stage they’re in, and when we expect to bring them to you.

The roadmap repository is for communicating GitHub’s roadmap. Existing issues are currently read-only, and we are locking conversations, as we get started. Interaction limits are also in place to ensure issues originate from GitHub. We’re planning to iterate on the format of the roadmap itself, and we see potential to engage more in discussions about the future of GitHub products and features.

Taylor Blau GitHub Blog

Git 2.28 brings `init.defaultBranch`

Leading off the updates for Git 2.28 is the highly sought after ability to configure init.defaultBranch so folks can move from master to main as their default branch name.

From Taylor Blau on the GitHub blog:

When you initialize a new Git repository from scratch with git init, Git has always created an initial first branch with the name master. In Git 2.28, a new configuration option, init.defaultBranch is being introduced to replace the hard-coded term. (For more background on this change, this statement from the Software Freedom Conservancy is an excellent place to look).

Starting in Git 2.28, git init will instead look to the value of init.defaultBranch when creating the first branch in a new repository. If that value is unset, init.defaultBranch defaults to master

Also check out github/renaming to learn more about the complementary changes GitHub is making. GitLab and Bitbucket are making similar changes.

Git 2.28 brings `init.defaultBranch`

Jerod Santo YouTube

Jonathan Clem from the GitHub Actions team joins me for a jam session

I thought it’d be cool to get mix test and mix format running on pushes to the repo, so I gave GitHub Actions the old college try. After (not too much) futzing around on my own, I figured I’d have more success by getting an expert to help out. Good call be me! 😆

In this ~1 hour jam session, we go from zero to a successful Actions workflow. I learned a lot along the way, and you might too by joining us on the journey. Thanks, Jonathan!

Caleb Porzio

I just hit $100,000/yr on GitHub Sponsors 🎉

I am now making more money than I’ve ever made while developing open-source software for a community that I adore. Pinch me, I’m dreaming.

Was it luck? there’s certainly been a lot of that.

Was it fate? Let’s leave religion out of this mmkay?…

Was it that the software I built was so incredibly compelling that it forced 535 people to give me at least $14/mo. to keep working on it? …I wish.

It’s more than that though. There were some key things I did along the way to get here. Let me tell you all about them.

0:00 / 0:00