The GitHub Blog: New Features

Whether you’re working on an open source project or building a software company, chances are you can simplify your work with GitHub Apps. In May, we launched GitHub Marketplace—a place where you can easily discover, purchase, and integrate new tools that customize your workflow. Today, we’re launching seven new apps in Marketplace and four new categories: Dependency Management, Localization, Security, and Time Tracking.

Code quality, Code review

Better Code Hub provides development teams with immediate, relevant feedback on code quality. It checks a code base against ten guidelines for maintainable software, delivering actionable recommendations and helping your team get to a shared definition of done. A score of ten out of ten indicates you’re performing among top development teams within the industry.

Code Climate provides automated code review, analyzing every commit, branch, and pull request for complexity, duplication, security, and more. It also combines line-by-line test coverage reports, technical debt assessments, and style checks in every pull request so your team merges only clear, maintainable, and well-tested code.

Coveralls helps teams deliver code confidently by providing test coverage history and statistics to show which parts of your code aren’t covered by your test suite. It works with your CI server to sift through new code and reveal changes in overall coverage. Coveralls can also stop deployments that contain newly untested code to protect your live application.

StyleCI is a PHP coding style service that automatically analyzes the code you push to GitHub. If something is amiss, it will immediately notify you through the GitHub Status integration. You can also configure StyleCI to automatically create a pull request with fixes.

Dependency management, Security

Gemnasium monitors project dependencies and alerts you to updates and security vulnerabilities, providing information about all of your repositories in a single interface.

Localization

GitLocalize is a continuous localization tool built for communities and teams that want to simplify their workflow when translating content. GitLocalize automatically syncs with your repository so you can keep your workflow on GitHub. It also keeps you updated on what needs to be translated.

Project management, Time tracking

WakaTime provides you with metrics, insights, and time tracking automatically generated from your programming activity. Compete with your friends on private leaderboards, and improve your productivity with your own personal dashboard.

Whether you’d like to automatically build and test your code as you push it to GitHub, measure performance, track errors, or manage projects, GitHub Apps give you flexibility across your development process. And our ecosystem is always growing. Discover new tools on GitHub Marketplace and start using them in minutes.

The biggest barrier to code review is often time, but there's a new way to easily understand how changes impact your code. Now you can navigate to changed methods and functions right from your pull request file finder.

Searching the file finder for a method or function in a Go, JavaScript, Ruby, or TypeScript file will provide you with a timeline-style view of the results, so you can skip to the most impactful parts of a pull request. Check out the documentation to learn more.

We hope this helps make your review process even more efficient. Let us know if you have any feedback—or if there are other search functions you'd find useful using our help form.

Open source is all about building communities around shared challenges. Thanks to some subtle (and not so subtle) improvements in the past few months, it's now easier to make your first contribution, launch a new project, or grow your community on GitHub:

Contributor badges

One of the best ways to grow your community is to welcome new contributors. To make it easier to identify when a user is new to your project, maintainers now see a "first-time contributor" badge when reviewing pull requests from users that have not previously contributed to the project.

Once the pull request is merged, you will see a "contributor" badge on the user's comments. In addition to being a badge of pride for contributors, the additional flag can also help maintainers better separate signal from noise in lengthy or heated discussions. This information is also exposed via the GraphQL API as the issue, pull request, or comment's authorAssociation.

Easier open source licensing

You've been able to select an open source license template for a while. Now, when you click the "add a license" button from your community profile, or begin adding a LICENSE file via the web editor, you'll be presented with a new license picker:

The license picker offers a brief overview of the license as well as the full text, and allows you to customize any applicable fields before committing the file or opening a pull request.

Simpler email privacy

Joining a community and making your first contribution can be intimidating. For one, not everyone wants their personal information to be public, often inadvertently the default workflow for many Git online tutorials.

While you've been able to hide your email while performing web-based commits for a number of years, and block pushes that expose your email address more recently, now, when you check the "keep your email address private" option in your email settings, we'll also prevent your email from displaying in places like on your profile, in search results, or via the API so that you can contribute more confidently.

We've also made "keep my email private" the default for new users going forward, and regardless of your email privacy settings, your email address will never be visible to logged out users.

Better blocking

Not every open source interaction is a positive one. If you navigate to a repository and someone you've blocked is a prior contributor, we'll show you a warning so that you can make an informed decision if you'd like to contribute to the project or not:

In addition to repositories you own, blocked users are now no longer able to comment on issues or pull requests you author in repositories owned by organizations or other users.

We hope these improvements will help you make your first contribution, start a new project, or grow your community. If you have any questions, check out the building a strong community documentation or get in touch.

You write software so that others can use it, but no software is perfect, and sometimes users have questions or run into trouble. To better direct users to dedicated support channels, you can now describe your project's support resources in a SUPPORT file.

SUPPORT files work just like CONTRIBUTING files. They can live in your repository root, .github/, or docs/ folder, and will be displayed throughout GitHub such as above the new issue form:

Instead of describing how to contribute to the project like CONTRIBUTING files do, SUPPORT files can be used to direct users to dedicated support resources, such as community forums, FAQ documents, or corporate support channels.

For more information, see the SUPPORT file documentation, and of course, you can always contact GitHub Support if you have any questions.

Manage your repositories' incoming issues more efficiently with a few new updates: a keyword and saved reply to mark duplicate issues, along with a clearer, more informative style for keywords.

Marking an issue as a duplicate

Sometimes your users report the same bug, or your teammates share the same idea. No matter why a redundant issue was posted, you can now mark it as a duplicate of another issue.

To flag a duplicate, add a comment using the duplicate of keyword followed by the issue number or URL. A "Marked as duplicate" timeline event will appear in the timelines of the referenced issues.

Learn more about duplicate issues

Improved keyword styling

We've updated the way keywords are displayed in issues and pull request to give you more information. Keywords like closes are highlighted, and when you hover over them, you'll see a tooltip explaining what the keyword means. For closes, you'll learn that the referenced issue will close when the pull request is merged.

Learn more about using keywords

While effective code review is essential to every successful project, it's not always clear who should review files—even with GitHub's reviewer suggestions. Now repository maintainers can define exactly which people and teams need to review projects using code owners. This new feature automatically requests reviews from the code owners when a pull request changes any owned files.

How code owners work

To specify code owners, create a file named CODEOWNERS in the repository's root directory (or in .github/ if you prefer) with the following format:

# Lines starting with '#' are comments.
# Each line is a file pattern followed by one or more owners.

# These owners will be the default owners for everything in the repo.
*       @defunkt

# Order is important. The last matching pattern has the most precedence.
# So if a pull request only touches javascript files, only these owners
# will be requested to review.
*.js    @octocat @github/js

# You can also use email addresses if you prefer.
docs/*  [email protected]

This format may be familiar if you've used gitattributes.

With that in place, code owners will automatically be requested for review whenever a pull request touches the files they own.

An extra layer of code security

For projects with more rigorous review processes, we've also added a new protected branch option to ensure the right people have a chance to review.

With protected branches enabled, a code owner for each owned file has to leave a review before anyone can merge a pull request to that branch.

We hope this helps make your review process even more effective. Let us know if you have any feedback on code owners using our help form.

The code owners feature was inspired by Chromium's use of OWNERS files.

You're invited to watch, fork, and collaborate on GitHub's Terms of Service and other site policies. Back in March we open sourced our Balanced Employee IP Agreement. The feedback from the community has been amazing. Not only have you given us comments and suggestions to make the agreement better, we've also heard anecdotes of other companies taking inspiration from it.

Now we're continuing to harness the power of open source by opening up our GitHub.com site policies in a new working repository, github/site-policy. Here you can view, comment, and suggest changes to our site policies—or fork a copy to adapt for your own site. Along with this new repository, we're also posting changes to our Terms of Service for public comment.

Why open source site policies?

Save time and money. Although essential for any online service, site policies can be time intensive and expensive to create. We hope that by opening up our privately and publicly vetted policies, your startup will be able to cut down on some of those legal fees.

Improve and iterate. Iteration makes things even better. With the help of our community, we can improve on and build policies that work best for everyone. We welcome your issues and pull requests.

Comment on new changes. Changes to our site policies can have a huge impact on you. The new repository is the perfect way to let us know how. Whenever we have significant changes, we'll post them as a pull request. From there, you can see the updates and easily leave comments or feedback.

Give it a try: comment on changes to our Terms of Service

To get you started, we have a new set of changes to our Terms of Service and Corporate Terms of Service. Feel free to look them over and try out the new Site Policy repository to share your input. Please follow our Contributor Guidelines, and let us know if you see anything you think should be different—whether it’s a missed typo or a rule that might have implications we haven’t thought of.

An overview of changes to our site Terms

• Updates to GitHub Terms of Service: Added a "Private Repositories" section as Section E, updated the licenses granted in Section D for clarity, and updated the Complete Agreement subsection in Section S, "Miscellaneous"

• Updates to GitHub Corporate Terms of Service: Added a "Private Repositories" section as Section E, updated the licenses granted in Section D for clarity, updated the Complete Agreement subsection, and added a Publicity subsection to Section S, "Miscellaneous"

• Added a product description to the GitHub Business Plan Addendum

• Updated the Amendment to GitHub Terms of Service Applicable to U.S. Federal Government Users to reflect previous changes to notification policy

We’ll leave comments open until 5:00 pm PST Friday, July 28. Then we’ll take a week to go through your comments and make changes to improve the Terms. We’ll enact the new Terms on Monday, August 7.

Sound interesting? Check out the github/site-policy repository to learn more, and share your feedback. We'd love to hear if our project is useful to you in creating foundations for your own business.

Review requests are a great way to get the people you need to look at your work.

Now with team requests, you can find the right group of people and review code together.

Have questions about code review on GitHub? Ask away or share your comments and feedback using our help form.

The GitHub for Unity extension we announced at the Game Developers Conference last March is now open source! Download the latest release for Windows and OS X for free, and enjoy the benefits of Git and features of GitHub without leaving Unity.

Large files? No problem!

GitHub for Unity supports Git LFS, the open source Git extension for versioning large files.

Add file locking to your workflow

With the introduction of file locking in Git LFS 2.2.0, locking files to avoid merge conflicts is a simple as a few clicks. No more shouting at your colleagues from across the room (or sending them messages in ALL CAPS) telling them to leave your scene alone.

Bring the GitHub workflow to Unity

Ditch the command line and view your project history, experiment in branches, craft a commit from your changes, and push your code to GitHub—all within Unity.

Known issues and bugs

GitHub for Unity is still alpha quality. Please check out the known issues, and make sure you have backups of your work before trying it out.

Find a bug? Want to suggest a feature? Look over our Contributing Guide. We're focused on triaging reported issues as we work towards a 1.0 milestone, and we'd love your help. All contributions are welcome.

If you have any questions or comments, email us at [email protected].

Kudos

Thank you to all of the preview release participants for your feedback. And of course, our friends on the Git LFS team and at Unity.

Open source software powers the internet. Anyone using a computer uses open source, either directly or indirectly. Although it has become the industry standard, getting involved isn't always straightforward.

Because so much of the open source community works with GitHub, we're working to make it easier for people to start and contribute to open source projects. This year we've documented best practices with our Open Source Guides, released our balanced employee IP agreement which eases employee contributions, and provided insight into the state of the community with the Open Source Survey.

Now we're inviting you to join our latest effort to make it easier to contribute to the open source community: Open Source Friday.

Open Source Friday is a structured program for contributing to open source. Contribution to open source is part of our DNA with GitHub employees maintaining projects like gh-ost, Rails, Atom, Homebrew, HospitalRun and Exercism. Over the last three years, we've encouraged GitHub employees to take time at least every fourth Friday to work on open source and share what we're working on with each other. Open Source Friday has grown from this into a program anyone can take part in.

Open Source Friday isn't limited to individuals. Your team, department, or company can take part, too. Contributing to the software you already use isn't altruistic—it's an investment in the tools your company relies on. And you can always start small: spend two hours every Friday working on an open source project relevant to your business.

Whether you're an aspiring contributor or active maintainer of open source software, we help you track and share your Friday contributions. We also provide a framework for regular contribution, along with resources to help you convince your employers to join in.

Join our friends at Google, Microsoft, Facebook, Comcast, Travis CI, and thoughtbot, who believe that contributing to open source should be part of their developers' work.

Thank you @andrew, @Charlotteis, @maxcell, @benpolinsky and @stevelacy for helping us build this project! Want to help improve Open Source Friday? The app is open source, so head over to ossfriday/ossfriday to submit a pull request.

We're introducing two new tools to help maintain and grow open source communities.

Recommended community standards

As an open source project grows beyond code, it can be difficult to maintain new contributions, documentation, issues, and the legal side of running a larger project. On your community profile, you'll see a checklist showing how your project compares to our recommended community standards. From there, you can easily add any missing files.

If you're a project maintainer, view your community profile by clicking the repository header's Insights tab and selecting Community.

Easier codes of conduct

As your project grows and matures, it's often necessary to spell out community roles, norms, and expectations. One of the recommended best practices is to add a code of conduct to your project. If you click the prompt from your community profile (or begin adding a CODE_OF_CONDUCT.md file to your repository), you'll see a short list of common templates to choose from. Then you can create a pull request to add a code of conduct to your repository.

Learn more

• Community profile
• Code of conduct tool

Now you can use multiple levels of nested teams to reflect your group or company's hierarchy within your GitHub organization, making your organization's permissions structure clearer and easier to manage.

Child teams inherit their parent's access permissions, so repository permissions and @mentioning among nested teams work from top to bottom. If your team structure is Employees > Engineering > Application Engineering > Identity, granting Engineering write access to a repository means Application Engineering and Identity also get that access. And if you @mention the Identity Team or any other team at the bottom of the organization hierarchy, they're they only ones who will receive a notification.

Membership inheritance from parent to child teams isn't automatic. If you're a member of Engineering and someone creates a child team called Security, team members of Engineering aren't automatically direct team members of Security. Security and all other teams nested under the Engineering will inherit repository permissions and @mentions but nothing else.

Check out the documentation to learn more and start structuring your existing teams!

It's easy to explore code in your browser when you visit a GitHub repository, but you often want to pull that code directly into the appropriate editor and try it out. For example, if the repository contains an .xcodeproj or .xcworkspace file, you might want to open that code in Xcode.

This is possible starting today with the new "Open in Xcode" button.

The button works with Xcode 9, the latest version announced at today's WWDC, which includes GitHub integration developed by Apple. Once you authenticate into Xcode with your GitHub account, the "Open in Xcode" button will appear for relevant repositories on GitHub. Click the button and Xcode will launch, prompting you to choose a directory to clone the repository to your local machine.

Happy cloning!

We just released an open data set for the open source community, researchers, and curious data wonks to study.

The data includes responses from 5,500 open source participants randomly sampled from over 3,800 projects on GitHub.com and over 500 sourced from communities that work on other platforms. Altogether, the data represents some of the most comprehensive and high-quality data on the open source community to date.

The Open Source Survey covers a broad set of topics, including:

• What people value in the software they use and in open source projects
• How and where people find and provide help
• Privacy preferences and practices
• Employer policies around using and contributing to open source
• Negative experiences and their consequences
• Personal backgrounds of community members

We hope you'll use the data to inform decisions about community, tooling, and prioritization of work; understand the needs and experiences of different parts of the community; and do new and interesting research on a remarkable system of peer production that powers so much of modern life.

In the meantime, we've started using the findings to help us understand what makes a healthy community and how we can improve GitHub for maintainers, contributors, and end users.

Huge thanks to all of our collaborators in academia, industry, and the open source community who contributed topic ideas and questions, helped with translations, and took the survey. You can find the data, and an analysis of the key findings, at opensourcesurvey.org. Let us know how you use the data or write to us with questions or comments.

When issue or pull request discussions get heated, sometimes a solution can't be reached until everyone has had time to cool down. Now, with interaction limits, maintainers can temporarily limit who can comment, create pull requests, and open issues among existing users, collaborators, and prior contributors. After 24 hours, limits expire and allow users to go back to participating in the conversation.

You'll find interaction limits when you click on the Settings tab in any repository you own.

This is just one tool your team can use to promote healthy, level-headed collaboration.

Learn more about interaction limits