はてなブックマーク

さまざまなシナリオでのコンカレンシーの使用 同じコンカレンシー グループを使うジョブまたはワークフローを一度に 1 つだけ実行するには、jobs.<job_id>.concurrency を使います。 並行処理グループには、任意の文字列または式を使用できます。 使用できる式コンテキスト: github、inputs、vars、needs、strategy、matrix。 式の詳細については、「ワークフローとアクションで式を評価する」を参照してください。 ワークフロー レベルで concurrency を指定することもできます。 詳細については、「concurrency」を参照してください。 つまり、コンカレンシー グループには、最大 1 つの実行ジョブと 1 つの保留中のジョブが存在できることを意味します。 並行ジョブかワークフローがキューに入っている場合、リポジトリ内の同じ並行グループを

ファイルとディレクトリの削除について リポジトリ内の個々のファイル、またはディレクトリ内のすべてのファイルを含むディレクトリ全体を削除できます。 書き込みアクセス許可をもっていないリポジトリ内のファイルまたはディレクトリを削除しようとした場合は、変更をコミットした後に、プロジェクトが個人用アカウントへフォークされ、pull request を元のリポジトリへ送信できるようになります。 詳しくは、「pull requests について」をご覧ください。 削除したファイルまたはディレクトリに機密データが含まれている場合、そのデータはリポジトリの Git 履歴で引き続き入手可能です。 GitHub からファイルを完全に削除するには、リポジトリの履歴からファイルを削除する必要があります。 詳しくは、「リポジトリからの機微なデータの削除」をご覧ください。 ファイルを削除する リポジトリ内で削除対象の

People with at least triage permissions for a repository can add sub-issues. sub-issue を issue に追加することで、大きな作業をタスクに分割できます。 sub-issue は、親の issue との関係が表示されるため、GitHub 全体で作業を追跡できます。 親の issue と sub-issue の進行状況は、projects でも利用できます。これにより、ビューの作成、親の問題によるフィルター処理、グループ化を行うことができます。 sub-issue 自体に sub-issue を含めることができるため、プロジェクト全体または作業の一部を視覚化し、issue 間の関係を示す issue の完全な階層を作成できます。 親 issue ごとに最大 100 個のサブ issue を追加でき、最大

GitHub Pages サイトのアクセス制御について GitHub Pages のアクセス制御では、サイトをプライベートで公開することで、プロジェクト サイトへのアクセスを制限できます。 プライベートで公開されたサイトは、サイトの公開元のリポジトリの読み取りアクセスを持っている人だけがアクセスできます。 プライベートで公開されたサイトは、内部的なドキュメンテーションや知識ベースをEnterpriseのメンバーと共有するために利用できます。 メモ GitHub Pages サイトをプライベートで公開するには、organization が GitHub Enterprise Cloud を使っている必要があります。 GitHub Enterprise Cloud を無料で試す方法の詳細については、「GitHub Enterprise Cloud の試用版を設定する」を参照してください。 自社

GitHub CLI 拡張機能をインストールして Webhook 転送を有効にするには、extension install サブコマンドを使います。 gh extension install cli/gh-webhook 組織の Webhook を転送しない場合、必要なアクセス許可が与えられるよう、admin:org_hook スコープを GitHub CLI ログインに追加します。 gh auth refresh --scopes admin:org_hook アプリケーションをローカルで起動し、Webhook を受信する予定の URL をメモします。 このガイドでは、アプリケーションが http://localhost:3000/webhook で Webhook イベントをリッスンしていることを前提としています。 Webhook がアプリケーションに配信されるように設定するには、we

概要 OpenID Connect (OIDC) を使うと、GitHub Actions ワークフローでは、有効期間の長い GitHub シークレットとしてアマゾン ウェブ サービス (AWS) 資格情報を格納しなくても、AWS 内のリソースにアクセスできます。 このガイドでは、GitHub の OIDC をフェデレーション ID として信頼するように AWS を構成する方法と、トークンを使って AWS に対する認証とリソースへのアクセスを行う aws-actions/configure-aws-credentials のワークフロー例を示します。 前提条件 GitHub が OpenID Connect (OIDC) を使用する方法の基本的な概念とそのアーキテクチャと利点については、「OpenID Connect」を参照してください。 先に進む前に、アクセス トークンが予測可能な方法での

GitHub Apps の登録について GitHub App は、いくつかの方法で登録できます。 個人用アカウント配下 自分が所有する組織配下 全アプリを管理する権限を付与した組織の配下 「Organization の GitHub App マネージャーを追加および削除する」を参照してください。 ユーザーまたは organization は、最大 100 個の GitHub Apps を登録できますが、1 つのアカウントにインストールできる GitHub Apps の数に制限はありません。 GitHub App の登録 GitHub の任意のページの右上隅にある、自分のプロファイル写真をクリックします。 アカウント設定にアクセスしてください。 個人用アカウントが所有するアプリの場合は、[設定] をクリックします。 組織が所有するアプリの場合: [自分の組織] をクリックします。 組織の右側

ダイアグラムの作成について Markdown では、Mermaid、geoJSON、topoJSON、ASCII STL の 4 つの異なる構文を使用してダイアグラムを作成できます。 ダイアグラムのレンダリングは、GitHub Issues、GitHub Discussions、pull request、Wiki、Markdown ファイルで利用できます。 Mermaid ダイアグラムの作成 Mermaid は、テキストをダイアグラムにレンダリングする、マークダウンから着想を得たツールです。 たとえば、Mermaid ではフローチャート、シーケンス図、円グラフなどをレンダリングできます。 詳細については、Mermaid のドキュメントを参照してください。 Mermaid ダイアグラムを作成するには、mermaid 言語識別子をもつコード ブロック内に Mermaid 構文を追加します。 コ

はじめに GitHub フローは、軽量のブランチ ベースのワークフローです。 GitHub フローは、開発者だけでなくすべてのユーザーに役立ちます。 たとえば、ここ GitHub では、サイト ポリシー、ドキュメント、ロードマップに GitHub フローを使用します。 前提条件 GitHub フローに従うには、GitHub アカウントとリポジトリが必要です。 アカウントの作成方法については、「GitHub でのアカウントの作成」を参照してください。リポジトリを作成する方法については、「リポジトリのクイック スタート」を参照してください。コントリビュートする既存のリポジトリを見つける方法については、「GitHub でオープンソースにコントリビュートする方法を見つける」を参照してください。 GitHub フローに従う ヒント GitHub フローの全ての手順は、GitHub Web インターフ

People with admin permissions can manage merge queues for pull requests targeting selected branches of a repository. pull request マージ キューは、Organization が所有するパブリック リポジトリ、または GitHub Enterprise Cloud を使っている Organization が所有するプライベート リポジトリで使うことができます。 詳細については、「GitHub のプラン」を参照してください。 マージ キューについて マージ キューを使用すると、pull request のマージをビジー ブランチに自動化し、互換性のない変更によってブランチが中断されないようにすることで、速度を向上できます。 マージ キューは、 [マージする前にブラン

法的情報このコンテンツの一部は、機械または AI で翻訳されている場合があります。 © 2025 GitHub, Inc.用語プライバシーStatus価格エキスパート サービスブログ

Repository collaborators and people with write access to a repository can generate and customize automated release notes for a release. 自動生成リリース ノートについて 自動生成リリース ノートは、GitHub リリースのリリース ノートを手作業で記述する代わりに、自動的に生成する機能です。 自動生成リリース ノートを使うと、リリースの内容の概要をすばやく生成できます。 自動生成されたリリース ノートには、マージされた pull request の一覧、リリースの共同作成者の一覧、完全な変更ログへのリンクが含まれます。 また、自動リリース ノートをカスタマイズし、ラベルを使ってカスタム カテゴリを作成して、含める pull request をまとめたり、特

GitHub をご利用いただきありがとうございます。 ご利用いただきありがとうございます。 GitHub にアクセスまたは使用する前に、本サービス契約の条件をよくお読みください。 これは当社とユーザーの間の非常に重要な契約であるため、当社は努めて可能な限り明確にしました。 お客様の便宜のため、最初に本条件の拘束力のない要約を、次に法的条件の全文を示しています。 概要 セクション本セクションの内容

GitHub には、通常の Git リポジトリで追跡できるファイルのサイズに制限があります。 制限を超えるファイルを追跡または削除する方法について説明します。 GitHub のサイズ制限について GitHub では、すべての Git リポジトリへの十分なストレージの提供に努めていますが、厳格な制限がファイルとリポジトリのサイズに課せられています。 ユーザーに対してパフォーマンスと信頼性を確保するため、リポジトリ全体の正常性のシグナルを積極的に監視しています。 リポジトリの正常性は、サイズ、コミットの頻度、コンテンツ、構造など、さまざまな要因が互いに及ぼす作用です。 ファイル サイズ制限 GitHub には、リポジトリで許可されるファイルのサイズに制限があります。 50 MiBより大きいファイルを追加または更新しようとすると、Gitから警告が表示されます。 変更は引き続きリポジトリに正常にプ

GitHub.com、GitHub Enterprise Server、およびいずれかの製品にアップロードする情報には、米国輸出管理規則 (EAR) を含む貿易管理規制が適用されます。 GitHub のビジョンは、開発者がどこに居住していようと、開発者コラボレーション用のグローバル プラットフォームになることです。 当社は、政府の制裁をくまなく調べて、ユーザーと顧客が法律により義務付けられる以上の影響を受けないようにする責任を真剣に受け止めています。 責任には、オープン ソース プロジェクト用も含めて、パブリック リポジトリ サービスを利用可能かつアクセス可能にして、制裁対象地域の開発者にかかわる個人的な通信をサポートすることも含まれています。 また、GitHub が制裁対象地域の開発者の仲介役となって、プラットフォームへのアクセスとグローバル オープン ソース コミュニティへの完全なアク

Projects について Projects は、作業の計画と追跡を効果的に行えるように GitHub 上の issue および pull request と統合できる、適応性のあるスプレッドシート、タスク ボード、ロード マップです。 Issue と pull request をフィルター処理、並べ替え、グループ化して複数のビューを作成、カスタマイズし、構成可能なグラフを使って作業を視覚化し、チーム固有のメタデータを追跡するカスタム フィールドを追加することができます。 Projects には、特定の手法を適用するのではなく、チームのニーズやプロセスに合わせてカスタマイズできる柔軟な機能があります。 プロジェクトを開始して作成するには、「project の作成」を参照してください。 さまざまなレイアウトの詳細については、「ビューのレイアウトを変更する」を参照してください。 最新の状態に保

GitHub Packages は、GitHub Free、GitHub Pro、organization 用 GitHub Free、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Server 3.0 以降で利用できます。 GitHub Packagesは、レガシーのリポジトリごとのプランを使っているアカウントが所有しているプライベートリポジトリでは利用できません。 また、従来のリポジトリごとのプランを使用しているアカウントは、詳細なアクセス許可をサポートするレジストリにアクセスできません。これらのアカウントはリポジトリによって課金されるためです。詳細なアクセス許可をサポートするレジストリの一覧については、「GitHub Packagesの権限について」を参照してください。 詳細については、「GitHub のプラン」を参照して

GitHub Actions ランナーに Apple コード署名証明書をインストールして、継続的インテグレーション (CI) ワークフロー内で Xcode アプリに署名する方法について説明します。 前提条件 YAMLとGitHub Actionsの構文に馴染んでいる必要があります。 詳細については、以下を参照してください: ワークフローの書き込み GitHub Actions のワークフロー構文 Xcode アプリケーションのビルドと署名について理解しておく必要があります。 詳細については、Apple の開発者向けドキュメントを参照してください。 証明書とプロビジョニングプロファイルのシークレットを作成する 署名プロセスには、証明書とプロビジョニングプロファイルの保存、それらのランナーへの転送、ランナーのキーチェーンへのインポート、およびビルドでの使用が含まれます。 ランナーで証明書とプロ

github.dev エディターについて github.dev エディターでは、完全にブラウザー内で実行される軽量の編集エクスペリエンスが導入されています。 github.dev エディターを使うと、GitHub からファイルとソース コード リポジトリに移動し、コードの変更を行ってコミットできます。 ユーザーは任意のリポジトリ、フォーク、または pull request をエディターで開くことができます。 github.dev エディターは、GitHub.com から誰でも無料で入手できます。 github.dev エディターでは、検索、構文の強調表示、ソース管理ビューなど、Visual Studio Code の多くの利点が提供されます。 Settings Sync を使用して、独自の VS Code 設定をエディターと共有することもできます。 VS Code ドキュメントの「設定の同

プロジェクトとは、テーブル、かんばんボード、ロードマップとして表示でき、GitHub データで最新の状態を維持できる、調整可能な項目のコレクションです。 プロジェクトでは、issue、pull request、メモしたアイデアを追跡できます。 issue と pull request をフィルター処理、並べ替え、グループ化して複数のビューを作成、カスタマイズし、構成可能なグラフを使って作業を視覚化し、チーム固有のメタデータを追跡するカスタム フィールドを追加することができます。 プロジェクトには、特定の手法を適用するのではなく、チームのニーズやプロセスに合わせてカスタマイズできる柔軟な機能があります。

はじめに このガイドでは、パッケージ化された複合アクションを作成して使用するために必要な基本コンポーネントについて説明します。 アクションのパッケージ化に必要なコンポーネントのガイドに焦点を当てるため、アクションのコードの機能は最小限に留めます。 アクションは「Hello World」と「Goodbye」を出力するか、カスタムの名前を指定すると「Hello [who-to-greet]」と「Goodbye」を出力します。 このアクションでは、乱数も random-number 出力変数にマップされて、goodbye.sh という名前のスクリプトが実行されます。 このプロジェクトを完了すれば、独自の複合アクションを作成し、それをワークフローでテストする方法を理解できます。 警告 ワークフローとアクションを作成するときは、攻撃者によってコードが信頼されていない入力を実行する可能性があるかどうか

はじめに GitLab CI/CD と GitHub Actions は、どちらも自動的にコードのビルド、テスト、公開、リリース、デプロイを行うワークフローを作成できます。 GitLab CI/CD と GitHub Actions は、ワークフローの設定において似ているところがあります。 ワークフローの設定ファイルはYAMLで書かれ、コードのリポジトリに保存されます。 ワークフローには1つ以上のジョブが含まれます。 ジョブには1つ以上のステップもしくは個別のコマンドが含まれます。 ジョブは、マネージドマシンまたはセルフホストマシンのいずれかで実行できます。 いくつかの違いがありますので、このガイドでは、ワークフローを GitHub Actions に移行できるようにする際の重要な違いを説明します。 ジョブ GitLab CI/CD のジョブは、GitHub Actions のジョブと非常

ヒント 特定のステータス チェックを必要とするブランチ保護規則を使う場合は、ジョブ名がすべてのワークフローで一意であることをチェックします。 複数のワークフローで同じジョブ名を使うと、ステータス チェックの結果があいまいになり、pull request のマージが禁止される可能性があります。 「ステータスチェックについて」を参照してください。 ブランチ保護ルールを作成することにより、コラボレータがリポジトリ内のブランチに変更をプッシュする前に、特定のワークフローまたは要件を適用できます。これには、プルリクエストのブランチへのマージが含まれます。 アクターをバイパス リストに追加できるのは、リポジトリが組織に属している場合のみです。 デフォルト設定では、各ブランチ保護ルールは、一致するブランチへのフォースプッシュを無効にし、一致するブランチが削除されないようにします。 必要に応じて、これらの

SSHエージェントのフォワーディング、OAuthトークンでのHTTPS、デプロイキー、マシンユーザを使ってデプロイメントスクリプトを自動化する際に、サーバー上のSSHキーを管理できます。 SSHエージェントのフォワーディング 多くの場合、特にプロジェクトの開始時には、SSHエージェントのフォワーディングが最も素早くシンプルに使える方法です。 エージェントのフォワーディングでは、ローカルの開発コンピュータで使うのと同じSSHキーを使います。 SSH エージェント転送の長所 新しいキーを生成したり追跡したりしなくていい。 キーの管理は不要。ユーザはローカルと同じ権限をサーバーでも持つ。 サーバーにキーは保存されないので、サーバーが侵害を受けた場合でも、侵害されたキーを追跡して削除する必要はない。 SSH エージェント転送の短所 ユーザーは、デプロイに SSH 接続する必要があります。自動デプロ