Reorder issues within a milestone

Milestones and labels are a handy way to group and organize your issues, but sometimes it’s helpful to indicate which ones you or your team want to focus on first. You can now reorder issues and pull requests and indicate priority by moving them higher up or lower down the list.

Re-ordering Issues

reordering

Once you’ve grouped issues and pull requests within a milestone, drag-and-drop to place them in whatever order you need, or use keyboard commands to select and move items up or down the list.

keyboard shortcuts

Learn more about Milestones and issue prioritization in our help guide.

GitHub Security Update: Reused password attack

What happened?

On Tuesday evening PST, we became aware of unauthorized attempts to access a large number of GitHub.com accounts. This appears to be the result of an attacker using lists of email addresses and passwords from other online services that have been compromised in the past, and trying them on GitHub accounts. We immediately began investigating, and found that the attacker had been able to log in to a number of GitHub accounts.

GitHub has not been hacked or compromised.

What information was involved?

For affected accounts, usernames and passwords are involved. Additionally, for some accounts, other personal information including listings of accessible repositories and organizations may have been exposed.

What we are doing:

In order to protect your data we’ve reset passwords on all affected accounts. We are in the process of sending individual notifications to affected users.

What you can do:

If your account was impacted, we are in the process of contacting you directly with information about how to reset your password and restore access to your account.

We encourage all users to practice good password hygiene and enable two-factor authentication to protect your account.

These attacks often evolve, and we’re continuing to investigate and monitor for new attack vectors. Please keep an eye on our blog and on Twitter for pertinent updates, or contact Support if you have any questions.

More contributions on your profile

Earning green squares on your contribution graph means celebrating the work you do in open source and public projects. Starting today, you can also celebrate the work you do in private by sharing anonymized contributions from private repositories.

GitHub contribution graph settings

We think including your work in private repositories is a more accurate representation of your contributions, but your privacy is important too. Private contributions are not shown by default and, when enabled, are completely anonymized to the general public. You can opt into sharing your private contributions in your profile settings. Details of the issues, pull requests, and commits you have made on private repositories are only visible to your fellow repository collaborators.

As part of this update, code streaks are no longer featured on your contribution graph. The simplified interface focuses on the work you're doing rather than the duration of your activity.

Now that every paid plan includes unlimited private repositories, you can experiment all you want in private and still add to your contribution graph. For more information, read our help guide for toggling private contributions on your profile.

Import repositories with large files

You can now import repositories from Subversion, Mercurial, and TFS that include files larger than 100 MB using the GitHub Importer.

detecting and importing

This new ability is powered by Git LFS. When the repository you are importing has files larger than 100 MB you can opt-in to using LFS to store those large files or opt-out and the files will simply be removed from your repository during the import.

opting in or out of LFS

You can learn more about our LFS feature and working with large files on our help site.

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 GitHub.com. For more information, check out the developer blog and take a look at the documentation for a full list of webhook events.

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.

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!

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.

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 add 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!

Start Learning Git and GitHub Today with Self-Paced Training

Can't wait for the next live course to get started with Git and GitHub? If so, we have an on-demand training option designed just for you.

GitHub for Developers is a self-paced course that distills best practices and documentation into a focused series of interactive lessons and covers the two most important things you need to know:

  1. Using Git to confidently manage your source code
  2. Using GitHub to collaborate with your team

GitHub for Developers is designed for command-line users who are new to Git and GitHub. This course will help you master the basics of both, from performing essential Git operations to dealing with merge conflicts in Pull Requests. You will even rewrite a bit of project history and learn how to undo almost anything with Git. The course will cover the following sections:

  • Section 1: Introducing Git and GitHub
  • Section 2: Getting Started with Collaboration
  • Section 3: The GitHub Workflow: Branching and Committing
  • Section 4: The GitHub Workflow: Pull Requests
  • Section 5: Setting up Git
  • Section 6: Using GitHub Locally
  • Section 7: The Workflow End-to-End
  • Section 8: Working with Local Files
  • Section 9: Fixing Common Issues with Git
  • Section 10: Creating Shortcuts

We've chosen the Wheelhouse education platform to deliver realistic, hands-on projects for an immersive learning experience. You will watch short videos from the GitHub training team, complete exercises to put your new knowledge to work, and receive immediate feedback on the tasks you complete. You will even be guided in practicing skills within your personal GitHub.com account.

For a limited time, we're teaming up with Wheelhouse to offer complimentary access to the GitHub for Developers self-paced course in exchange for your feedback.

To get started, go to training.github.com and click the On Demand tab.