Contents hide

The GitHub Blog

Updates, ideas, and inspiration from GitHub to help developers build and design software.

Bring your project to life during Local Hack Day 8 Nov 2019, 5:00 pm

It’s time for Major League Hacking’s (MLH) annual Local Hack Day: Build. Do you have a great idea that you want to bring to life? Or have you always wanted to participate in a hackathon? This is your chance to join us for a global hack day between December 1-8 to learn, build, and spark your interest in technology. With over 120 locations around the world, there’s no better time for you to gather with your local tech community or join a new one.

What’s Local Hack Day: Build?

For 12 hours, you can dive into all the tools and magic that technology brings—a time where you can bring ideas to life. It doesn’t matter if you’re new to coding, or if you’re an experienced developer: this hack day is for everyone.

Besides lots of GitHub swag, everyone who attends a Local Hack Day gets free access to the GitHub Education Pack. The Pack now offers over $100k worth of tools and training to every student developer, anywhere that GitHub is available.

What will I learn?

You can attend workshops on how to collaborate on code projects with GitHub, or how to build a node.js app with Azure, and learn skills that you can apply to your school projects, internships, career, and beyond. And GitHub Campus Experts will be at a few of the locations to help mentor.

We’re proud to support Local Hack Day for the fourth time in a row, and we can’t wait to see you there. Spread the word about Local Hack Day by using the hashtag #LocalHackDay on Twitter and don’t forget to mention us @GitHubEducation so we can follow along.

Happy hacking!

Join a Local Hack Day near you

The post Bring your project to life during Local Hack Day appeared first on The GitHub Blog.

A thousand community-powered workflows using GitHub Actions 6 Nov 2019, 9:00 pm

We recently celebrated an exciting milestone on the GitHub Actions team: 1,000 actions published to GitHub Marketplace.

If you haven’t browsed it yet, GitHub Marketplace is the home for shared actions that you can use to enhance your GitHub Actions workflows. Authors publish these actions to the marketplace to help you create more powerful workflows, whether you’re building an application, deploying it to a public cloud, or automating common tasks in your repository.

A few highlights

GitHub Actions is more than just a continuous integration build system. It also allows you to run workflows when changes occur in your GitHub repository. Here are some of our favorite actions that take advantage of this diversity—one for working with issues in your repository, one for working with deployments, and one for working with the code in pull requests.

Setup JFrog CLI

Continuous integration builds often need more than just your source code. You might need a particular piece of software installed on the build environment in order to run the build. Or you might build inside a container that’s pre-configured with all of your dependencies. The easiest way to manage these dependencies is with a package registry.

The Setup JFrog CLI action makes it easy to set up and use Artifactory as your package registry. It handles the setup of the CLI in your build environment and helps you configure authentication. All you have to do is set up the action, then you can jfrog rt download your artifacts and use them in your build.

Close Stale Issues

In a busy repository, it’s easy to get overwhelmed by the number of issues and pull requests, especially when issues go stale. Even with our best efforts, it’s hard to keep track after a certain point,  but closing out issues that don’t matter can help us focus on higher-priority or urgent requests and problems.

The Close Stale Issues action filters issues and pull requests that haven’t had any activity or comments for a few weeks. This action informs you when an issue is stale and—unless any new activity occurs—will close the issue or pull request a week later. This helps keep you informed about any issue that needs your attention, but you may have forgotten about. And it helps reduce the cognitive load of stale issues without any extra effort on your part.


You may have heard that you only have a few seconds to make a good first impression. So don’t waste any of that time with unoptimized images—make sure your website loads quickly.

Thankfully, the image-actions from Calibre take care of optimization for you. Every time a pull request is opened, this action will search your repository for images that are large and unoptimized. Once it finds any images, the action uses lossless compression libraries to shrink the images down to a more manageable size. It’s an easy way to get more performance out of your website delivery—all with a simple action.

Want more actions to help you manage your repository, build your application, or deploy it to production? 

Get more actions from GitHub Marketplace

The post A thousand community-powered workflows using GitHub Actions appeared first on The GitHub Blog.

The State of the Octoverse 2019 6 Nov 2019, 5:00 pm

It’s that time of year again, when we ask ourselves, “What can 40 million developers do in 365 days?” Today we published our annual Octoverse report, showing that the world’s software is built by a global community, one that’s growing, evolving, and increasingly interconnected. This year, we’ve seen that the way developers work together can change fast. We’ve also seen that software development is, increasingly, a community endeavor as it becomes easier to find and build on work from others around the world. And some of the top open source projects not only have thousands of contributors—they’re dependencies for millions of repositories.

To celebrate 365 days of achievements, let’s look back at the code and communities built on GitHub this year.

Dive into the full report—or read on for the highlights.

40M+ people are building together on GitHub, worldwide

By all metrics, more people are working together from more places than ever. There are over 40 million developers building on GitHub, most of whom (80%) come from outside of the United States. Ten million new developers joined in the last year alone, 44% more created their first repository in 2019 than 2018, and 1.3 million made their very first contribution to open source. We even saw contributions from new places, like Antarctica.

Organizations are collaborating across time zones and relying on open source software

Almost three million organization accounts are now on GitHub. Created from all over the world, these represent the collective work of companies, nonprofits, open source projects, and more. Digging in, we can see that GitHub Enterprise Cloud accounts alone came from more than 70 different countries. And 35 of the Global Fortune 50 contributed to open source this year—a glimpse into how deeply proprietary code depends on the open source source community.

The software community is more deeply connected than ever

More than 44 million repositories were created in the last year. And from machine learning in medicine and academic papers on deep learning to robots of all shapes and sizes, we’ve seen some exciting new work open sourced in just 12 months. We’ve also seen that a shared infrastructure of open source projects ties all software together and that nowhere are we more connected than in our dependency graphs.

On average, each public and private repository on GitHub depends on more than 200 packages. With hundreds of dependencies behind every project, our code is more connected than ever. And if we look at the top 50 open source projects by number of dependent repositories, we can also see that the most depended-upon projects supported more than 3.6 million other repositories this year. Projects like rails/rails, facebook/jest, and axios/axios have become critical to code around the world.

7.6M+ vulnerability alerts remediated by maintainers, developers, researchers, and more

Much like software, security is a community effort: when a potential vulnerability is found, maintainers, developers, researchers, and an ecosystem of tools all work together to keep everyone’s code safe. Since we launched security alerts in November 2017, this community has remediated more than seven million alerts.

And since Dependabot joined GitHub in May 2019, more than 209,000 pull requests were merged with automated updates, adding to more than one million pull requests merged since the app launched in April 2017.

And more

These highlights show just how much the GitHub community is growing, but our data tells millions of stories, not that we’re counting. Here are some of our favorites:

  • Python passed Java as the second-most popular language on GitHub by repository contributors.
  • Dart and Rust topped our list of fastest growing languages by repository contributors.
  • The use of Jupyter Notebooks (by number of repositories with Jupyter as their primary language) has seen more than 100% growth year-over-year for the last three years.
  • When counting contributors to its dependencies, TensorFlow’s contributors grow from 2,238 to a global community of 25,166 people.

Are you as excited about data as we are? Join me at GitHub Universe for a fireside chat with Rachel Potvin, VP of Engineering for Data at GitHub, and Stephen O’Grady, Principal Analyst and Co-founder of RedMonk, where we’ll take a deep dive on the findings in this year’s report. The livestream starts at 2:10 pm PT on November 13. Make sure to tune in at

The post The State of the Octoverse 2019 appeared first on The GitHub Blog.

Self-hosted runners for GitHub Actions is now in beta 5 Nov 2019, 9:00 pm

Since we announced GitHub Actions support for CI/CD In August, self-hosted runners have been one of the most eagerly anticipated updates—and it’s now available in beta.

Advantages of self-hosted runners

Self-hosted runners offer a number of advantages when the hosted virtual environments don’t meet all your needs:

  • Your environment, your tools: Your workflow may require software that’s proprietary, expensive, or difficult to install on virtual environments. Or maybe you need more flexibility with platforms like a different Linux distribution or architecture. Self-hosted runners allow you to create the perfect environment for your workflow. See the product documentation for details on supported platforms and architectures.
  • Any size machine or configuration: Self-hosted runners allow you to use the specific hardware you need, whether that’s more memory or cores, or different configurations like GPUs or ARM-based CPUs. 
  • Secure access and networking: We received feedback that securely networking to and from hosted virtual environments can be challenging. Self-hosted runners make this easier by allowing you to more easily enable access to firewalled on-premises resources or RDP into the environment that’s running your job.
  • Large workload support: In some cases, your jobs benefit from using techniques like incremental source fetches, package caches, or other configurations that require persistence. Self-hosted runners give you the opportunity to persist whatever you like for your jobs and not be subject to the six-hour time-out in hosted virtual environments.

Downloading and configuring the runner

To get started, you must be an administrator to change any configurations. Once logged in, navigate to the Actions tab from your repository’s settings. You should see a new section where you can manage your self-hosted runners.

Click the Add runner button, select the platform you’re targeting, and then follow the sequence of shell commands to download, configure, and run your runner.

During configuration, the CLI will prompt you to answer a few questions, including naming the runner, and determining the output directory for any jobs.

Once your runner is successfully configured and listening for jobs, it will display as idle which means you’re ready to update your workflow.

Using the runner

To support using self-hosted runners in your workflows, we’ve expanded the experience of using the runs-on key. When registering your self-hosted runners, they’re each given a read-only label self-hosted which you can use with runs-on. Here’s an example:

# Use Any available Self-hosted runners connected to repo
runs-on: self-hosted

In addition to the self-hosted label, each runner is also given read-only labels that identify its platform and architecture.

    • Platforms: windows, linux, macos
    • Architectures: x64 is available today. ARM64, ARM32, and x86 will be available shortly after Actions GA

Since self-hosted runners have more than one label, you can provide a single label, or array of labels to runs-on. These allow you to filter the runners to only those that include the specific label values you specify. Here’s an example where we filter labels:

# Use an ARM32 linux based self-hosted runner
runs-on: [self-hosted, linux, ARM32]

# Use only macos based based self-hosted runners
runs-on: [self-hosted, macos]

Adding your own custom labels to self-hosted runners is currently not supported, but we hope to release it in a future iteration.

Get started today

We know that flexibility and control are critical when it comes to your CI/CD setup, so we’re excited to add self-hosted runners as a new way to use GitHub Actions. You can start adding your own self-hosted runners through the Actions tab in your repository’s setting page, and we look forward to hearing what other features you need!

Learn more about self-hosted runners for GitHub Actions

The post Self-hosted runners for GitHub Actions is now in beta appeared first on The GitHub Blog.

Internal repositories are now generally available for GitHub Enterprise 5 Nov 2019, 5:00 pm

After the public beta announcement at GitHub Satellite, we’ve continued adding to the internal repository visibility and it’s now generally available as of October 28. We’d like to thank all of the beta participants for their engagement and feedback during this beta period. Your input played a critical role in creating this feature and the direction that brought the product to where it is today.

The role of customer feedback

We received over 100 unique enterprise customer requests and countless more individual developer reports, all enthusiastic about bringing the innersource methodology to their businesses. The internal repository visibility allows an enterprise-owned repository to be read by any member of any organization that belongs to an enterprise account. 

We wanted our customers to have this feature quickly, but we knew we had some work to do after launch. Some of the feedback we received during the beta was expected, like requests for API support and more specific search capabilities. What we didn’t expect was that many users, including some internal to GitHub, thought that these repositories were internal to a specific GitHub organization. Here’s why we think that happened:

  • Limited in-product guidance from GitHub at launch
  • Strong association to organizations being the top-level owner of repositories
  • Enterprise accounts were brand new and many users didn’t know how they became an “enterprise member”

We made a few precise changes to internal repositories to help our users.

What we changed during the beta

  • Updated repository creation dialog and new enterprise policy settings [details]
  • New documentation describing the role of “enterprise member” [details]
  • New search filters that isolate internal repositories
  • Updated organization and repository API endpoints that include “internal” types
  • Forking policy was updated to reflect the same behavior that would apply to a private repository [details]

The first and second changes were almost entirely responses to customer feedback, which we’ll cover in the following sections.

Repository creation design

At launch, we needed to provide an interface that allows you to create an internal repository and understand the core differences from internal, public, or private options. Let’s take a look at the interface before and after we made a few updates.

In the new repository dialog at launch, “GitHub” is both the name of an enterprise account and organization. We’re telling the user that all members of the GitHub account can see this repository. Since we can’t see what kind of entity “GitHub” is, it wasn’t clear who could see the repository. This led users to believe that the visibility was organization-wide instead of across the enterprise account. For clarity, we added the enterprise account’s avatar to the dialog and changed the text to state that “enterprise members” of the enterprise account will be able to see this organization-owned repository. This removes ambiguity between the organization and enterprise account names.

Who is an enterprise member?

During the beta, one of the most interesting things we learned is that the members of organizations belonging to an enterprise account didn’t really notice that they were members of an enterprise account rather than a collection of GitHub organizations. While this was not disruptive to the user’s regular behavior, it was a primary cause of confusion around who could (or should) be able to see an internal repository. To address this, a distinct role description for enterprise members was added that we link directly in the new repository creation dialog.

Thank you for your feedback

Without valuable input from our users, we wouldn’t have been able to create this feature or improve the user experience. We can’t express our thanks enough and hope you’ll continue collaborating with us. Ready to give us more feedback? Share your comments with us. Be sure to select “Teams, organizations, or Enterprise accounts” where our product team will be watching for items related to internal repositories.

Upcoming changes to GitHub Enterprise Server

With the upcoming release of GHES 2.20, we’re adding the internal repository visibility to our on-premises offering and creating a uniform experience for both Cloud and Server platforms. Stay tuned for more updates as we continually improve your experience.

Learn more about internal repositories

The post Internal repositories are now generally available for GitHub Enterprise appeared first on The GitHub Blog.

GitHub Sponsors is now out of beta in 30 countries 4 Nov 2019, 6:45 pm

GitHub Sponsors is now out of beta and generally available to developers with bank accounts in 30 countries and growing.

Since GitHub Sponsors launched, the beta has grown exponentially, reaching tens of thousands of developers in the GitHub community. It’s been amazing to see what open source developers have already done with sponsorships in just a few months. 

Developers ❤GitHub Sponsors

Hear just a few of the talented developers who participated in the beta describe what GitHub Sponsors means to them:

Our small team was busy this summer. We’ve spoken to hundreds of open source developers and sponsors, merged hundreds of pull requests, and added many of the key features that our patient beta users requested—and there’s still so much more to do! 

Next steps

This is just the beginning for native sponsorships on GitHub. We’re working hard to build out great sponsorship experiences around the world.

If you don’t have a bank account in one of the 30 countries where GitHub Sponsors is generally available, you can still sign up on the waitlist to join the beta in your country. You’ll also receive news about when GitHub Sponsors is generally available.

In the coming months, we’ll continue to roll out general availability to countries where GitHub does business, incorporate feedback, and improve the tools you need to connect with the community you depend on and collaborate with.

Learn more about GitHub Sponsors

The post GitHub Sponsors is now out of beta in 30 countries appeared first on The GitHub Blog.

Highlights from Git 2.24 4 Nov 2019, 3:55 am

The open source Git project just released Git 2.24 with features and bug fixes from over 78 contributors, 21 of them new. Here’s our look at some of the most exciting features and changes introduced since Git 2.23.

Feature macros

Since the very early days, Git has shipped with a configuration subsystem that lets you configure different global or repository-specific settings. For example, the first time you wrote a commit on a new machine, you might have been reminded to set your and settings[1] if you haven’t already.

It turns out, git config is used for many things ranging anywhere from the identity you commit with and what line endings to use all the way to configuring aliases to other Git commands and what algorithm is chosen to produce diffs.

Usually, configuring some behavior requires only a single configuration change, like enabling or disabling any of the aforementioned values. But what about when it doesn’t? What do you do when you don’t know which configuration values to change? For example, let’s say you want to live on the bleeding-edge of the latest from upstream Git, but don’t have a chance to discover all the new configurable options. In Git 2.24, you can now opt into feature macros—one Git configuration that implies many others. These are hand-selected by the developers of Git, and they let you opt into a certain feature or adopt a handful of settings based on the characteristics of your repository.

For example, let’s pretend that you have a particularly large repository, and you’re noticing some slow-downs. With enough searching, you might find that setting index.version to 4 could help, but discovering this can seem like a stretch. Instead, you can enable feature.manyFiles with:

$ git config feature.manyFiles true

Now you’re opted into the features that will make your experience with Git the smoothest it can be. Setting this signals to Git that you’re willing to adopt whichever settings Git developers feel can make your experience smoothest (right now, this means that the index.version and core.untrackedCache to enable path-prefix compression and the untracked cache, respectively). Not only that, but you can feel even better knowing that any new features in a release that might help your use case will be included in the macro.


Commit graphs by default

You may remember commit graphs, a feature that we have discussed in some of our previous highlights.  Since its introduction in Git 2.19, this feature has received a steady stream of attention. When enabled, and kept reasonably up to date, commit graphs can represent an order of magnitude improvement in the performance of loading commits.

Now in Git 2.24, commit graphs are enabled by default, meaning that your repository will see an improvement the next time you run git gc. Previously, this feature was an opt-in behind an experimental core.commitGraph configuration (as well as a handful of others), but after extensive testing[2], it’s ready for prime time.

Besides being the new standard, here are a few other changes to commit graphs:

  • All commit-graph sub-commands (e.g., git commit-graph write, git commit-graph verify, and so on) now have support for the -[no-]progress. Now the progress meters for these commands behave in the usual way: writing only to a terminal by default, and respecting -[no-]progress to override that.
  • A new configuration value to automatically update the commit-graph file while fetching has been introduced, which takes advantage of commit graph chains to write a portion of history onto a commit-graph chain for later compaction. This means that every time you get new commits from a remote, they are guaranteed to be in a commit-graph immediately, and you don’t have to wait around for the next auto-gc. To try this out today, set the fetch.writeCommitGraph configuration variable to true.
  • Lots of bug fixes to improve the performance and reliability of the commit-graph commands, especially when faced with corrupt repositories.
  • The commit-graph commands now also support Git’s latest tracing mechanism, trace2.

[source, source, source, source, source, source, source]

Adopting the Contributor Covenant

Since the last release, the Git project has discussed at length adopting a code of conduct to solidify welcoming and inclusive behavior on the mailing list where Git development takes place.

Because communication between Git developers happens over email, it can be intimidating or unwelcoming to new contributors who may not be familiar with the values of the people contributing to Git. The Git community has long relied on a policy of “be nice, as much as possible” (to quote this thread). This approach is in the right spirit, but it may not be readily apparent to new contributors unfamiliar with the existing culture. Likewise, it can make an individual feel uncomfortable engaging with a project that has not solidified its values.

By adopting a code of conduct, the Git project is making it clear which behaviors it encourages and which it won’t tolerate. New contributors are able to see explicitly what the project’s values are, and they can put their trust in Git’s choice of using the well-trusted and widely-adopted Contributor Covenant. This code of conduct is enforced by the project’s leadership, who will handle any case in which an individual does not adhere to the guidelines.

New contributors can be assured that the Git community is behind this adoption with the introduction of the Code of Conduct, Acked-by 16 prominent members of the Git community.


Alternative history rewriting tools

If you’ve ever wanted to perform a complicated operation over the history of your repository—like expunging a file from a repository’s history or extracting the history pertaining to just one directory—you may have visited the documentation for git filter-branch.

git filter-branch is a long-standing and powerful tool for rewriting history[3]. With git filter-branch, you can do all of those aforementioned operations and much more. However, this flexibility comes at a hefty cost: git filter-branch is notoriously complicated to use (not to mention slow), and can often lead its users towards unintended changes, including repository corruption and data loss.

In other words, git filter-branch is starting to show its age. Now, as of Git 2.24, the Git project instead recommends a new, independent tool, git filter-repo.

git filter-repo serves to avoid many of the pitfalls that users experienced with git filter-branch. Instead of reprocessing every commit in order, git filter-repo operates on an efficient, stream representation of history to run much faster. The tool is extremely powerful, and all of its capabilities are documented thoroughly. Here are a few highlights about how you can use git filter-repo:

  • git filter-repo --analyze provides a human-readable selection of metrics profiling the size of your repository. This includes how many objects of each kind there are, which files and directories are largest, which extensions take up the most space, and so on. And this isn’t your only option in this space. For additional metrics on the shape of your repository, check out another tool, git sizer.
  • You can also filter the history of your repository to contain only certain paths, with --path-{glob,regex} and similar options. [source]
  • Likewise, you can run a “find and replace” operation over history, as well as strip blobs that are larger than a fixed threshold. [source]
  • When rewriting history, any rewritten commits (along with their ancestors) will get a new SHA-1 to identify them. By default, git filter-repo updates all other references to these SHA-1s, like other commit messages that reference them. By a similar token, git filter-repo also has options to rewrite the names of contributors using .mailmap. [source, source]
  • Finally, git filter-repo is extensible. It provides a flexible interface for specifying callbacks in Python (e.g., calling a function when git filter-repo encounters a blob/tree/commit, new filetype, etc.), as well as defining new sub-commands entirely. View a portfolio of demo extensions, or define your own to support a complex history rewrite. [source]

git filter-branch will, however, remain included in the usual distributions of Git for some time. git filter-repo is another alternative for performing complex modifications to your repository’s history, and it’s now the official recommendation from upstream.



You might be aware that many Git commands take one or more optional reference names as arguments. For example, git log without arguments will display a log of everything that’s reachable from the currently checked-out branch, but git log my-feature ^master will show you only what’s on my-feature and not on master.

But what if your branch is called --super-dangerous-option, you probably don’t want to invoke git log since it’ll interpret the argument as an option, not a branch name. You could try and disambiguate by invoking git log 'refs/heads/--super-dangerous-option', but if you’re scripting, you may not know under what namespace the argument you’re getting belongs.

Git 2.24 has a new way to prevent this sort of option injection attack using --end-of-options. When Git sees this as an argument to any command, it knows to treat the remaining arguments as such, and won’t interpret them as more options.

So, instead of the string previously mentioned, you could write the following to get the history of your (admittedly, pretty oddly named) branch:

$ git log --end-of-options --super-dangerous-option

Not using the standard -- was an intentional choice here, since this is already a widely-used mechanism in Git to separate reference names from files. In this example, you could have also written git log --end-of-options --super-dangerous-option ^master -- path/to/file to get only the history over that range which modified that specific file.


In a previous post, we talked about git rebase‘s new --rebase-merges option, which allows users to perform rebases while preserving the structure of history. But when Git encounters a merge point how does it unify the two histories? By default, it uses a strategy known internally as “recursive”, which is most likely the merge strategy you’re currently using.

You might not know that you can tell Git which merge strategy to use, and picking one over the other may result in a different resolution[4].

Now, git rebase --rebase-merges supports the --strategy and --strategy-option options of git rebase, so you can rebase history while both preserving its structural integrity and specifying your own merge resolution strategy.


Git supports a number of hooks, which are specially-named executable files that Git will run at various points during your workflow. For example, a pre-push hook is invoked after running git push but before the push actually occurs and so on.

A new hook has been added to allow callers to interact with Git after a merge has been carried out, but before the resulting commit is written. To intercept this point, callers can place an executable file of their choice in .git/hooks/pre-merge-commit.


Git has learned a handful of new tricks since the last release to handle partial clones. For those who aren’t up to date on what partial cloning in Git looks like, here’s a quick primer. When cloning a repository, users can specify that they would only like some of its objects by using a filter. When doing so, the remote from which the user clones is designated as a “promisor,” meaning that it promises to send the remaining objects later on if the user requests them down the road.

Up until 2.24, Git only supported a single promisor remote, but this latest release now supports more than one promisor remote. This is especially interesting since it means that users can configure a handful of geographically “close” remotes, and not all of those remotes have to have all of the objects.

There’s more work planned in this area, so stay tuned for more updates on this feature in the future.


Last but not least, Git’s command-line completion engine has learned how to complete configuration variables on per-command configurations.

Git has a hierarchy of places where gitconfig files can be found: your repository (via .git/config), your home directory, and so on. But, Git also supports the top-level -c flag to specify configuration variables for each command. Here’s an example:

$ git -c core.autocrlf=false add path/to/my/file

This invocation will disable Git’s auto-CRLF conversion just for the duration of the git add (and any other internal commands that Git may run as a part of git add).

However, if you forgot the name of the variable that you were trying to set Git’s command-line completion engine learned how to provide a completion list of configuration variable names in Git 2.24. So, if you ever forget where you are in the middle of a -c ..., all you need to do is press tab.


[1] When you create a commit, these are the configuration values that Git is looking at to generate the signature; Git-parlance for the name/email-pair that is shown wherever an identity is expected.

[2] Including at GitHub, where we’ve used the commit-graph file behind the scenes since August to achieve speed-ups of over 50 percent on operations which traverse history.

[3] In fact, this tool appeared in git/git with 6f6826c52b which was first released in v1.5.3 over 12 years ago.

[4] For example, the patience merge strategy is widely regarded as one that will “move up” chunks of your diff (these are usually known as “hunks”) that look textually related (for example, closing function braces), but in fact produce awkward-looking diffs.

Learn more

That’s just a sample of changes from the latest version. Check out the release notes for 2.24 or any previous versions in the Git repository.

The post Highlights from Git 2.24 appeared first on The GitHub Blog.

Game Off 2019 theme announcement 1 Nov 2019, 8:36 pm

Game Off  is our annual month-long game jam (hackathon for building games). This year’s theme is LEAPS AND BOUNDS.

You’re welcome to interpret the theme however you wish, but if you need some ideas to kickstart your creativity, maybe your game could:

  • Make your character evolve to overcome challenges
  • Add obstacles to test your hero’s ability to leap into action
  • Deduct points for anything going out of bounds
  • Duck, dip, dive, and dodge an enemy that’s changing or moving rapidly
  • Take place in the year 2020, the next leap year

Maybe the year 2020 will lead you to think about hindsight being 20/20, and that’ll inspire even more ideas around time travel, decision-making, or something else. Let your imagination run wild and create a game loosely-based or inspired by that theme using whatever game engines, libraries or languages you prefer before December 1st, 13:37 PT. Work alone or as a team. Most importantly, have fun!

Join Game Off now

How to participate

  • Sign up for a free GitHub account if you don’t already have one.
  • Join the Game Off on If you don’t already have an account, log in with your GitHub account.
  • Create a game based on the theme over the next month. You have from November 1, 13:37 PT to December 1, 13:37 PT.
  • Create a new public GitHub repository to store the source code and any assets you’re able to share for your entry. Then push your changes before December 1, 13:37 PT.
  • Submit your game through the Game Off page on The form will be viewable once the jam starts and you’ve joined.


Shortly after the jam ends, voting will be open to everyone who has submitted a game. Don’t worry—there will be plenty of time to play and vote on the entries. As always, we’ll highlight some of our favorites on the GitHub Blog, and the world will get to enjoy (and maybe even contribute to or learn from) your creations.


Octocat pixel art animation

It’s dangerous to go alone

If you’re new to Git, GitHub, or version control

Never fear, we have several resources for you, from how to use Git to all things GitHub. You’ll “Git” it in no time.

Did you know? You don’t have to use Git on the command line. There’s a Desktop client for Windows and macOS, A GitHub extension for Visual Studio, a GitHub for Unity plugin, and a client for Atom!

If you’re new to or game development

The community feature is enabled for this jam—it’s a great place to share tips, ask Game Off and game development questions, and more.

With so many tutorials, open source game engines, and the source for thousands of other game jam games available online, there’s never been an easier (or more exciting) time to jump into game development.

Are you:

The official Twitter hashtag for the Game Off is #GitHubGameOff. We can’t wait to see what you build. GLHF!

The post Game Off 2019 theme announcement appeared first on The GitHub Blog.

Get over $100k worth of tools with the GitHub Student Developer Pack 30 Oct 2019, 4:00 pm

The GitHub Student Developer Pack now offers over $100k worth of tools and training to every student developer, anywhere that GitHub is available. If you’re new to the Pack, it provides verified students with GitHub Pro at no charge while they are in school, plus free access to the best developer tools and training—thanks to our partners—so they can learn by doing. 

As the Pack continues to grow and shape the next generation of developers, we continue to listen. We’re here to better understand how you’re using these tools and what’s missing that you hope to see included. Whether you’re developing your portfolio, building a new desktop app, or creating an interactive map—the goal of the Pack is to provide you with the tools you need to be successful.

This year, the value of the Pack tripled during the Fall semester by adding nineteen new partners in October plus a dozen in September to the twenty-one who joined our long-time partners for Back-to-School. Let’s highlight the partners who joined us since our last post in August.

A few words from our new partners

We ask all of our new partners what motivated them to join the Pack. Here’s a sample of what they’ve told us:

When I was a student, I actually used the GitHub Student Developer Pack myself! It allowed me to test and learn how to use tools that I wouldn’t have been able to otherwise. The Pack was a great help!” -Floran Pagliai, Weglot

“The way that developers learn best is by getting their hands dirty, trying different things, and experimenting with a variety of tools. The Pack allows developers to do that and get exposure creating awesome projects outside the confines of the classroom.” -Naeem ul Haq, Educative

“Not many high school and even college students would ordinarily be able to afford [our tool.] Letting students try it will give us valuable feedback about what up-and-coming developers are looking for.” -Levie Rufenacht, Wisej

“The Pack opens new doors to students that were not accessible before. It basically gives them what’s needed to build a project from A to Z, lets them cultivate their curiosity, an essential quality for a developer, and free their creativity. Learning should know no boundaries.” -Julien Lehuraux, USE Together

Partner details

The following are our new partners and the tools and training they are providing, for free, to students:


  • Appfigures, app store analytics, optimization, and intelligence
  • Astra Security, security suite for your website, including firewall, malware scanner, and a managed bug bounty platform
  • BoltFlare, reliable, secure, and scalable managed WordPress hosting
  • BrowserStack, test your web apps, providing instant access to 2,000+ browsers and real iOS and Android devices
  • Codecov, implement code coverage easier to develop healthier code
  • Educative, level up on trending coding skills at your own pace with interactive, text-based courses
  • EverSQL, boost your database performance by automatically optimizing your SQL queries
  • HazeOver, get focused while working on projects or studying
  • Iconscout, design resources marketplace with high quality icons, illustrations, and stock images
  • Interview Cake, makes coding interviews a piece of cake with practice questions, data structures and algorithms reference pages, cheat sheets, and more
  • Kaltura, build interactive video experiences and advanced media applications
  •, managed Cloud hosting for developers
  • NetLicensing, cost-effective and integrated Licensing-as-a-Service (LaaS) solution for your software on any platform from Desktop to IoT and SaaS
  • Scrapinghub, battle-tested cloud platform for running web crawlers where you can manage and automate your web spiders at scale
  • Testmail, unlimited email addresses and mailboxes for automating email tests with powerful APIs
  • Typeform, interactive forms, surveys, and quizzes to engage and grow your audience
  • USE-Together, provides a remote pair programming and team collaboration tool
  • Weglot, make any website multilingual and manage your translations through a single platform
  • Wisej, build powerful web applications in Visual Studio with C# or VB.NET


  • Blackfire, Code performance measurement tool where you can find and fix bottlenecks
  • Canva, create professional looking graphics and designs, featuring thousands of templates and an easy to use editor
  • Covalence, provides an exclusive developer community and allows you to learn Full Stack web-development with no long-term commitments
  • Crowdin, cloud-based solution that streamlines localization management
  • Education Host, web hosting platform to host assignment and project work
  • GoRails, tutorials for web developers learning Ruby, Rails, Javascript, Turbolinks, Stimulus.js, Vue.js, and more
  • Honeybadger, exception, uptime, and cron monitoring
  • Mailgun, APIs that enable you to send, receive, and track email
  • One Month, learn HTML, CSS, JavaScript and Python in just 30 days
  •, an online IDE that lets you instantly code in over fifty languages so you can start learning, building, collaborating, and hosting all in one place
  • Storyscript, top-level, cloud native programming language that helps you orchestrate data flow seamlessly between microservices
  • Vaadin, open source Java framework for building Progressive Web Applications

What can I do with the Pack?

Looking for ideas for how to use all the new tools? Take a look at these projects or check out GitHub Education’s Twitter and Facebook for suggestions.

Make a request

Have a tool you’d like to see included in the Pack? Let the developer know (and tag us) on social media using the hashtag #GitHubPack. Companies interested in including an offer in the Pack can apply to be a partner.

Get the Pack

Not yet a member of the Pack? It’s available for all verified students ages 13+, anywhere in the world where GitHub is available. Join today using your school-issued email, student ID, or other proof of current academic enrollment.

Explore the latest offers in the GitHub Student Developer Pack

The post Get over $100k worth of tools with the GitHub Student Developer Pack appeared first on The GitHub Blog.

Thirteen spooktacular games to play, hack, and slash this Halloween 30 Oct 2019, 1:00 pm

With Halloween creeping up (and Game Off just days away), we thought you might enjoy some fun, fiendish, and forkable games that have risen from game jams over the years. For the undead uninitiated, game jams are hackathons for building games in just a few days or weeks based on a theme or some other constraint like limitations to CGA color palettes, total filesize no more than 13kB, or fitting an entire game into a 64×64 pixel canvas. They’re fun, challenging, and we’ve seen some spooktacular creations!

We’re covering 13 games with ghosts, ghouls, demons, daemons, witches, worms, and a myriad of monsters from jams like CGAJam, Global Game Jam, JS13K, LowResJam, and Ludum Dare. Play them alone in the dark, or fork them and make some tweaks to the source to give yourself an advantage. We’ve provided a few cheat codes to get you started. 🎃

The Wandering Wraith (JS13K, 2019)

The Wandering Wraith

► Play in your browser · Source (JavaScript)
Game theme: Back · By @tulustul

A lost wraith is wandering through the world seeking peace. Will you guide him back to his grave so he can finally rest?

Fun hack: Give yourself infinite dash-jumping abilities and get to those hard-to-reach places with ease by commenting out this.dashed = true; in player-physics.ts L#285:

   this.player.body_.vel.y = 5 * (this.gravity > 0 ? -1 : 1);
-  this.dashed = true;
+  // this.dashed = true;
   zzfx(0.6, 1, 200, 0.1, 0.47, 4.2, 1.4, 1, 0.15);

Trick Parade (Ludum Dare 33, 2015)

Trick Parade

► Play on Win, macOS, or Linux · Source (Lua)
Game theme:
You are the monster · By @SimonLarsen

Trick Parade is an RPG with a twist—through a combination of menu-based combat and mini-game mayhem, you’ll quest to become a master of tricks and scares.

Daemon vs. Demon (Game Off, 2017)

Demon vs. Daemon► Play on Win, macOS, or Linux · Source (Godot, GDScript)
Game theme: Throwback · By @securas and @mundus

Winner of 2017’s Game Off, Daemon vs. Demon challenges our hero to fight their way back to the land of the living using the W A S D keys to move and the J K keys to hack and slash.

Fun hack: Having problems getting through those tentacled felines? Limit their ability to grab you by updating GRAB_PLAYER_TIMEto a higher value in scripts/

  var steering_control = preload( "res://scripts/" ).new()
- var GRAB_PLAYER_TIME = 0.5
+ var GRAB_PLAYER_TIME = 1337
  var grab_player_timer = GRAB_PLAYER_TIME

Murder at the Residence Gudul (Global Game Jam, 2015)

Murder at the Residence Gudul

► Play in your browser · Source (Superpowers, JavaScript)
Game theme:
What do we do now · By a team of ten people

With the theme “What do we do now?”, we were almost guaranteed some classic point-and-click adventure games. This one didn’t disappoint.

Mogee (LowRezJam, 2016)


► Play in your browser · Source (Elm)
By @w0rm, @kuzminadya, and @carlospazuzu

Built in just three days and 64×64 pixels, this pixelated platformer and infinite runner poses quite a challenge. 

Fun hack: Give yourself a speed boost with a tweak to Mogee.elm lines 20-27 by doubling the jump and walk velocities:

jumpVelocity : Float
jumpVelocity =
-   0.09
+   0.18

walkVelocity : Float
walkVelocity =
-   0.045
+   0.09

Monster Pong (Game Off, 2018)

► Play in your browser · Source (JavaScript)
Game theme:
hybrid · By @michelebucelli and Andrea Di Primio

2017’s Game Off inspired a hybrid of Breakout and Pong that can get monstrously difficult.

Fun hack: If it’s too challenging to defeat the computer, hack the AI! Removing the following from script.js lines 707-710 will force your opponent to make some monstrously inefficient decisions when it comes to which balls to intercept, giving you the advantage.

// Checks if there are balls attached and finds the nearest incoming ball
for ( var i = 0; i < this.balls.length; ++i ) {
-   if ( this.balls[i].v[1] < 0 && this.balls[i].x[1] < nearestIncomingBall.x[1] )
-      nearestIncomingBall = this.balls[i];
-   if ( this.balls[i].x[1] < nearestBall.x[1] )
-      nearestBall = this.balls[i];

   if ( this.balls[i].bound == 2 && this.t >= 3.5 )
      this.shoot ( 2 );

Witch ‘em up (CGA Jam, 2017)

Witch 'em Up

► Play in your browser  ·  Source (Lua)
By @Tinchetsu

Limited to a CGA color palette, this side-scrolling shooter might be the perfect introduction to fantasy consoles.

Fun hack: Press ESC to open the code editor, and give yourself more lives or health. You can even make yourself invincible.

Meteorite (LowRezJam 2018)

► Play on Win, macOS, or Linux · Source (Godot, GDScript)
By @Bauxitedev

Watch out for the giant floating eyeball that shoots purple laser beams in this low-resolution, metroidvania, first-person shooter. It’s even more impressive when you consider that this jam had a constraint where any game could only be a maximum of 64×64 pixels.

The Sucker (JS13K, 2012)

The Sucker

► Play in your browser · Source (JavaScript)
Game theme:
13 · By @onether

Can you survive the onslaught of zombies? This zombie survival game was made with less than 13kB.

Fun hack: Turn those red pixels into something a little slimier. Fork the repository and make the following change to this line:

app.blood.forEach(function (elem)
-  ctx.fillStyle = 'rgb(' + (128 + Math.floor(Math.random() * 128)) + ', 0, 0)';
+  ctx.fillStyle = 'rgb(0,' + (128 + Math.floor(Math.random() * 128)) + ', 0)';
   ctx.fillRect(app.round(elem.x), app.round(elem.y), elem.w, elem.h);

Dark Forest (Game Off, 2017)

Dark Forrest► Play on Win or macOS · Source (Unity, C#)
Game theme:
Throwback · By @progrium

Built in just ten days, this polished entry will keep you entertained as you take on an evil spirit from a dark realm.

Fun hack: Windows users can navigate to the DarkForest_Data folder and rename or swap the level1 and level2 files with one another to start on the final level.

Blood Worm (Ludum Dare 33, 2015)

► Play on Win or macOS · Source (JavaScript)
Game theme:
You are the monster · By @whitingjp

This game gives you control of a creepy-crawly worm complete with voiced sound effects. What more could you ask for?

Micromancer (Ludum Dare 33, 2015)

► Play in your browser · Source (JavaScript)
Game theme:
You are the monster · By Team RADMARS

This is another Ludum Dare 33 entry where you play as a necromancer king raising your army of the dead to fight on to victory.

Johnny Smiter: Episode Zero

► Play in your browser (and VR) · Source (JavaScript)
Game theme:
Back · By @supereggbert

This game throws you into a virtual reality forest where you must capture runes and avoid deadly spiders.

We hope you had fun playing with these games. Did you experiment with tweaking some variables, modifying graphics, or updating the sound? We’d love to see it—reply to our post or tag us on Twitter, Facebook and LinkedIn with screenshots or videos. ❤

Happy hack-a-ween!

Build your own game this November

Inspired to build your own game? Game Off, our annual month-long game jam kicks off on November 1st. Check back for the theme and join the fun. 

Join Game Off


The post Thirteen spooktacular games to play, hack, and slash this Halloween appeared first on The GitHub Blog.

This page processed in 0.22 seconds.

Leave a Reply

Your email address will not be published. Required fields are marked *