Skip to content

GitHub Pages drops support for RDiscount, Redcarpet, and RedCloth (Textile) markup engines

Back in February, we announced, that GitHub Pages would be dropping support for the RDiscount, Redcarpet, and RedCloth (Textile) markup engines, and today we're making it official.

For the vast majority of users, making the switch should be easy, as kramdown supports all of RDiscount and Redcarpet's most popular features. If you're making the transition from Textile, follow these instructions to upgrade your site to Markdown.

In standardizing on a single Markdown engine, we're able to simplify and improve the publishing experience, by removing much of the confusion and complexity associated with the differences between various markdown interpretations, bringing things more closely in line with what you'd expect from Markdown rendering on See last month's blog post on the subject, for more context behind our decision.

If you're still using RDiscount, Redcarpet, or RedCloth, next time you push to your GitHub Pages site, you will receive an email from us with instructions on how to upgrade. We highly recommend you test building your site locally with kramdown prior to pushing. If you're a GitHub Enterprise user, this change will affect GitHub Enterprise versions 2.7 and later.

In most cases, upgrading to kramdown should be a matter of updating your site's configuration. If in the off chance you do run into any trouble, please get in touch with us, or if you have questions about what this change means for your GitHub Enterprise appliance, please contact GitHub Enterprise support. We're here to help.

Get insights from GitHub customers, community, and leaders at Satellite


Join the European developer community at GitHub Satellite in Amsterdam on May 11 to hear how organizations like Facebook, Heroku, GOV.UK, and Spotify are building software and contributing to open source. 

We’ll also share the latest on GitHub products and services, beginning with a keynote from GitHub CEO Chris Wanstrath. Check out talks from GitHub engineers and executives, including inside stories about projects like scaling GitHub, DevOps workflows, and Electron.




To close out the day, GitHub's VP of Social Impact, Nicole Sanchez, will lead a session featuring the amazing stories of nonprofits Fred Hutch and Code to Inspire, which are using technology to pave the way to a more inclusive society and a healthier world.

Hands-on Help

While you're at Satellite, you can also get your Git and GitHub questions answered personally by experts from our Services team! Schedule your one-on-one session here.

Grab tickets now, before we sell out!

GitHub Enterprise 2.6 is here with faster, more approachable workflows

A new release of GitHub Enterprise is now available—and includes features requested by developers across the GitHub community. With GitHub Enterprise 2.6, we’re introducing tools and updates that will provide teams with even more options to create efficient, flexible, and friendly processes at every step of their development cycles.

All teams work differently, so it’s important that GitHub Enterprise supports the effort they put into creating efficient, effective tooling. In this release, administrators will find tools that save time throughout their development processes, including Issue templates and support for pre-receive hooks.

GitHub Enterprise 2.6 will also help teams have productive conversations. Developers can more efficiently review code and comments with new ways to view the history of their pull requests. And to make GitHub a better communication tool for all team members, we’ve added the option to drag and drop files into repositories using the GitHub interface and an editor to style issues and comments without markdown.

Ready to upgrade? Upgrade now.

Build a workflow that works for your team

The latest release adds features and support to help you and your team create even more tailored, efficient workflows. Administrators can now:

Protect branches with greater flexibility

With more than 100,000 people pushing to nearly 300,000 Protected Branches every week, we've found a few ways to make them better. Administrators now have more flexibility over their Protected Branches with the option to merge out-of-date pull requests and set restrictions on which users and teams can merge branches. Check out the documentation to learn how.

Let your team know what's happening, fast

From GitHub Enterprise 2.6 onwards administrators can set up custom messages to share with developers on their GitHub Enterprise sign-in page. Administrators can also write custom messages for suspended users to appear when anyone with a suspended account tries to log in. See how you can use custom messages to communicate with your team.

Flexibly review pull requests

Effective code review catches bugs before they’re deployed, improves code consistency, and helps educate new developers. Since our last release, we've worked to make reviewing pull requests faster and more flexible. With GitHub Enterprise 2.6, you can:

  • Quickly find files to review, and filter them by name or extension
  • Filter changes by commit to see how a pull request has evolved through time
  • Pick up where you left off, and view new changes to pull requests since your last visit

Choose how you commit

Shape your workflow however you like. The organization of your Git history is just one of the choices to make, but up until now the merge button on GitHub only created merge commits. Now you also have the option to squash merge—squashing all of your commits into a tidy, easy-to-digest history. Learn more about squash merging.

Communicate better across GitHub, across teams

To help everyone on your team share their ideas, we've added features to streamline feedback and open up your development process to even more team members. Your team can now:

Upgrade today

GitHub Enterprise 2.6 is driven by developer and community feedback and includes some of our most requested improvements. Upgrade today, so your team can start taking advantage of them. You can also check out the release notes to see what else is new or enable update checks to automatically update your instance whenever there is a new release.

Expanded webhook events

Webhooks are one of the more powerful ways to extend GitHub. They allow internal tools and third-party integrations to subscribe to specific activity on GitHub and receive notifications (via an HTTP POST) to an external web server when those events happen. They are often used to trigger CI builds, deploy applications, or update external bug trackers.

Based on your feedback, we've expanded the kinds of events to which you can subscribe. New events include:

  • Editing an issue or pull request's title or body
  • Changing a repository's visibility to public or private
  • Deleting a repository
  • Editing an issue comment, pull request comment, or review comment
  • Deleting an issue comment, pull request comment, or review comment

When the action in question was an edit, the webhook's payload will helpfully point out what changed.

changed payload

These expanded webhook events are now available on For more information, check out the developer blog and take a look at the documentation for a full list of webhook events.

Preview GitHub Pages metadata locally

A year ago, Jekyll sites on GitHub pages gained access to repository and organization metadata with the introduction of the site.github namespace.

We recently moved our own site.github implementation to use the community-driven GitHub metadata Jekyll plugin, meaning it's now easier to preview sites locally that rely on repository or organization metadata using the exact same process GitHub Pages uses to build your site in production.

To recreate the site.github namespace when previewing your site locally, assuming you're using the GitHub Pages gem, simply add the jekyll-github-metadata gem to your site's config:

 - jekyll-github-metadata

For more information on using repository and organization metadata, when previewing locally or on GitHub Pages, see the plugin and repository metadata documentation.

Join us at GitHub Satellite to hear how top European companies build software

Technology has fundamentally changed the way people work. As businesses from every industry build more software, new challenges and opportunities arise. Join us at GitHub Satellite to glimpse how developers are using software to change the way their companies work.

GitHub's VP of Product Kakul Srivastava will host engineering leaders from some of Europe's best-known companies for a panel discussion. Hear from Tesco, Zalando, UBS, and KPN on why they’ve evolved their focuses on manufacturing, retail, finance, and telecomms to include significant investments in software development.


Meet the panel

Tesco Stores, Joshua Anderson, Technology Product Owner

Zalando, Eric Bowman, VP Engineering

UBS Thomas Sugden, Executive Director

KPN, Jerry Caupain, IT Architect

About the discussion

Championing modern development practices

The move to modern software development practices often starts with small projects championed by individual developers. During the panel, we’ll discuss the evolving role of the developer, how to advocate for change within your organization, and challenges for securing support from executives.

Trade secrets: tools, integrations, and organizational structures

This panel gives you a chance to peek behind the curtain of Europe’s leading companies to see how they organize teams and people around software, the tools they can’t live without, and the creative ways they integrate with GitHub.

From InnerSource to open source

No discussion on modern software development would be complete without an exploration of open source. We’ll ask panel participants about their strategies for organizing around, consuming, and contributing to open source software projects, and how it impacts their developers.

GitHub Satellite sessions announced


We're pleased to welcome an excellent lineup of speakers to GitHub Satellite, the first ever international event in the GitHub Universe conference series. On May 11, 2016, 500 people will converge in Amsterdam to learn how developers, founders, activists, and more create impactful technologies.

Check out sessions led by GitHub executives and engineers like CEO Chris Wanstrath, VP of Social Impact Nicole Sanchez, and Head of Open Source Brandon Keepers. We'll also feature talks from GitHub customers and partners, open source maintainers, and organizations who are building software for social good.

The GitHub Satellite program is organized into two tracks:


The Discover track provides an introduction to the ideas, people and companies who are advancing the world through software, creating business transformation, or building the methodologies and practices that will drive software development into the future.


The Develop track provides practical and tactical advice to developers seeking to implement modern software development practices, maintain or evolve open source projects and communities, and adopt best practices for scaling or building integrations for GitHub.

Check out the schedule and grab a ticket and we'll see you in Amsterdam.

Call for proposals: CodeConf LA - June 27-29, 2016

CodeConf LA June 27-29

CodeConf LA will converge June 27-29, 2016 in sunny Los Angeles for three days of unforgettable discussions.

We're searching for the best talks that the open source community has to offer. We'd like opinionated, thoughtful, and compelling sessions that will leave everyone that attends thinking differently about the open source ecosystem. This year’s event will focus on systems engineering projects, practices, and programs in the open source community. We are looking for a wide range of topics from all over the systems community, with topics ranging from systems programming practices to operating applications at scale.

We welcome speakers with all level of experience, whether it's your first talk or your fiftieth. We are also actively seeking a diverse line-up of speakers across all dimensions.

The call for proposals closes April 29, 2016 at 11:59pm PST. Please get in touch if you have any questions about the conference or the application process.

GitHub Shop: water bottles are here

Stay hydrated while sharing your love for GitHub with the new water bottle. Available in the GitHub Shop

Water Bottle

Meet Richard Davey, creator of Phaser

To highlight the people behind projects we admire, we bring you the GitHub Developer Profile blog series.

Richard Davey

Meet Richard Davey, the game developer behind Phaser — a free open source HTML5 game framework used by developers from indies and multi-national digital agencies to schools and universities. A 34-year veteran dev, Richard built Phaser using Pixi.js for WebGL and Canvas rendering across desktop and mobile web browsers. The project is maintained by an enthusiastic open source community as well as Photon Storm Limited, a collaboration that has made Phaser one of the most starred game frameworks on GitHub. A pure gamer at heart, Richard is building tools that make it possible for thousands of people to turn their ideas into reality. We asked him to share the story of how he became a developer, and what he’s learned from his work.

Lee: Who inspired you when you were learning to program?

Richard: I looked up to those who were part of the demoscene. This counterculture took pride in pushing those humble little machines to their absolute limits. They would try crazy new hardware tricks and make them do things even the original chip designers never thought possible. Of course, most of the people in the scene were quite young, too, and this was reflected in their creations. Entire new art forms and styles of music emerged from those days, and it's still going on now.

Although there were many one-person game studios back then, typically their games would still be released by publishers. It was hard to recognise individual developers to look up to. There were some notable exceptions of course, like Jeff Minter, the Oliver Twins, Andrew Braybrook and Raffaele Cecco, but generally you'd only know about them because they appeared in magazines, often sharing coding tips.

Lee: The Oliver Twins were a huge inspiration for me - I also have them to thank for getting me into software development. How did you get into it originally?

Richard: Like lots of kids in the 1980s, my first taste of programming was on 8-bit home micros such as the MSX and ZX Spectrum. I spent countless hours pouring over type-in listings from computer magazines, tweaking things here and there to see what effect it would have on the game. Because those early machines were cassette-tape based, I often wouldn't even try to save my work. Or, it would get corrupted during the recording process. I'd literally type the code in, play with it until I got bored, and then turn it all off.

Moon Mission code listing Example listing from the December 1983 edition of Computer and Video Games magazine.

One day I went to a friend’s house after school and he had a brand new Atari ST plugged into the living room TV. He fired-up a copy of the game Bubble Bobble, and that was it. I was utterly blown away. My poor parents didn't hear the end of it, and I finally managed to get an Atari ST of my own. It was on this that I started doing game art and development properly (and yes, I would actually save my work now!).

As I was growing up and developing as a person, the Atari ST was providing me with an outlet for my creativity. It poured a constant stream of new game and art influences into me. I managed to find one of my early games a few years back and recorded a video of it, and of course I cringe when looking at it now. When compared to some of the games my own son is making today, they are miles apart in what's possible technically, but that same passion and desire to just create something is still there. Kids these days are no different in that respect.

Lee: The Phaser website is an amazing resource for people learning how to build games. What resources did you have available when you first got into web / game development?

Richard: When I first started coding all I had were books and magazines. Magazines back then were a treasure trove of information, often containing many pages of code to learn from. Tutorials, hardware experiments, and really in-depth technical pieces were common. There were loads of books as well. Of course, the front covers of these books never quite did represent what you'd finally create, but they served the purpose of drawing you in.

Lee: Have you seen the Internet Archive’s Computer Magazine Archives? All of our old favorites are there!

Richard: Let’s just say that accessing these materials is not a problem for me. Photo of my office wall shown below...

Richard Davey's computer magazine collection Richard Davey's computer magazine collection.

Learning web development was very different though. I started out building websites while still at University, when the most common web browser was the fully text-based Lynx, and Netscape Navigator was still in public beta. I remember it being a quite monumental day when we compiled a new build that was capable of displaying jpeg images in-page! I was now learning electronically. Knowledge would come from various sources: from IRC chat rooms, to Usenet postings, to just ripping apart the code in another web page and figuring it out. The difference was stark, though. There was no waiting for a new magazine to be published, or taking a trip to the library. You could nearly always find the answer right there online. This is definitely a change for the better.

Lee: Is there something you wish more people understood about software developers?

Richard: We're humans, just like everyone else. And humans make mistakes. Hindsight is a wonderful thing in life in general, but even more so in software development. Your first pass at solving a problem may not always be the best, but that's the beauty of software: most of the time you can go back and change it for the better. Without wanting to sound like a blatant plug, tools like GitHub have democratized distributed software development, and I honestly couldn't imagine working without them now.

Having said that, it has of course given rise to the 'entitled': those who don't appreciate that we're nearly all doing this for free, in our spare time. And because we're human, we react accordingly if you open a GitHub issue with a particularly negative tone to it. You have every right to point out flaws in my code. And if done with respect, I'll treat your feedback with respect, too.

In short: If you want something done, don't be an ass about it.

Lee: What advice would you give someone just getting into game development?

Don't give up. While there are many more learning materials and resources than ever before, there are also many more distractions, too. If what you're working on just doesn't do it for you, then ditch it and move onto something else. Unless it's a client project, of course :) Keep yourself motivated by working on things that interest you, sharing what you're doing with others, and soliciting their feedback and help when needed.

Also don't be tempted by the grass-is-always-greener mentality. I've seen it time and time again: someone assumes that if they move over to "Tool X" instead, they'll become instantly more productive as a result. This is rarely true. If you're struggling to complete something the issue seldom has anything to do with how it's being built, and nearly always to do with things impacting and pulling on the person trying to make it.

Lee: Hubot tells us the first Phaser code was committed in 2013. What were your initial aspirations for the project? Did you draw on any inspiration or incorporate lessons learned from Flixel or your Flixel Power Tools project?

Richard: Back in 2013 I was stuck in a large, complex project. When you're in deep like this, sometimes you need some small wins to rekindle your love for development. So I literally spent a weekend while the family was away hacking together a crude conversion of Flixel. For those not familiar with Flixel, it was a popular Flash game framework. I literally copied it wholesale, having to rebuild classes that existed in AS3 and porting the others.

A couple of days later I was done. It was small, clean, and just worked because it only tried to do a few things, so it did them pretty well. I wanted to release it on GitHub. I asked Adam Saltsman, the creator of Flixel, if I could call it Flixel5 but he said he'd rather I didn't as it would confuse things with the Flash build. So, I spent an hour brainstorming some names with my good friend Ilija and we settled on Phaser. He drew a cool little spaceman sprite and logo and the first build was pushed to GitHub on April 12th 2013.

Then an interesting thing happened: other people started using it. It started to take on a life of its own. A small-but-constant trickle of devs submitted pull requests and bug fixes. People actually started making games with it. And this does a curious thing when you've been working effectively in isolation for so long: it motivates you like nothing else possibly can.

Phaser was a weekend creation born from a pit of frustration that went mental and grew into what you see today, utterly unplanned, but utterly wonderful because of it.

Now, 3 years on, Phaser has evolved significantly. I believe you can clearly see a lot of my personal game development history and influences within it, and those of the wider HTML5 game developer community too.

Lee: Phaser relies on Pixi.js and Qici Engine relies on Phaser. What are some useful or cool open source projects you use, admire, or couldn't live without?

Richard: I love what Ricardo Cabello (Mr. Doob) is doing with three.js. We recently used three.js in a client project and it was great to work with. I like that he keeps pushing it in whatever direction he feels like, and not following the whims of the wider developer community.

I also admire Stefan Hedman’s work on p2.js, the physics engine that Phaser uses. Although development has dropped off massively on this since he joined Goo, it's still a fantastic library.

As you mentioned Phaser uses Pixi.js, and Mat Groves works tirelessly on improving that. V4 has just landed in beta tools. The rapid rate of iterations, from v1 to v4 in just a few years, is a bit of a challenge if you ever build a library around it :) But, at the same time, where else do you ever get the chance to experiment like this? Mat doesn't just change things for the sake of it. None of us do. We change things because we feel like we're making it measurably better in the process, and I admire him for constantly trying new approaches.

Lee: Talk to us about a subject we know is close to your heart, the future of game development. Where do you see it headed?

Richard: Honestly, I see it carrying on much as it has been for decades. New tools and frameworks will arrive from out of nowhere, and older ones will fade away if they stop being maintained.

For me, 2016 and beyond is all about taking advantage of the significant updates we're seeing in JavaScript. As a language it's really growing up fast. Even just a cursory glance at the new features that have already landed, or are coming soon, is enough to excite any longtime JavaScript developer. It's entirely possible to carry on in the old way, of course, and lots of people will. For me though, I see this as being a fundamental change in the way we'll be coding in the near future, so I am embracing it now rather than later.

The next generation of Phaser, called Lazer, is all about this. I covered the topic in depth in my article 'Phaser in 2015 and beyond'. You can read all about my reasoning, and the approach I'm taking, in that article.

Ever since I saw my first web page load into a text based terminal system all those years ago, the web has never failed to keep on innovating and exciting me. We're on the cusp of WebGL 2, Vulkan, VR in the browser, WebAssembly and loads more exciting tools to play with. Some will become standards, others will be sparks that die away quickly. But being a developer has always been about keeping a careful eye on those sparks, and knowing when to use them to light fires.

The fact that I can keep making tools that empower anyone to create games is what keeps my passion burning. In that respect I feel no different today, than the 10-year-old me who sat staring into the phosphorescent TV display, marveling at what possibilities it could unlock.

GPG signature verification

When you're building software with people from around the world, sometimes it's important to validate that commits and tags are coming from an identified source. Git supports signing commits and tags with GPG, and starting today GitHub will show you when commits and tags are signed.

screenshot 2016-04-04 08 44 43

When you view a signed commit or tag, you will see a badge indicating if the signature could be verified using any of the contributor's GPG keys uploaded to GitHub. You can upload your GPG keys by visiting the keys settings page.

Many open source projects and companies want to be sure that a commit is from a verified source. GPG signature verification on commits and tags makes it easy to see when a commit or tag is signed by a verified key that GitHub knows about.

screenshot 2016-04-04 10 35 33

To learn more about how to generate a GPG key and start signing your work, read our GPG documentation articles.

From the OctoTales video series: advancing cancer research through open source

There are no shortage of open source projects making an impact on our world, and we’ve been especially excited to see an increase in collaboration across the healthcare community. A few months ago we met a team at the Fred Hutchinson Cancer Research Center that is working to break down silos across cancer research by open sourcing their data and a tool called Oncoscape to visualize and interact with it. We thought the best way to introduce you to Oncoscape and the team behind it was through OctoTales, our video series about incredible companies using GitHub to work better together.

Meet Desert, Lisa, Jenny, and Eric, and discover what Oncoscape is all about.

"The project needs help at every level, from simple CSS improvements, to D3 refinements, to new interactive visualizations and extending all the way to novel challenging computational tasks, such as robust implementations of recently published computational biology algorithms", says our friend Paul Shannon, the founding architect of Oncoscape. "Cancer researchers at Fred Hutch and around the world will welcome your contribution!"

If you’re inspired to help the Oncoscape team advance their goals, you can find out more in the project repository. They have detailed contributing guidelines, issues labeled Help Wanted, and even a contributions cheat sheet.

If you would like to be a part of the OctoTales series, tell us your story at

Organizations can now block abusive users

Community is one of the most important aspects of open source, but sometimes a few bad actors can ruin the experience for the group. To help address the problem, organization owners now have the ability to block abusive users from public repositories. This feature allows project owners to block users, and prevents blocked users from opening or commenting on issues or pull requests, forking repositories, and adding or editing wiki pages.

Screenshot of organization settings

All records of blocked activity are available in the organization's audit log for your reference.

Screenshot of organization audit logs

To learn more about encouraging positive contributions in your organization, read our community documentation articles.

Supporting the student hacker community

To stimulate the growth and show our support of the student hacker community, we've partnered with Major League Hacking (MLH) to provide each new member hackathon with a $1,000 grant and one sponsored ticket to Hackcon, the conference for hackathon organizers.

GitHub <3 Students

Hackathons are amazing social gatherings where students interested in technology can come together to learn, build, and share brand new creations over the course of a weekend.

For a small, first-time hackathon, $1,000 can make or break the event budget. For organizers, having the opportunity to meet the people behind the most successful student hackathons at Hackcon is invaluable to the continued success of their events.

As the official student hackathon league, MLH provides member events with organizational support including mentorship, hardware labs, and connections to technology companies. Last week, they announced their seed funding and B-Corp certification to reaffirm their mission-driven focus on empowering student hackers. Together, GitHub and MLH have supported a community of 50,000 students at over 150 global events in the last year.

We're proud to be part of the rapidly growing movement of hackathons organized for students by students. GitHubbers regularly participate in student hackathons as mentors, guest speakers, and judges while the GitHub Student Developer Pack gives student hackers free access to the best developer tools to use for their hacks.

To organize a hackathon at your school with support from GitHub start an MLH member hackathon in the 2016-2017 season.

Squash your commits

Git’s flexibility allows you to shape your workflow however you like. The organization of your git history is just one of the choices to make, but up until now the merge button on GitHub only created merge commits, resulting in a style of history that didn’t necessarily match your own workflow.

Merge commits

For years, the merge button on GitHub has created merge commits (i.e. git merge --no-ff) which retain all of the commits in your branch and interleaves them with commits on the base branch. The result of a merge commit is a visually complex, but more accurate log that depicts how changes from a feature branch came to be on the base branch. Here’s what that looks like today:

Merge commits create accurate, but more complex history

Enter commit squashing

Commit squashing has the benefit of keeping your git history tidy and easier to digest than the alternative created by merge commits. While merge commits retain commits like “oops missed a spot” and “maybe fix that test? [round 2]”, squashing retains the changes but omits the individual commits from history. Many people prefer this workflow because, while those work-in-progress commits are helpful when working on a feature branch, they aren’t necessarily important to retain when looking at the history of your base branch. Here’s what squashing on merge looks like:

What’s changing?

Repository administrators now have a few options to choose from when deciding how to handle history.

New merge button settings

Allow merge commits and commit squashing

This option will leave the decision to create a merge commit or squash up to the user doing the merging. This lets repository administrators stay flexible when deciding whether or not to retain all history from a feature branch.

Only allow merge commits

This is the default behavior and is exactly how the merge button worked before this change. Collaborators won’t have the option to squash their commits via the merge button.

Only allow squash commits

This is a new option which lets you force commit squashing on all pull requests merged via the merge button.

Squash and merge

Check out the documentation or get in touch with any questions or feedback. Enjoy!

Something went wrong with that request. Please try again.