ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

このバージョンの GitHub Enterprise はこの日付をもって終了となります: このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2020-08-20. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてください。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してください。

記事のバージョン: Enterprise Server 2.18

About apps

You can build integrations with the GitHub APIs to add flexibility and reduce friction in your own workflow. You can also share integrations with others on GitHub Marketplace.

ここには以下の内容があります:

Apps on GitHub allow you to automate and improve your workflow. You can build apps to improve your workflow.

GitHub Apps are the officially recommended way to integrate with GitHub because they offer much more granular permissions to access data, but GitHub supports both OAuthアプリケーションs and GitHub Apps. For information on choosing a type of app, see "About apps" and "Differences between apps."

For a walkthrough of the process of building a GitHub App, see "Building Your First GitHub App."

GitHub Appsについて

GitHub Apps are first-class actors within GitHub. A GitHub App acts on its own behalf, taking actions via the API directly using its own identity, which means you don't need to maintain a bot or service account as a separate user.

GitHub Apps can be installed directly on organizations and user accounts and granted access to specific repositories. They come with built-in webhooks and narrow, specific permissions. When you set up your GitHub App, you can select the repositories you want it to access. For example, you can set up an app called MyGitHub that writes issues in the octocat repository and only the octocat repository. To install a GitHub App, you must be an organization owner or have admin permissions in a repository.

By default, only organization owners can manage the settings of GitHub Apps in an organization. To allow additional users to manage GitHub Apps in an organization, an owner can grant them GitHub App manager permissions. See "GitHub App Managers" to learn how to add and remove GitHub App managers in your organization.

GitHub Apps are applications that need to be hosted somewhere. For step-by-step instructions that cover servers and hosting, see "Building Your First GitHub App."

To improve your workflow, you can create a GitHub App that contains multiple scripts or an entire application, and then connect that app to many other tools. For example, you can connect GitHub Apps to GitHub, Slack, other in-house apps you may have, email programs, or other APIs.

Keep these ideas in mind when creating GitHub Apps:

  • A GitHub App should take actions independent of a user (unless the app is using a user-to-server token).

  • Make sure the GitHub App integrates with specific repositories.

  • The GitHub App should connect to a personal account or an organization.

  • Don't expect the GitHub App to know and do everything a user can.

  • Don't use a GitHub App if you just need a "Login with GitHub" service. But a GitHub App can use a user identification flow to log users in and do other things.

  • Don't build a GitHub App if you only want to act as a GitHub user and do everything that user can do.

To begin developing GitHub Apps, start with "Creating a GitHub App."

About OAuthアプリケーションs

OAuth2 is a protocol that lets external applications request authorization to private details in a user's GitHub account without accessing their password. This is preferred over Basic Authentication because tokens can be limited to specific types of data and can be revoked by users at any time.

Warning: Revoking all permission from an OAuthアプリケーション deletes any SSH keys the application generated on behalf of the user, including deploy keys.

An OAuthアプリケーション uses GitHub as an identity provider to authenticate as the user who grants access to the app. This means when a user grants an OAuthアプリケーション access, they grant permissions to all repositories they have access to in their account, and also to any organizations they belong to that haven't blocked third-party access.

Building an OAuthアプリケーション is a good option if you are creating more complex processes than a simple script can handle. Note that OAuthアプリケーションs are applications that need to be hosted somewhere.

Keep these ideas in mind when creating OAuthアプリケーションs:

  • An OAuthアプリケーション should always act as the authenticated GitHub user across all of GitHub (for example, when providing user notifications).
  • An OAuthアプリケーション can be used as an identity provider by enabling a "Login with GitHub" for the authenticated user.
  • Don't build an OAuthアプリケーション if you want your application to act on a single repository. With the repo OAuth scope, OAuthアプリケーションs can act on all of the authenticated user's repositories.
  • Don't build an OAuthアプリケーション to act as an application for your team or company. OAuthアプリケーションs authenticate as a single user, so if one person creates an OAuthアプリケーション for a company to use, and then they leave the company, no one else will have access to it.

For more on OAuthアプリケーションs, see "Creating an OAuthアプリケーション" and "Registering your app."

個人アクセストークン

A personal access token is a string of characters that functions similarly to an OAuth token in that you can specify its permissions via scopes. A personal access token is also similar to a password, but you can have many of them and you can revoke access to each one at any time.

As an example, you can enable a personal access token to write to your repositories. If then you run a cURL command or write a script that creates an issue in your repository, you would pass the personal access token to authenticate. You can store the personal access token as an environment variable to avoid typing it every time you use it.

Keep these ideas in mind when using personal access tokens:

  • Remember to use this token to represent yourself only.
  • You can perform one-off cURL requests.
  • You can run personal scripts.
  • Don't set up a script for your whole team or company to use.
  • Don't set up a shared user account to act as a bot user.

Determining which integration to build

Before you get started creating integrations, you need to determine the best way to access, authenticate, and interact with the GitHub APIs. The following image offers some questions to ask yourself when deciding whether to use personal access tokens, GitHub Apps, or OAuthアプリケーションs for your integration.

Intro to apps question flow

Consider these questions about how your integration needs to behave and what it needs to access:

  • Will my integration act only as me, or will it act more like an application?
  • Do I want it to act independently of me as its own entity?
  • Will it access everything that I can access, or do I want to limit its access?
  • Is it simple or complex? For example, personal access tokens are good for simple scripts and cURLs, whereas an OAuthアプリケーション can handle more complex scripting.

サポートのリクエスト

GitHub App、OAuthアプリケーション、API開発に関する疑問、バグレポート、議論については、GitHub API Development and Support Forumを調べてみてください。 このフォーラムはGitHub Enterpriseのスタッフによって進行及び管理されていますが、フォーラムにポストされた疑問に対してGitHub Enterpriseのスタッフからの返答があることは保証されていません。

以下の場合は、連絡フォームを使ってGitHub Supportに直接連絡することを検討してください。

  • GitHub Enterpriseのスタッフからの反応を確実に得たい場合
  • センシティブなデータやプライベートな懸念事項に関わるサポートリクエスト
  • 機能リクエスト
  • GitHub Enterpriseの製品に関するフィードバック

担当者にお尋ねください

探しているものが見つからなかったでしょうか?

弊社にお問い合わせください