GitHub Icon

GitHub

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

The GitHub Blog Icon The GitHub Blog

GitHub officially says farewell to Atom

GitHub will archive all projects under the Atom org on December 15, 2022. Why?

Atom has not had significant feature development for the past several years, though we’ve conducted maintenance and security updates during this period to ensure we’re being good stewards of the project and product. As new cloud-based tools have emerged and evolved over the years, Atom community involvement has declined significantly. As a result, we’ve decided to sunset Atom so we can focus on enhancing the developer experience in the cloud with GitHub Codespaces.

Atom was co-founder and long-time CEO Chris Wanstrath’s baby. We first heard its story from project lead Nathan Sobo on The Changelog back in 2017. Here’s what he had to say about the end of Atom’s era:

As Atom’s sun sets, Zed’s sun is rising. We’re not done here.

The GitHub Blog Icon The GitHub Blog

GitHub will require 2FA by the end of 2023

Mike Hanley on GitHub’s blog:

The software supply chain starts with the developer. Developer accounts are frequent targets for social engineering and account takeover, and protecting developers from these types of attacks is the first and most critical step toward securing the supply chain…

Today, as part of a platform-wide effort to secure the software ecosystem through improving account security, we’re announcing that GitHub will require all users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023.

This is a big step in the right direction and their new(ish) 2FA for GitHub Mobile feature helps make the burden not as cumbersome as it might be otherwise.

GitHub httpie.io

How HTTPie lost 54k GitHub stars

A tragic tale, but one worth sharing because we can all learn from their mistake:

Due to an unfortunate sequence of events, I accidentally made the project’s repository private for a moment. And GitHub cascade-deleted our community that took 10 years to build.

Whoops! This reminds me of the time I thought it’d be cute to set JSPartyFM’s Twitter birth date to the day our first episode shipped, which immediately resulted in the account being suspended for being too young.

Sounds like GitHub isn’t up for restoring their stars, so if you were following HTTPie before, you’ll want to head over there and give ’em a re-star.

GitHub github.com

HUBFS – a file system for GitHub

HUBFS is a file system for GitHub and Git. Git repositories and their contents are represented as regular directories and files and are accessible by any application, without the application having any knowledge that it is really accessing a remote Git repository. The repositories are writable and allow editing files and running build operations.

So if you hubfs mnt (on macOS/Linux), it will set up a file hierarchy inside /mnt that follows this pattern: / owner / repository / ref / path. Cool idea! It is affected by GitHub’s API rate limiting and I’m not sure if/how it syncs (commits) back to the remote repos…

Martin Heinz martinheinz.dev

Building GitHub Apps with Go

If you’re using GitHub as your version control system of choice then GitHub Apps can be incredibly useful for many tasks including building CI/CD, managing repositories, querying statistical data and much more. In this article we will walk through the process of building such an app in Go including setting up the GitHub integration, authenticating with GitHub, listening to webhooks, querying GitHub API and more.

The GitHub Blog Icon The GitHub Blog

GitHub has a new CEO

Thomas Dohmke will be CEO of GitHub. He served as GitHub’s Chief Product Officer, and according to his LinkedIn bio — Thomas led the acquisition of GitHub at Microsoft and the acquisitions of Dependabot, Semmle, and npm.

This morning, I shared the following post with Hubbers in response to Nat’s announcement about his next adventure. I am thrilled to take on the role of CEO to build the next phase of GitHub for our global community of software developers.

Exiting as CEO, Nat Friedman shared his thanks in a post titled “Thank you, GitHub”.

This morning, I sent the following post to the GitHub team. TL;DR: I’m moving on to my next adventure, and Thomas Dohmke (currently Chief Product Officer) will be GitHub’s next CEO. I will become Chairman Emeritus, which fulfills my lifelong ambition of having a title in Latin. My heartfelt thanks to every Hubber and every developer who makes GitHub what it is, every day.

Licensing fsf.org

Free Software Foundations declares GitHub Copilot "unacceptable and unjust"

The FSF is funding white papers on “philosophical and legal questions around Copilot”. In their post announcing the fund, Donald Robertson states:

The Free Software Foundation has received numerous inquiries about our position on these questions. We can see that Copilot’s use of freely licensed software has many implications for an incredibly large portion of the free software community. Developers want to know whether training a neural network on their software can really be considered fair use. Others who may be interested in using Copilot wonder if the code snippets and other elements copied from GitHub-hosted repositories could result in copyright infringement. And even if everything might be legally copacetic, activists wonder if there isn’t something fundamentally unfair about a proprietary software company building a service off their work.

One thing is for sure: there are many open questions that need answering. How we (as a community / industry) go about answering those questions is much less clear. But it’ll probably take place on blogs, forums, GitHub Issues, and even court rooms over the next decade.

RSS github.com

A GitHub Action to create single-show feeds from your Changelog++ feed

One of our awesome Changelog++ members scratched their own itch:

When you upgrade to Changelog++ you’re given access to ad-free versions of episodes however they’re only available in one giant bucket feed instead of through individual show feeds. Though only around 5 new podcast episodes are published weekly, if you’re coming in as a new listener you’ll have a long backlog list with over one thousand shows. It’s easier to sift through older episodes when they’re organized by show, so that’s what this project provides: individual show feeds.

I love grassroots initiatives like this, but it’s motivating me to bring Changelog++ onsite so we can bake the functionality right in to our platform…

Daniel Janus blog.danieljanus.pl

Things I wish Git had: Commit groups

Commit groups sounds interesting to me. Anyone reading this familiar with Git innards? Is this doable?

You know the “group” facility of vector graphics programs? You draw a couple of shapes, you group them together, and then you can apply transformations to the entire group at once, operating on it as if it were an atomic thing. But when need arises, you can “ungroup” it and look deeper.

I’d love to see that same idea applied to Git commits. In Git, a commit group might just be a named and annotated range of commits: feature-a might be the same as 5d64b71..3db02d3. Every Git command that currently accepts commit ranges could accept group names. I envision groups to have descriptions, so that git log, git blame, etc could take –grouped or –ungrouped options and act appropriately.

Kathy Korevec Medium

Maybe it’s time we re-think docs

Kathy Korevec has been putting a lot of thought into documentation as part of her work at GitHub:

Wouldn’t it be great if the docs knew that you were writing a Python app on a Windows machine and that you preferred watching videos instead of reading through text? I want you to find the answer to your questions in the docs, easily and efficiently. When you’re stuck on a problem and you turn to the docs, there’s a moment of magic as you find the solution, try it out and it works. In that moment you become unblocked, you learn something new and you can move on to keep building your application.

In this post, she outlines 10 guiding principles she developed after speaking with hundreds of developers about their struggles with documentation. She then shares how she’s putting those principles into action in/around GitHub. Good stuff.

SQLite phiresky.github.io

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.

RSS github.com

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

GitHub blog.arkency.com

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 daniel.haxx.se

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.

0:00 / 0:00