Skip to content

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 :+1: 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. :+1::-1::smile::confused::heart::tada: 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…:+1: or :tada: to your :heart: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 :tada: 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! :sparkles:

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

Git Large File Storage v1.0

After months of letting our early adopters kick the tires, Git Large File Storage (Git LFS) has reached a 1.0 milestone and is now available to all repositories on GitHub.com.

Git LFS is an open source Git extension that we released in April for integrating large binary files into your Git workflow. Distributed version control systems like Git have enabled new and powerful workflows, but they haven’t always been practical for versioning large files. Git LFS solves this problem by replacing large files with text pointers inside Git, while storing the file contents on a remote server like GitHub.com.

We’re hugely appreciative of the community that’s sprung up around Git LFS. This milestone contains features and fixes that came directly from your feedback and pull requests. Some notable changes include:

  • A fully rewritten HTTP client and API specification that improves concurrency and reduces overhead when transferring thousands of files
  • New git lfs fetch and git lfs pull commands that download objects much faster than the standard Git smudge filter
  • Options for customizing what files are automatically downloaded on checkout
    • Selectively ignore a directory of large files that you don’t need for daily work
    • Download recent files from other branches
  • Improvements to git lfs push that filter the number of commits to scan for eligible LFS objects to upload. This greatly reduces the time to push new feature branches
  • A Windows installer and Linux packages for more convenient installation
  • An experimental extension system for teams that want to customize how objects are stored on the server

Git LFS is now available to all users on GitHub.com, just install the client to get started.

Find and install your favorite developer tools

Our new Integrations Directory showcases a variety of developer tools that extend GitHub and your development workflow. Quickly find tools that work with GitHub to help you and your team build software together. Connect those tools to GitHub to manage all aspects of your software projects—from idea to running application in the hands of customers. Browse new integrations to customize your workflow with functionality provided by our partners.

GitHub integrates with text editors and IDEs, project management and customer support systems, CI and CD services. Developer tools that integrate with GitHub let you build sophisticated chatops workflows, allow you to deploy software directly from your GitHub repositories, and make it easy to track analytics, customer feedback, performance issues, and runtime errors back to a line of code and the context for code changes.

The Integrations Directory shows off some of our favorite tools and allows you to quickly connect them with your GitHub account. Don't see your favorite developer tool or want to get your integration listed? Let us know!

8e540cc2-6782-11e5-86e9-3daa8cf4fb7e

New organization permissions now available

We've begun rolling out major improvements to GitHub organization permissions to all organizations on GitHub.com. These improvements include new customizable member privileges, fine-grained team permissions, and more open communication. Over the next few days, all organization owners will be able to take advantage of the new system.

Announced a few short months ago, these improvements give your organization the flexibility to work the way you want. To recap, here are just a few highlights:

  • (Opt-in) Members can view and mention all teams, even when they're not on those teams.
  • (Opt-in) Members can create repositories without help from an owner.
  • Members can create new teams to self-organize with the people they work with.
  • Owners can give just the right amount of access to contractors and interns by adding them to repositories without giving them the privileges of organization members.
  • And many more! Learn about GitHub's improved organization permissions.

Coding together just got easier.

Attach files to comments

You've been able to attach images to issues and pull request comments for awhile. Now we've expanded that feature to include:

  • Microsoft Word .docx
  • Microsoft Powerpoint .pptx
  • Microsoft Excel .xlsx
  • Text .txt
  • PDF documents .pdf

File attachments screenshot

Just drag and drop the files into the comment box and they will appear in your comment.

Teachers, manage your courses with Classroom for GitHub

Classroom for GitHub is available now, making it easier than ever to teach with GitHub.

Classroom for GitHub screenshot

Thousands of teachers use GitHub in their courses every day. They distribute starter repositories, give feedback on pull requests, and collect assignments. In addition to helping teachers provide a better learning experience, teaching with GitHub gives students early exposure to software development best practices like version control, issue tracking, and code review.

Classroom for GitHub makes typically tedious administrative tasks (like creating repositories and managing access for large courses) simple and streamlined.

How it works

Classroom for Github automates repository creation and access control, making it easy for teachers to distribute starter code and collect assignments from students.

Assignments are the core of Classroom for GitHub. Teachers can easily create an assignment and distribute it to students using a private invitation URL. Optional starter code can be provided for individual or group work. It's even possible to delegate assignment creation and management to co-teachers and teaching assistants by adding them as organization administrators.

Get started

  1. Create an organization
  2. Request free private repositories for your classroom organization (optional)
  3. Create your first assignment with Classroom for GitHub

Open source

Classroom for GitHub is open source and we'd love to have you participate. Check out CONTRIBUTING.md for information on how to help.

Shout out to GitHub Summer of Code student, Mark Tareshawty, from The Ohio State University for his work on Classroom for GitHub.

Something went wrong with that request. Please try again.