Navigate file history faster with improved blame view

Whether you're debugging a regression or trying to understand how some code came to have its current shape, you'll often want to see what a file looked like before a particular change. With improved blame view, you can easily see how any portion of your file has evolved over time without viewing the file's full history.

use-the-improved-blame-view-to-see-what-the-file-looked-like-before-a-particular-change

Check out the GitHub Help documentation for more information on using git blame to trace the changes in a file.

Visualize your project's community

A new graph is available in the Graphs tab to visualize your repository's data. With the dependents graph, you can now explore how repositories that contain Ruby gems relate to other repositories on GitHub.

If you're an open source maintainer, this means you can find out more about the community connected to your project in addition to projects that depend on your repository and its forks.

Screenshot of dependents page

The page starts with a list of the latest repositories to depend on your repository, making it easier to discover the newest members of your community. It also allows you to filter by either packages, which are other repositories that are gems, or applications, which are other public repositories that aren't gems themselves but use your gem.

The dependency graph works for Ruby gems today, and we plan to expand support to other package ecosystems in the future. For more on what graphs can tell you about your project, check out our Help guide on Graphs.

Publishing with GitHub Pages, now as easy as 1, 2, 3

Publishing a website or software documentation with GitHub Pages now requires far fewer steps — three to be exact:

  1. Create a repository (or navigate to an existing repository)
  2. Commit a Markdown file via the web interface, just like you would any other file
  3. Activate GitHub Pages via your repository's settings

And that's it — you now have a website. If you're already familiar with GitHub Pages, you may be interested to know that behind the scenes, we're now doing a few things to simplify the publishing experience and bring it more in line with what you may expect from authoring Markdown content elsewhere on GitHub:

  1. All Markdown files are now rendered by GitHub Pages, saving you from needing to add YAML front matter (the metadata at the top of the file separated by ---s) to each file.
  2. We'll use your README file as the site's index if you don't have an index.md (or index.html), not dissimilar from when you browse to a repository on GitHub.
  3. If you don't specify a theme in your site's config (or don't have a config file at all), we'll set a minimal, default theme that matches the look and feel of Markdown elsewhere on GitHub.
  4. If a given file doesn't have a layout specified, we'll assign one based on its context. For example, pages will automatically get the page layout, or the default layout, if the page layout doesn't exist.
  5. If your page doesn't have an explicit title, and the file begins with an H1, H2, or H3, we'll use that heading as the page's title, which appears in places like browser tabs.

These improvements should allow you to quickly and easily publish your first (or 100th) website with just a few clicks, or to document your software project by simply adding Markdown files to a /docs folder within your repository. Of course, you can continue to control the look and feel by opting in to additional customizations (such as overriding the default theme with your own layouts or styles).

While these changes shouldn't affect how most existing sites build, there are two potential gotchas for some more advanced Jekyll users:

  1. If your site iterates through all pages (e.g., for page in site.pages), you may find that there are now additional pages (such as the README of a vendored dependency) in that list. You can explicitly exclude these files with your config file's exclude directive.
  2. If you don't specify a page's layout or title, and expect either to be unset (e.g., if you need to serve unstyled content), you'll need to explicitly set those values as null.

And if for any reason you don't want these features, you can disable them by adding a .nojekyll file to your site's root directory.

So that the GitHub Pages build process can be as transparent and customizable as possible, all the above features are implemented as open source Jekyll plugins, namely Jekyll Optional Front Matter, Jekyll README Index, Jekyll Default Layout, and Jekyll Titles from Headings.

Again, these changes shouldn't affect how most existing sites build (although you can safely begin to use these features), but if you have any questions, please get in touch with us.

Happy three-step publishing!

Introducing review requests

You can now request a review explicitly from collaborators, making it easier to specify who you'd like to review your pull request.

You can also see a list of people who you are awaiting review from in the pull request page sidebar, as well as the status of reviews from those who have already left them.

gif of requesting review from sidebar

Pending requests for review will also show in the merge box. They do not affect mergability, however, so you can still merge your pull request even if you are still awaiting review from another collaborator.

image of merge box showing a requested review

Learn more about requesting reviews in our Help docs.

Introducing GitHub Community Guidelines

Building software should be safe for everyone. The GitHub community is made up of millions of developers around the world, ranging from the new developer who created their first "Hello World" project to the most well-known software developers in the world. We want the GitHub community to be a welcoming environment where people feel empowered to share their opinion and aren't silenced by fear or shouted down.

Beginning today, we will be accepting feedback on proposed GitHub Community Guidelines. By outlining what we expect to see within our community, we hope to help you understand how best to collaborate on GitHub and what type of actions or content may violate our Terms of Service. The policy consists of four parts:

  1. Best practices for building a strong community - people are encouraged to be welcoming, assume no malice, stay on topic, and use clear and concise language at all times.
  2. What to do if something offends you - project maintainers are encouraged to communicate expectations and to moderate comments within their community — including locking conversations or blocking users when necessary.
  3. What behavior is not allowed on GitHub - the community will not tolerate threats of violence, hate speech, bullying, harassment, impersonation, invasions of privacy, sexually explicit content, or active malware.
  4. What happens if someone breaks the rules - GitHub may block or remove content and may terminate or suspend accounts that violate these rules.

As always, we will continue to investigate any abuse reports and may moderate public content on our site that we determine to be in violation of our Terms of Service. To be clear, GitHub does not actively seek out content to moderate. Instead, we rely on community members like you to communicate expectations, moderate projects, and report abusive behavior or content.

Additionally, we are releasing the guidelines under the Creative Commons Zero License in hopes of encouraging other platforms to establish similar norms to govern their respective communities.

These guidelines are first and foremost community guidelines and we'd like to hear your thoughts on them before they're finalized. Please get in touch with us with any feedback or questions prior to November 20th, 2016. Together, we can make the open source community a healthy, inclusive place we can all be proud of.

Updates to our Privacy Statement

When you check your GitHub account today, you’ll see an announcement letting you know that we’ve updated our Privacy Statement. Check it out!

Before we get into what’s new, rest assured that your information is still safe and sound. We have not made any substantive changes to the way we handle your information. For example, we still . . .

  • don’t sell your personal information to any third parties for their commercial purposes;
  • don’t have advertising on GitHub;
  • only require a small amount of information; and
  • only use your information for the purpose of providing services to you.

What’s changed

The new Privacy Statement clarifies quite a few things about how GitHub uses data, and how we permit third parties to use your information. For example, the new Privacy Statement describes how people such as researchers or archivists can use your public information on GitHub.com, and it explains that third parties using public information must respect our users’ choices. The new Privacy Statement now also includes a statement regarding tracking—we don’t track your web browsing off our site, and we don’t let third parties track you on GitHub.

Privacy Shield compliance

With this updated Privacy Statement, we’ve also applied for certification with the new EU–US Privacy Shield Framework. Privacy Shield is an agreement between the US Department of Commerce and the European Commission that provides companies in both the United States and the European Union a mechanism to comply with EU data protection requirements when transferring personal data from the EU to the US. We expect to receive our certification shortly, and we currently comply with the Privacy Shield Principles to protect all our users’ information.

Protecting our users

Although the Privacy Shield is only directed to users in the European Union, GitHub is committed to protecting all our users equally, regardless of where you live. So we are extending Privacy Shield’s benefits to all our users, including access to a free independent arbitration provider for privacy disputes.

Please take a few minutes to look over the new Privacy Statement, and please reach out if you have any questions.

GitHub Extension for Visual Studio 2.0 is now available

We're pleased to announce that version 2.0 of the GitHub Extension for Visual Studio is now available. You can install it directly from the Tools and Extensions gallery in Visual Studio, as well as from our releases page and our website.

This release allows you to list your existing pull requests and create new ones directly from Visual Studio. You can also create gists directly from your code, making it even easier to share your code and collaborate. It also includes a slew of other enhancements and fixes, available in our release notes.

Screenshot of Visual Studio with GitHub pane open

As we focus our efforts on building workflows targeted towards maintainers and contributors, we'd love to hear your thoughts on how we can improve our tools. Let us know what works and what doesn't and how to make your coding and collaboration workflows easier.

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.