Today we’re introducing the GitHub Changelog–a chronological list of user-facing changes, large and small, made to the GitHub platform.
We regularly ship incremental improvements to make your GitHub experience even better. The changelog will supplement major release announcements on the GitHub Blog, encompassing smaller ships and enhancements you might not hear about otherwise. These include new features, security updates, deprecations, improvements, and more. Each entry will provide a short description of changes and direct you to additional resources, like documentation or blog posts.
As part of our work to open source policies for other companies to adapt and use, and in accordance with the UK Modern Slavery Act, we’ve included our Statement Against Modern Slavery and Child Labor in the latest round of updates to our Site Policy repository.
While modern slavery (slavery, forced or compulsory labor, trafficking, servitude, and workers who are imprisoned, indentured, or bonded) and child labor are not typically associated with software, businesses in all industries are increasingly recognizing that there are possibilities for these abuses to occur in their own labor force or through their sourcing practices.
We have no reason to believe modern slavery or child labor is occurring in our business or supply chain, and we have outlined our policies and due diligence processes to help ensure it won’t happen in the future. Given the abhorrent nature of modern slavery and child labor, prohibiting these atrocities in our business and supply chain is a logical and important commitment for GitHub to make.
While publishing a statement is a requirement for certain businesses under UK law, our statement goes beyond the requirements of that law by holding our suppliers to our statement too. Our statement also highlights our partnership with the FairHotel Program, through which we encourage GitHub employees to choose hotels where workers are paid fair wages, receive adequate benefits, and have a voice on the job. To ensure our commitment to preventing modern slavery and child labor in our business and supply chain, we’ll publish a new statement annually, building on our previous statements.
We announced the public beta of the open source, Electron-built version of GitHub Desktop a year ago, giving the GitHub community a unified GitHub experience for macOS and Windows. With every release, including the version 1.0 in September 2017, we’ve seen more people using GitHub Desktop to improve their workflows. Less than six months after 1.0 was released, more Desktop users were using the Electron-based version than both the classic versions for Mac and Windows combined.
Since its initial release, we’ve added more features to GitHub Desktop, including support for additional external editors, syntax highlighting support for additional languages, support for adding co-authors to commits, and the ability to view and checkout pull requests from collaborators or forks. Many of these new features were contributions from the open source community.
Starting today, if you’re still using the classic app, you’ll see in-app notifications suggesting an upgrade to the new GitHub Desktop with information on what’s changed. If you are still using GitHub for Mac or GitHub for Windows, or if you’ve never used our desktop apps, try out the new GitHub Desktop.
As more people contribute to your project, the issue tracker can start to feel hectic. We recently helped project maintainers set up multiple issue templates as a way to manage contributions, and now we’re following up with a better contributor experience and improved setup process.
When someone opens a new issue in your project, you can now prompt them to choose from multiple issue types.
To add this experience to your repository, go to the “Settings” tab and click Set up templates—or add a template from your community profile. You’ll be able to use a builder to preview and edit existing templates or create a custom template.
Once these changes are merged into master, the new issue templates will be live for contributors. Head over to your project settings to get started.
Today, custom domains on GitHub Pages are gaining support for HTTPS.
GitHub Pages is the best way to quickly publish beautiful websites for you and your projects. Just edit, push, and your changes are live. GitHub Pages has supported custom domains since 2009, and sites on the
*.github.io domain have supported HTTPS since 2016. Today, custom domains on GitHub Pages are gaining support for HTTPS as well, meaning over a million GitHub Pages sites will be served over HTTPS.
HTTPS (most recognizable as the lock icon in your browser’s address bar) encrypts traffic between GitHub’s servers and your browser giving you confidence that the page you asked for is the page you’re reading, from the site you think it is, and that others can’t snoop on or modify its contents along the way.
We have partnered with the certificate authority Let’s Encrypt on this project. As supporters of Let’s Encrypt’s mission to make the web more secure for everyone, we’ve officially become Silver-level sponsors of the initiative.
Action may be required on your part to secure your custom domain.
If you are using
ALIAS records for your custom domain, you’re all set and your site should be accessible over HTTPS. If it is, and your site loads correctly over HTTPS, you can optionally enforce HTTPS in your repository’s settings. Users who request your site over HTTP will be upgraded to HTTPS.
If you are using
A records, you must update your site’s DNS records with new IP addresses. Please see our guide to setting up your custom domain with Pages and update any A records you might have set.
Once your updated DNS records have propagated, and you’ve confirmed that your site loads correctly over HTTPS, you can optionally “Enforce HTTPS” for your domain in your repository’s settings, ensuring users who request your site over HTTP are upgraded to HTTPS.
These new IP addresses don’t just allow us to serve your site over HTTPS, but also places your site behind a content delivery network (CDN), allowing us to serve your site from data centers around the world at fast speeds, and offering additional protection against DDoS attacks. While the previous IP addresses will remain available for a transition period, we recommend you migrate to the new IP addresses to gain these benefits.