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:

gems:
 - 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.

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.

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.

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!

Protected Branches Improvements

Over 100,000 people push to protected branches nearly 300,000 times every week. We’ve been listening to how we can make protected branches even better and we’re happy to introduce two workflow improvements.

Merging out-of-date pull requests

Required status checks currently provide a strong guarantee of compatibility between a pull request’s base and head branches. Not only must the status checks be passing, the head branch must also be up to date with the protected base branch in order to be merged. This catches hard-to-spot incompatible changes that don’t cause merge conflicts but result in broken code nonetheless.

The extra status check runs required by this policy can be a burden for teams where many changes are being made to a protected branch. To make this easier for those teams, we’ve added a setting which will still enforce required status checks but will no longer require a pull request to be up to date before merging.

Toggle whether a branch has to be up to date with a protected branch

User and team restrictions

Sometimes merges to a protected branch are best left to a release manager or a team of people responsible for the stability of that particular branch. Organizations can now specify which members and teams are able to push to a protected branch. Note that organization and repository administrators are always able to push.

Choose which users and teams can push to a protected branch

Protected branches help you keep your codebase safe from force pushes and buggy code. These changes give you better control over whom can push to your protected branches and make the experience for very active repositories much smoother. Check out the documentation for more information or get in touch with any questions or feedback.

Saved replies

We know from community feedback and open source projects (like @notwaldorf’s Chrome extension) that replying with the same response to Issues and Pull requests over and over can be tedious. Saved replies allow you to create a response to Issues and Pull requests and reuse it multiple times, saving you a ton of time typing and posting the replies you use most frequently. It’s available on all repositories starting today.

Using Saved replies

To get started, go to your personal settings and click “Saved replies”. Here, you can add custom replies based on the types of responses you use most frequently. You can edit and update these anytime.

Add a saved reply

You can access your Saved replies when composing or replying to an Issue or Pull request.

Insert a saved reply

Check out the documentation for additional information on the feature.

More code review tools

Effective code review catches bugs before they’re deployed, improves code consistency, and helps educate new developers. We’re adding new features to make code review on GitHub faster and more flexible.

Find what you’re looking for, faster

Pull requests with many changes sometimes require review from several people with different areas of expertise. If you’re a Ruby expert, for example, you might want to focus just on the Ruby code and ignore any changes made to HTML and CSS files. You can use the new files list to search by extensions like .rb, .html, etc. You can also filter by filename if you know what you’re looking for.

Find files you’re looking for, faster

More flexible review

Not all teams review code the same way. The most popular style on GitHub is reviewing all changes in a pull request at once, making the pull request the unit of change. Some teams choose to use a commit-by-commit workflow where each commit is treated as the unit of change and is isolated for review.

Page through commits easily

For teams using this style, you’ll now have access to the new commits list in the review bar which can help you quickly find the commit you want to review. We’ve also added pagination and new keyboard shortcuts to make navigating through commits in a pull request even easier. Use the ? key when viewing a pull request to view the list of keyboard shortcuts.

Use previous and next buttons to navigate through commits

View comments with more context

Every day, developers have interesting conversations and debates about code during the review process. These conversations can help new and future developers gain context quickly and better understand how and why a codebase has evolved over time. To ensure these conversations and the accompanying diffs are never lost we’ve made it easier to get deeper context on any line comment, even if it has been outdated by newer changes.

Use the “view outdated diff” button for more context

Pick up where you left off

While code review is essential for high quality code, it can be a long and tiring process, especially for projects with many incoming pull requests. It’s often most helpful to view just the new changes that have occured after you have reviewed a pull request, so we’ve added a timeline indicator to help you get to those changes, faster.

New changes are now marked in the timeline

Today’s changes are all about making code review on GitHub faster and more flexible for you and your teams. Check out the documentation for more information on working with pull requests. As always, get in touch with us for any questions or feedback. We’d love to hear how we can make code review even better.

Add Reactions to Pull Requests, Issues, and Comments

Every day, thousands of people are having conversations on GitHub around code, design, bugs, and new ideas. Sometimes there are complex and nuanced points to be made, but other times you just want to 👍 someone else's comment. We're adding Reactions to conversations today to help people express their feelings more simply and effectively.

While people have been able to include emoji in responses for a long time, using them as reactions resulted in a lot of noise. In many cases, especially on popular projects, the result is a long thread full of emoji and not much content, which makes it difficult to have a discussion. With reactions, you can now reduce the noise in these threads.

We decided to choose reactions that are relevant to the conversations people have on GitHub. 👍👎😄😕❤️🎉 cover the range of reactions our users typically express through comments on GitHub. We’re looking forward to seeing how the GitHub community uses this set of reactions.

Reactions are available on all Issues and Pull Requests on GitHub today. So go ahead…👍 or 🎉 to your ❤️s content.

Issue references and @mentions for GitHub Desktop

GitHub Desktop on both Windows and Mac now provides suggestions when mentioning team members, referencing Issues, and adding more 🎉 to your commit messages and Pull Requests.

Just as you would on GitHub.com the website, you can bring another collaborator into the conversation by prefacing their username with @, reference any Issue by hitting #, and include any emoji by putting : around its name. Happy shipping!

demonstration of Issue lookup, @ mentions, and emoji lookup

Upload files to your repositories

You’ll soon be able to skip the command line and upload files directly to your repositories without having to leave the browser. Repository uploads will be rolling out over the next few days, so if you can’t upload yet, sit tight.

You can click the “Upload files” button in the toolbar at the top of the file tree.

Upload files button

Or, you can drag and drop files from your desktop onto the file tree.

Repo upload drag & drop animation

Once you’ve added all the files you want to upload, you can commit them directly to your default branch or create a new branch and open a pull request. This will look familiar if you’ve used the “New file” button before.

Check out the documentation for additional information on the feature.

This should make simple file additions a little quicker for new and experienced users alike. Enjoy!

Issue and Pull Request templates

It's hard to solve a problem when important details are missing. Now project maintainers can add templates for Issues and Pull Requests to projects, helping contributors share the right details at the start of a thread. This is the first of many improvements to Issues and Pull Requests that we're working on based on feedback from the community.

screenshot 2016-02-17 10 51 37

To add an Issue template to a repository create a file called ISSUE_TEMPLATE in the root directory. A file extension is optional, but Markdown files (.md) are supported. Markdown support makes it easy to add things like headings, links, @-mentions, and task lists to your templates.

Pull Request templates follows the same pattern: add a file called PULL_REQUEST_TEMPLATE to the root directory of your repository.

If you're worried about the added clutter in the root directory of your project, we also added support for a .github/ folder. You can put CONTRIBUTING.md, ISSUE_TEMPLATE.md, and PULL_REQUEST_TEMPLATE.md files in .github/ and everything will work as expected.

Check out the documentation for additional information on the feature.

Migrate your code with the GitHub Importer

If you have source code in Subversion, Mercurial, Team Foundation Server, or another Git repository, you can now quickly and easily move that code to GitHub with the GitHub Importer. It will move your code and then notify you (via email or in your browser) when your newly populated GitHub repository is ready for action.

Access the GitHub Importer directly from https://import.github.com, or use the import feature to migrate your code when you create a new repository on GitHub.com. Your repository will join over 400,000 that have used this feature to move to GitHub!

Importing a repository

For more on migrating your source code, see "Importing your project to GitHub" in GitHub Help.

GitHub Pages now faster and simpler with Jekyll 3.0

GitHub Pages is now running the latest major version of Jekyll, Jekyll 3.0, and with it, many of the complexities associated with publishing have been further simplified, meaning it's now easier and faster to publish beautiful sites for you and your projects.

A more intuitive Markdown experience

If you're familiar with using Markdown to author issues, pull requests, or comments on GitHub.com, writing Markdown for GitHub Pages sites will now be equally as intuitive. Markdown may be the lingua franca of the open source community, but that doesn't mean that certain regional dialects haven't emerged over the years. Traditionally, authors have had to choose between several different Markdown engines, each with their own interpretations of how Markdown should work.

Starting May 1st, 2016, GitHub Pages will only support kramdown, Jekyll's default Markdown engine. If you are currently using Rdiscount or Redcarpet we've enabled kramdown's GitHub-flavored Markdown support by default, meaning kramdown should have all the features of the two deprecated Markdown engines, so the transition should be as simple as updating the Markdown setting to kramdown in your site's configuration (or removing it entirely) over the course of the next three months.

The highlight zone

GitHub Pages now only supports Rouge, a pure-Ruby syntax highlighter, meaning you no longer need to install Python and Pygments to preview your site locally. If you were previously using Pygments for highlighting, the two libraries are feature compatible, so we'll swap Rouge in for Pygments when we build your site, to ensure a seamless transition.

Traditionally, highlighting in Jekyll has been implemented via the {% highlight %} Liquid tag, forcing you to leave a pure-Markdown experience. With kramdown and Rouge as the new defaults, syntax highlighting on GitHub Pages should work like you'd expect it to work anywhere else on GitHub, with native support for backtick-style fenced code blocks right within the Markdown.

Need for speed

Jekyll 3.0 offers several improvements for previewing and optimizing your site locally. For one, local builds are significantly faster, meaning you can preview your changes in near real time, and with incremental regeneration support (experimental), builds can be even faster still.

Jekyll 3.0 also introduces a liquid profiler. By adding --profile to the build or serve command, Jekyll will analyze your site's build time, so you can see exactly where things can be sped up, ensuring you spend more time authoring content, and less time waiting for your site to build.

Profiler output

Two additional changes

The Jekyll 3.0 upgrade will introduce two additional changes that may affect a small subset of users:

  1. Jekyll no longer supports relative permalinks. This has been the default since Jekyll 2.0, and is only an issue if you explicitly added relative_permalinks: true to your site's configuration. Going forward, regardless of your site's configuration, if you add the permalink directive to a page's YAML front matter, the path should be relative to the site's root directory, not the page's parent.
  2. Starting May 1st, 2016, GitHub Pages will no longer support Textile. If you are currently using Textile (Redcloth) to author your Jekyll site, you'll need to convert your site to use Markdown instead.

The changes introduced today promise to make GitHub Pages a faster, more intuitive experience for new and power users alike. For more information on upgrading, see Jekyll's 3.0 upgrade guide, and if you have any questions about Jekyll 3.0, the upgrade process, or just GitHub Pages in general, please get in touch with us.

Happy (simplified) publishing!

Improved commenting with Markdown

Toolbar

You’ll notice there’s a new Markdown text-formatting toolbar on all the comment fields throughout GitHub. While you've always been able to use Markdown to format your text with links, headers, italics, and lists, the new toolbar allows you to do so without learning Markdown syntax.

The toolbar includes a limited set of tools that gets out of the way of experts, but helps those new to GitHub to write just as clearly, and expressively as anyone else. Neat.

Toolbar

In addition to standard Markdown formatting, the toolbar also includes GitHub-specific features. @mentions bring additional users or teams into the conversation, issue and pull request links allow you to cross-reference related discussions, and task lists track outstanding tasks. They’re now available to you with a single click.

A new look for repositories

Repositories on GitHub are about to get a brand new look. The new design improves navigation and simplifies page layout, all while improving the code and performance under the hood. Over the course of the next two weeks, we'll be rolling out the option to opt-in to the new design from any of your repositories with the click of a button.

New GitHub repository screenshot

The collapsing side menu is now a single, always present navigation at the top of every page within a repository. This improves accessibility, makes navigating more coherent, and allows you to always see the labels for each tab without requiring tooltips.

New clone toolbar screenshot

The Code tab now more prominently emphasizes cloning. Clone with confidence using the redesigned protocol switcher, which now contains explicit menu items with explanatory text for each cloning method instead of simple text links.

Example GitHub issue

With the navigation at the top, it's easier to focus on what matters most to you: your content on the page. For example, with the extra horizontal space, issues and pull requests are simpler with a wider and more legible sidebar.

Large changes like this one can be disruptive. To help make the transition as smooth as possible for you, the new design is opt-in for the next two weeks, and after that, you'll switch over automatically.

We're super excited to share the new design with you and can't wait to keep iterating on it moving forward. Enjoy, and happy collaborating!