Embedded Files
GitHub Skills
GitHub Skills
Learn how to use GitHub with interactive courses designed for beginners and experts.
参考
参考
GitHub初学者向け無料チュートリアル「GitHub Skills」をやってみた
First day on GitHub
First day on GitHub
Introduction to GitHub
Introduction to GitHub
Get started using GitHub in less than an hour.
リポジトリ
リポジトリは、ファイルとフォルダーを含むプロジェクトです。リポジトリは、ファイルとフォルダーのバージョンを追跡します。
ブランチ
ブランチはリポジトリの並列バージョンです。デフォルトでは、リポジトリには名前付きのブランチが 1 つありmain、それが最終的なブランチとみなされます。main追加のブランチを作成すると、メイン プロジェクトを中断することなくリポジトリのブランチをコピーし、安全に変更を加えることができます。多くの人はブランチを使用して、プロジェクトの他の部分に影響を与えずに特定の機能に取り組んでいます。
ブランチを使用すると、作業をブランチから分離できますmain。言い換えれば、あなたが貢献している間、全員の作業は安全です。
プロファイルの README
プロファイル README は、基本的に GitHub プロファイルの「自己紹介」セクションであり、ここで自分自身に関する情報を GitHub.com のコミュニティと共有できます。GitHub では、プロフィール ページの上部にプロフィールの README が表示されます。
コミット
コミットは、プロジェクト内のファイルとフォルダーに対する一連の変更です。コミットはブランチ内に存在します。
プルリクエスト
コラボレーションはプル リクエストで発生します。プル リクエストにより、ブランチの変更が他の人に表示され、ブランチに対する追加の変更を承認、拒否、または提案できるようになります。並べて比較すると、このプル リクエストはブランチに加えた変更を保持し、それらをプロジェクトmainブランチに適用することを提案します。
マージ
マージにより、プル リクエストとブランチに変更が追加されますmain。
アクティビティ: プル リクエストをマージする
「プルリクエストをマージ」をクリックします。
[マージの確認]をクリックします。
ブランチがマージされると、ブランチは必要なくなります。このブランチを削除するには、[ブランチの削除]をクリックします。
Communicate using Markdown
Communicate using Markdown
Organize ideas and collaborate using Markdown, a lightweight language for text formatting.
ステップ 1: ヘッダーを追加する
マークダウン
Markdown は、 GitHub 上で通信するための軽量の構文です。テキストの書式を設定して、見出し、リスト、太字、斜体、表、その他多くのスタイルを追加できます。GitHub のほとんどの場所で Markdown を使用できます。
問題、プルリクエスト、ディスカッションに対するコメント
拡張子が.mdまたは のファイル.markdown
Gistでのテキストのスニペットの共有
ヘッダー
ヘッダーは、セクションの先頭にある大きなテキストです。サイズは6種類あります。
＞プル リクエストタブを開きます。
＞[新しいプル リクエスト]をクリックし、比較するブランチを選択し、base: mainをクリックしますcompare: start-markdown。
＞[プル リクエストの作成]をクリックします。
>このプル リクエストでは、[変更されたファイル]タブに移動します。空のファイルを作成しましたindex.md。
ヘッダー例
# This is an `<h1>` header, which is the largest
## This is an `<h2>` header
###### This is an `<h6>` header, which is the smallest
#の数をh～と合わせる。
ステップ 2: 画像を追加する
例
・先頭に!が必要。
・[]内が代替テキスト。
・()内が画像。
ステップ 3: コード例を追加する
コード ブロックに加えて、JavaScript やコマンド ライン テキストなど、一部のコード ブロックは言語に応じて異なる方法でレンダリングする必要があります。
Example 1
```
$ git init
Initialized empty Git repository in /Users/skills/Projects/recipe-repository/.git/
```
How it looks
$ git init
Initialized empty Git repository in /Users/skills/Projects/recipe-repository/.git/
Example 2
``` javascript
var myVar = "Hello, world!";
```
How it looks
var myVar = "Hello, world!";
ステップ 4: タスクリストを作成する
タスクリスト
タスク リストでは、チェックを入れるためのチェックボックスが作成されます。これらは、問題やプル リクエストの追跡に非常に役立ちます。課題またはプル リクエストの本文にタスク リストを含めると、課題リストに進行状況インジケーターが表示されます。タスク リストの構文は非常に特殊です。必要な場合は必ずスペースを含めてください。そうしないとレンダリングされません。
例
- [x] List syntax is required
- [x] This item is complete
- [ ] This item is not complete
タスク リストは構文 - [ ] で始まり、次にタスク リスト項目。
2023/09/13
GitHub ページ
GitHub ページ
GitHub Pages を使用して、GitHub リポジトリからサイトまたはブログを作成します。
GitHub Pages
GitHub Pagesを使用すると、プロジェクトのブログ、ドキュメント、履歴書、ポートフォリオ、その他の任意の静的コンテンツをホストできます。GitHub リポジトリは簡単に独自の Web サイトにすることができます。
ステップ 1: GitHub ページを有効にする
リポジトリ名の下にある[設定]をクリックします。
「コードと自動化」セクションの「ページ」をクリックします。
[ソース]ドロップダウン メニューから [ブランチからデプロイ] が選択されていることを確認し、[ブランチ]ドロップダウン メニューmainから選択します。
「保存」ボタンをクリックします。
1 分ほど待ってから、このページ (指示に従っているページ) を更新します。
ステップ 2: サイトを構成する
_config.ymlブランチ内のファイルを参照しますmy-pages。
右上隅でファイルエディタを開きます。
セットをminimatheme:に追加して、ファイルに次のように 表示されるようにします。_config.yml
theme: minima
title:(オプション) 、 、などの他の構成変数を変更してauthor:、description:サイトをさらにカスタマイズできます。
[プル リクエスト]タブをクリックし、 [新しいプル リクエスト]をクリックし、 [設定base: main] をクリックし、 [プル リクエスト] をクリックしますcompare:my-pages。
ステップ 3: ホームページをカスタマイズする
my-pagesブランチ内のファイルを参照します。index.md
ステップ 4: ブログ投稿を作成する
GitHub Pages は Jekyll を使用します。Jekyll では、特別な名前のファイルとフロントマターを使用してブログを作成できます。ファイルには という名前を付ける必要があります_posts/YYYY-MM-DD-title.md。title前付にとも含める必要がありますdate。
フロントマター
Jekyll ファイルが使用する構文は、YAML フロントマッターと呼ばれます。これはファイルの先頭にあり、次のようになります。
---
title: "Welcome to my blog"
date: 2019-01-20
---
フロントマターの構成の詳細については、Jekyll フロントマターのドキュメントを参照してください。
ステップ 5: プル リクエストをマージする
変更を から にマージしmy-pagesますmain。ステップ 2 でプル リクエストを作成した場合は、その PR を開いて [プル リクエストをマージ]をクリックするだけです。
(オプション) ブランチを削除しますmy-pages。
First week on GitHub
First week on GitHub
2023/09/14
プルリクエストを確認する
プルリクエストを確認する
GitHub でコラボレーションして共同作業します。
ステップ 1: プル リクエストを開く
プルリクエスト
コラボレーションはプル リクエストで発生します。プル リクエストは、ブランチ内の変更を他の人に示します。このプル リクエストは、ブランチに加えた変更を保持し、それらをブランチに適用することを提案しますmain。
ステップ 2: 自分自身を割り当てる
プル リクエストのレビュー
プル リクエストのレビューは、他のコントリビューターの変更を調べてフィードバックを与える機会です。プロジェクトがどのように機能するか、他の人がどのように問題を解決しているかについて詳しく学ぶ素晴らしい機会です。
レビューを得る最善の方法は、レビューを依頼することです。GitHub では、誰かをレビュー担当者または担当者として割り当てることで、プル リクエストのレビューを依頼できます。レビューの準備ができていない場合は、代わりにドラフト プル リクエストを作成することを検討してください。
作成したばかりのプル リクエストを開きます。
画面右側の[担当者] (Assignees)に自分自身を追加します。
ステップ 3: レビューを残す
プル リクエストをレビューする場合:
意図された変更を理解するために、プル リクエストのタイトルと本文、および関連する問題を確認してください。
プロジェクト全体のコンテキストで、提案されたコードの比較であるdiff(https://docs.github.com/en/get-started/quickstart/github-glossary#diff)を確認します。
ほとんどの場合、提案された変更を試してください。実際の変更が意図と一致するかどうかを確認します。変更を確認する方法については、リポジトリの貢献ガイドを参照してください。
レビューのコメントでは次のようになります。
・潜在的な問題、リスク、制限を特定します。
・変更や改善を提案します。
・プル リクエストでは考慮されていない今後の変更についての認識を共有します。
・質問をして共通の理解を確認します。
・著者がうまく行ったこと、そして今後も続けるべきことを強調します。
・最も重要なフィードバックを優先します。
・簡潔にして意味のある詳細を提供してください。
・プルリクエストの作成者には親切と共感を持って接してください。
承認や変更のリクエストがまだ必要でない場合は、コメントの使用を検討してください。承認により、プル リクエストをマージしても安全であると確信していることが作成者に通知されます。変更をリクエストすると、プル リクエストをマージする準備ができていないと思われることが作成者に伝わります。
アクティビティ: レビューを残す
プル リクエストで、[変更されたファイル]（File changed）をクリックします。
[変更の確認]（Review changes）をクリックします。
プル リクエストに関する最初の考えをコメントに追加します。
コメントを選択します。自分のプル リクエストを承認したり、変更をリクエストしたりすることはできません。
[レビューを送信]（Submit review）をクリックします。
ステップ 4: 変更を提案する
変更の提案とは何ですか? : この機能を使用すると、作成者がボタンを押すだけでコミットできるプル リクエストへの変更を推奨できます。
アクティビティ: 変更を提案する
プル リクエストで、[変更されたファイル]( Files changed)をクリックします。
変更を見つけますindex.html。
ページの左側にある行番号の横にカーソルを置きます。
青いプラスアイコンをクリックします。
コメントフォームが表示されたら、「提案を追加」(Add a suggestion)ボタンをクリックします。
提案を編集します。
[単一のコメントを追加]( Add a single comment)をクリックします。
ステップ 5: 提案された変更を適用する
アクティビティ: 提案された変更を適用する
リポジトリ名の下にある [プル リクエスト]をクリックします。
プル リクエストのリストで、提案された変更を適用するプル リクエストをクリックします。
適用したい最初の提案された変更に移動します。
「提案をコミット(Commit suggestion)」をクリックします。
コミットメッセージを入力します。
「変更をコミット(Commit changes)」をクリックします。
進めなくなった。
2023/09/15
マージ競合を解決する(Resolve merge conflicts)
マージ競合を解決する(Resolve merge conflicts)
マージ競合は、2 人のユーザーが GitHub 上の同じファイルに変更を加えたときに発生します。これは、他のユーザーと作業しているときによく発生します。相違点を解決するにはある程度の議論が必要になるかもしれませんが、マージ競合を恐れる必要はありません。このコースでは、チームが構築を継続できるように、最適なマージ競合解決策を見つける手順を説明します。
ステップ 1: プル リクエストを作成する
マージ競合とは何ですか? : 2 つの異なるブランチ上の同じファイルの同じ部分に変更が加えられた場合、マージ競合が発生します。通常、競合についてはプル リクエストでわかります。まず、競合を作成してみましょう。
ステップ 2: マージ競合を解決する
Git に必要なのは、人間が競合を解決する(https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line)方法を決定することだけです。場合によっては、マージ競合を解決する最善の方法は、両方のブランチのコンテンツ、またはどちらにも存在しないコンテンツを追加することです。このため、Git には人間がコードを調べて適切な修正を行う必要があります。
アクティビティ: マージ競合を解決する
ページの下部にある [このブランチには解決する必要がある競合があります] で、[競合の解決]( Resolve conflicts)ボタンをクリックします。
<<<<<<< my-resumeで始まり で終わる強調表示されたセクションを探します>>>>>>> main。これらのマーカーは、競合しているコンテンツを示すために Git によって追加されます。
次に、次の行を削除して、マージ競合マーカーを削除します。
<<<<<<< my-resume
=======
>>>>>>> main
マージ競合マーカーを削除したら、[解決済みとしてマーク]( Mark as resolved)をクリックします。
最後に、上に表示される「マージをコミット」をクリックします。
ステップ 3: 独自の競合を作成する
競合を解決しても、プル リクエストは GitHub に自動的にマージされません。代わりに、競合の解決策がマージ コミットに保存され、ユーザーとチームが作業を続行できるようになります。競合を解決するために、GitHub はいわゆる逆マージを実行します。これは、ブランチからの変更がブランチmainにマージされたことを意味しますmy-resume。逆マージでは、my-resumeブランチのみが更新されます。これにより、ブランチを にマージする前に、ブランチ上で解決された変更をテストできますmain。
リリースベースのワークフローを作成する（Release-based workflow）
リリースベースのワークフローを作成する（Release-based workflow）
GitHub フロー（https://guides.github.com/introduction/flow/）の基盤に構築されたリリース ベースのワークフローを作成します。チームがリリースベースのワークフローを使用している場合、GitHub を使用すると、プロジェクトのデプロイ可能なイテレーションとの共同作業が簡単になり、パッケージ化し、より幅広いユーザーがダウンロードして使用できるようになります。
GitHub リリースを使用すると、チームはプロジェクト履歴の特定の時点に基づいてソフトウェアをパッケージ化し、ユーザーに提供できます。
ステップ 1: ベータ版リリースを作成する
GitHub の流れ
GitHubフローは、定期的にデプロイするプロジェクト向けの軽量のブランチベースのワークフローです。
プロジェクトによっては、継続的にデプロイすることで、より頻繁にデプロイする場合があります。メインに新しいコミットがあるたびに「リリース」が発生する可能性があります。
ただし、一部のプロジェクトは、バージョンとリリースの異なる構造に依存しています。
バージョン
バージョンは、オペレーティング システム、アプリ、依存関係など、更新されたソフトウェアのさまざまな反復です。一般的な例は、「Windows 8.1」から「Windows 10」、または「macOS High Sierra」から「macOS Mojave」です。
開発者はコードを更新し、プロジェクトでバグのテストを実行します。その間、開発者は新しいコードやバグから保護するために特定のセキュリティを設定する場合があります。その後、テストされたコードは運用準備が整います。Teams はコードのバージョンを作成し、エンド ユーザーがインストールできるようにリリースします。
アクティビティ: 現在のコードベースのリリースを作成する
GitHub リリースは特定のコミットを指します。リリースには、Markdown ファイル内のリリース ノートと添付バイナリを含めることができます。
「新しいリリースの作成」をクリックします。
[タグのバージョン] フィールドに数値を指定します。この場合は、v0.9を使用します。Target をmainとして保持します。
これはベータ版であるため、「プレリリースとして設定」の横にあるチェックボックスを選択します。
ステップ 2: リリース ブランチに新機能を追加する
リリース管理
将来のリリースに備えて、タスクや機能以外にも整理する必要があります。チームに明確なワークフローを作成し、作業が整理された状態に保たれるようにすることが重要です。
リリースを管理するにはいくつかの戦略があります。productionチームによっては、 、dev、 などの存続期間の長いブランチを使用する場合がありますmain。一部のチームは、メイン ブランチからリリースして、単純な機能ブランチを使用しています。
ある戦略が他の戦略より優れているということはありません。ブランチについては意図的に考慮し、可能な限り存続期間の長いブランチを減らすことを常にお勧めします。
保護されたブランチ
ブランチと同様にmain、リリース ブランチも保護できます。これは、ブランチを強制プッシュや誤った削除から保護できることを意味します。これはこのリポジトリですでに構成されています。
アクティビティ: 更新base.css
release-v1.0 をベース ブランチ、新しいブランチを比較ブランチとしてプル リクエストを開きます。
新機能をリリースブランチにマージする
リリースがあっても、GitHub フローは依然としてチームと協力するための重要な戦略です。機能の追加やバグ修正を迅速に行うために、有効期間の短いブランチを使用することをお勧めします。
できるだけ早くリリース プル リクエストをオープンできるように、この機能プル リクエストをマージします。
ステップ 3: リリース プル リクエストを開く
mainブランチをリリース
できるだけ早くリリース ブランチとメインの間でプル リクエストをオープンする必要があります。長時間開いていても大丈夫です。
一般に、プル リクエストの説明には次の内容を含めることができます。
・プル リクエストで対処されている問題への参照(https://docs.github.com/en/articles/basic-writing-and-formatting-syntax/#mentioning-people-and-teams)
・プル リクエストで提案された変更の説明。
・提案された変更のレビューを担当する個人またはチームの@メンション。(https://docs.github.com/en/articles/basic-writing-and-formatting-syntax/#mentioning-people-and-teams)
このプル リクエストの作成を迅速化するために、プル リクエスト テンプレートをリポジトリに追加しました。プル リクエストを作成すると、デフォルトのテキストが自動的に表示されます。これは、必要な情報をすべて特定して入力するのに役立ちます。テンプレートのコンテンツを使用したくない場合は、プル リクエストからテキストを削除し、プル リクエストのメッセージに置き換えます。
アクティビティ: リリース プル リクエストを開く
release-v1.0ブランチとブランチを比較する新しいプル リクエストを作成してみましょうmain。
とを使用して新しいプル リクエストを開きます。base: maincompare: release-v1.0
プル リクエストのタイトルが「リリース v1.0」であることを確認してください。
詳細なプル リクエスト本文を含めます。例を以下に示します。
## Description:
- Changed page background color to black.
- Changed game text color to green.
[プル リクエストの作成]をクリックします。
ステップ 4: リリースノートを生成してマージする
自動的に生成されるリリースノート
自動生成されたリリース ノートは、 GitHub リリースのリリース ノートを手動で作成する代わりに自動化された手段を提供します。自動的に生成されるリリース ノートを使用すると、リリースの内容の概要を迅速に生成できます。自動的に生成されるリリース ノートには、マージされたプル リクエストのリスト、リリースへの貢献者のリスト、および完全な変更ログへのリンクが含まれます。リリース ノートが生成されたら、カスタマイズすることもできます。
アクティビティ: リリースノートを作成する
別のタブで、このリポジトリの 「リリース」ページに移動します。
「新しいリリースのドラフト」ボタンをクリックします。
[タグのバージョン] フィールドに、 を指定しますv1.0.0。
タグ ドロップダウンの右側にある[ターゲット]ドロップダウンをクリックしてrelease-v1.0ブランチを選択します。
説明テキスト ボックスの右上にある [リリース ノートの生成]をクリックします。
テキスト ボックス内のリリース ノートを確認し、必要に応じて内容をカスタマイズします。
これは、リリース ブランチがマージされた後にタグを作成するブランチであるため、ターゲットブランチを に設定し直します。Main
次のステップでこのリリースを公開するので、「ドラフトを保存」をクリックします。
ステップ 5: リリースを完了する
リリースを完成させる
そのリリースで何が表示されるかについての情報を認識しておくことが重要です。プレリリースでは、バージョンとコミット メッセージが表示されます。
セマンティック バージョニング
セマンティック バージョニングは、互換性を指定するための正式な規則です。メジャー バージョン、マイナー バージョン、およびパッチの 3 つの部分からなるバージョン番号を使用します。バージョン番号は、基礎となるコードと変更内容に関する意味を伝えます。たとえば、バージョン管理は次のように処理できます。
詳細については、セマンティック バージョニングに関するこの記事をご覧ください。
リリースを完了する
別のタブで、このリポジトリの 「リリース」ページに移動します。
ドラフトリリースの横にある「編集」ボタンをクリックします。
[リリースの公開] (Publish release)をクリックします。
ステップ 6: ホットフィックスをリリースにコミットする
ブランチを削除していないことに気づきましたか? それは意図的です。
リリースでは時々間違いが発生する可能性があるため、同じブランチ上でそれらを修正できるようにしたいと考えます。
あなたの釈放が完了したので、告白しなければなりません。最近のアップデートのどこかで間違いを犯し、バグを導入してしまいました。テキストの色を緑色に変更する代わりに、ゲームの背景全体を変更しました。
「ホットフィックス」、つまりソフトウェアのバグに対処するための簡単な修正は、開発の通常の部分です。多くの場合、「バグ修正」という説明だけが記載されているアプリケーションの更新を目にすることがあります。
バージョンをリリースした後にバグが発生した場合は、それに対処する必要があります。開始できるように、hotfix-v1.0.1とブランチがすでに作成されています。fix-game-background
プル リクエストを作成してマージすることでホットフィックスを送信します。
ステップ 7: リリース v1.0.1 を作成する
最終リリース
ソース コードを更新しましたが、ユーザーは最新の変更内容に簡単にアクセスできません。新しいリリースを準備し、そのリリースを必要なチャネルに配布します。
リリース v1.0.1 を作成する
説明的なプル リクエストと自動生成されたリリース ノートを使用すると、リリース ドラフトの作業に多くの時間を費やす必要がなくなります。以下の手順に従って、新しいリリースを作成し、リリース ノートを生成し、公開します。
別のタブで、このリポジトリの 「リリース」ページに移動します。
「新しいリリースのドラフト」ボタンをクリックします。
ターゲットブランチをmainに設定します。
説明テキスト ボックスの右上にある [リリース ノートの生成]をクリックします。
テキスト ボックス内のリリース ノートを確認し、必要に応じて内容をカスタマイズします。
[リリースの公開]をクリックします。
2023/09/16
GitHub リポジトリで点と点を結ぶ（Connect the dots）
GitHub リポジトリで点と点を結ぶ（Connect the dots）
このコースでは、次のことを行います。
1.重複した問題を解決します。
2.履歴からコミットを見つけます。
3.壊れたサイドバーを修正します。
ステップ 1: 重複する問題を解決する
GitHub には、GitHub 上の他の情報を参照するのに役立つ特別な機能があります。たとえば、別の課題やプル リクエストを番号で参照すると、その番号がハイパーリンクされます。同時に、リンクされた課題またはプル リクエスト内に相互参照が作成されます。この双方向の参照は、GitHub 全体の情報の関係を追跡するのに役立ちます。
複数のチームメンバーが協力すると、問題が重複する場合があります。上の例では、新しい問題は#8346以前の問題の複製です#8249。相互参照機能を使用すると、これらの重複を追跡し、必要に応じて問題を解決できます。
参照の作成
別の問題にリンクすると、GitHub 内の参照が自動的に作成されます。実際、完全なリンクを含める必要さえありません。#5コメント内に入力すると、リクエスト番号 5 を発行またはプル リクエストへのリンクに変わります。
クロスリンクを作成する場合は、シンボルを入力した直後に、問題またはプル リクエストのタイトルの入力を開始します#。GitHub は、適切な場所にリンクする問題やプル リクエストを提案します。さらに詳しく知りたい場合は、「自動リンクされた参照と URL」の記事をご覧ください。
https://docs.github.com/en/articles/autolinked-references-and-urls
アクティビティ: 相互リンクされた問題を見つけて閉じる
>issue #1 (Welcome) に移動します
#2の間違い
コメントとして「#2 の重複」と入力し、問題 #1 を閉じます。
右のコメントではなくClose with commentをクリック。（右のコメントだとエラー）
ステップ 2: 履歴でコミットを見つける
バージョン管理の重要な部分は、過去を調べる機能です。を使用し、コミットの背後にあるストーリーを見つけることで、コードのせいで人のせいにするgit blame以上のことができるようになります。コミットが行われた理由に関するストーリーを確認できます。関連するプルリクエストとは何ですか? プルリクエストを承認したのは誰ですか? マージ前にそのコミットに対してどのようなテストが実行されましたか?
歴史の中で何かを見つける明白な理由は、歴史について知るためです。イシューとプルリクエストでは、最小限のものだけではなく、より完全な歴史のストーリーが見られます。
git blameとは何ですか?
git blameは、ファイルの各行を最後に変更したリビジョンと作成者を示す Git の機能です。この方法で、誰がいつコミットしたか、さらにはなぜコミットしたかなどの情報を見つけることができます。誰がファイルに特定の変更を加えたかがわからない場合は、git blameを使用して調べることができます。gitblame はかなり非難的に聞こえるかもしれませんが、これは決定に関するコンテキストを理解するために使用できます。
セキュア ハッシュ アルゴリズム (SHA) とは何ですか?
SHA は特定のオブジェクトへの参照です。この場合、それはコミットへの参照です。GitHub では、特定のコミットを参照して、導入された変更、誰によって、そしてそれらがプル リクエストの一部であるかどうかを確認できます。
アクティビティ: 履歴でコミットを見つける
ファイルの上部にある「Blame」をクリックすると、最新のリビジョンの詳細が表示されます。
コミットメッセージをクリックすると、add sidebar to documentationコミットの詳細が表示されます
SHA の最初の 7 文字 (commitの後にリストされる 40 文字の 16 進文字列の最初の 7 文字) をコピーします。
＞SHA をコメント テキストとして追加し、[コメント] ボタンをクリックして、issue #2 にコメントします。
issue #3の間違い。
ステップ 3: 壊れたサイドバーを修正する
すでに見たように、Issue やプル リクエストでの会話は他の作業を参照できますが、コンテキストの量はクロスリンクよりもはるかに多くなります。Git はバージョン管理であることを忘れないでください。たとえば、最後のステップで見つけたコミットには、次のようなさらに多くの情報が関連付けられています。
・コミットを行った人。
・他にどのような変更が含まれているか。
・コミットが行われたとき。
・コミットがどのプル リクエストに含まれていたか。
コミットからのプルリクエストの検索
GitHub 上のコミットを見ると、多くの情報を確認できます。このビューから、コミットが作成されたプル リクエストへのリンクも見つけることができます。これは次のステップで使用します。
アクティビティ: 壊れたサイドバーを修正する
メイン ブランチでファイルを編集しますdocs/_sidebar.md。
(doc-references__.md)4 行目の参照のスペルを に変更して修正します(doc-references.md)。
このコミットの新しいブランチを選択または作成しfix-sidebar、プル リクエストを開始します。
GitHub コードスペースと Visual Studio Code を使用したコード作成（Code with Codespaces）
GitHub コードスペースと Visual Studio Code を使用したコード作成（Code with Codespaces）
GitHub Codespaces は、クラウドでホストされる開発環境です。
ステップ 1: 最初のコードスペースを作成してコードをプッシュする
ソフトウェア開発にコードスペースを使用することの何が重要ですか? コードスペースは、クラウドでホストされる開発環境です。構成ファイルをリポジトリ (コードとしての構成とも呼ばれます) にコミットすることで、GitHub コードスペース用にプロジェクトをカスタマイズできます。これにより、プロジェクトのすべてのユーザーに対して反復可能なコードスペース構成が作成されます。作成した各コードスペースは、仮想マシン上で実行される Docker コンテナ内の GitHub によってホストされます。必要なリソースに応じて、使用するマシンのタイプを選択できます。
GitHub は、開発チームがコードスペースをカスタマイズして構成とパフォーマンスのピーク ニーズに到達するのに役立つさまざまな機能を提供します。たとえば、次のことができます。
・リポジトリからコードスペースを作成します。
・コードをコードスペースからリポジトリにプッシュします。
・VS Code を使用してコードを開発します。
・カスタム イメージを使用してコードスペースをカスタマイズします。
・コードスペースを管理します。
GitHub コードスペースを使用して開発を開始するには、テンプレート、またはリポジトリ内の任意のブランチまたはコミットからコードスペースを作成できます。テンプレートからコードスペースを作成する場合、空のテンプレートから開始することも、行っている作業に適したテンプレートを選択することもできます。
アクティビティ: コードスペースを開始する
ページの中央にある緑色の「コード」ボタンをクリックします。
表示されるボックスで「コードスペース」タブを選択し、 「メインにコードスペースを作成」（Create codespace on main）ボタンをクリックします。
コードスペースが自動的に起動するまで、約 2 分間待ちます。 注: これはバックグラウンドで起動する仮想マシンです。
コードスペースが実行されていることを確認します。ブラウザには VS Code の Web ベースのエディタが含まれており、次のようなターミナルが存在する必要があります。
アクティビティ: コードスペースからリポジトリにコードをプッシュします。
VS Code エクスプローラー ウィンドウのコードスペース内からindex.htmlファイルを選択します。
h1ヘッダーを以下に置き換えます。
<h1>Hello from the codespace!</h1>
ファイルは自動保存されます。
VS Code ターミナルを使用して、次のコミット メッセージを入力してファイルの変更をコミットします。
git commit -a -m "Adding hello from the codespace!"
入力したらエンターキーを押す。
変更をリポジトリにプッシュして戻します。VS Code ターミナルから、次のように入力します。
git push
コードがリポジトリにプッシュされました。
リポジトリのホームページに戻り、 を表示して、index.html新しいコードがリポジトリにプッシュされたことを確認します。
ステップ 2: カスタム イメージをコードスペースに追加します。
リポジトリの開発コンテナを構成すると、そのリポジトリ用に作成されたコードスペースによって、特定のプロジェクトで作業するために必要なすべてのツールとランタイムを備えた、カスタマイズされた開発環境が提供されます。
開発コンテナとは何ですか?
開発コンテナ (dev コンテナ) は、完全な機能を備えた開発環境を提供するように特別に構成された Docker コンテナです。コードスペースで作業するときは常に、仮想マシン上の開発コンテナを使用することになります。
開発コンテナ ファイルは、コードスペース、VS コード設定、カスタム コードの実行、ポートの転送などを実行するデフォルト イメージをカスタマイズできる JSON ファイルです。
devcontainer.jsonファイルを追加し、カスタム イメージを追加しましょう。
アクティビティ: .devcontainer.json ファイルを追加してコードスペースをカスタマイズする
リポジトリの[コード]タブに戻り、 [ファイルの追加] ドロップダウン ボタンをクリックして、 をクリックしますCreate new file。
空のテキスト フィールド プロンプトに次の内容を入力または貼り付けて、ファイルに名前を付けます。
.devcontainer/devcontainer.json
新しい.devcontainer/devcontainer.jsonファイルの本文に、次の内容を追加します。
{
// Name this configuration
"name": "Codespace for Skills!",
// Use the base codespace image
"image": "mcr.microsoft.com/vscode/devcontainers/universal:latest",
"remoteUser": "codespace",
"overrideCommand": false
}
「変更をコミット」をクリックし、 「変更をブランチに直接コミット」mainを選択します。
リポジトリの「コード」タブに戻って、新しいコードスペースを作成します。
ページの中央にある緑色の「コード」ボタンをクリックします。
表示されるボックスの「コードスペース」タブをクリックします。
「メインにコードスペースを作成」ボタンをクリックするか、+タブ上の記号をクリックします。これにより、メイン ブランチに新しいコードスペースが作成されます。(ここにリストされている他のコードスペースに注目してください。)
以前と同様に、新しいコードスペースが実行されていることを確認します。
使用されているイメージは、GitHub コードスペースに提供されているデフォルトのイメージであることに注意してください。これには、Python、Node.js、Docker などのランタイムとツールが含まれています。完全なリストはこちらでご覧ください: https://aka.ms/ghcs-default-image。開発チームは、必要な前提条件がインストールされている任意のカスタム イメージを使用できます。詳細については、「コードスペース イメージ」を参照してください。
ステップ 3: コードスペースをカスタマイズします。
ステップ4の間違い。
VS コード拡張機能の追加、機能の追加、ホスト要件の設定などにより、コードスペースをカスタマイズできます。
ファイル内のいくつかの設定をカスタマイズしてみましょう.devcontainer.json。
⌨️ アクティビティ:devcontainerファイルにカスタマイズを追加します。
ファイルに移動します.devcontainer/devcontainer.json。
ファイル本体の最後の . の前に次のカスタマイズを追加します}。
,
// Add the IDs of extensions you want installed when the container is created.
"customizations": {
"vscode": {
"extensions": [
"GitHub.copilot"
]
},
"codespaces": {
"openFiles": [
"codespace.md"
]
}
}
「変更をコミット」をクリックし、 「変更をブランチに直接コミット」mainを選択します。
リポジトリのランディング ページに移動して、新しいコードスペースを作成します。
ページの中央にある「コード」ボタンをクリックします。
表示されるボックスの「コードスペース」タブをクリックします。
「メインにコードスペースを作成」ボタンをクリックします。
このボタンがないので＋ボタンでいいと思う。
ファイルcodespace.mdは VS Code エディターに表示されるはずです。
拡張copilot機能は VS Code 拡張機能のリストに表示されます。
これにより、VS Code 拡張機能が追加され、コードスペースの起動時にファイルが開きます。
アクティビティ: コードスペースの作成時にコードを実行する
ファイルを編集します.devcontainer/devcontainer.json。
次の postCreateCommand をファイル本体の最後の } の前に追加します。
,
"postCreateCommand": "echo '# Writing code upon codespace creation!' >> codespace.md"
「変更をコミット」をクリックし、 「変更をブランチに直接コミット」mainを選択します。
リポジトリのランディング ページに移動して、新しいコードスペースを作成します。
新しいコードスペースが作れないが、ステップは先に進んだ。
ステップ 4: コードスペースをパーソナライズします。
開発環境を使用する場合、設定とツールを好みやワークフローに合わせてカスタマイズすることは重要な手順です。 GitHub Codespaces では、コードスペースをパーソナライズする 2 つの主な方法、VS Code との設定同期、およびドットファイル（Dotfile）を提供します。
ドットファイル（Dotfile）とは何ですか?
ドットファイルは、. で始まる Unix 系システム上のファイルとフォルダーです。システム上のアプリケーションとシェルの構成を制御します。ドットファイルは GitHub 上のリポジトリに保存して管理できます。
リポジトリのランディング ページから開始します。
任意のページの右上隅でプロフィール写真をクリックし、[設定]をクリックします。
サイドバーの「コード、計画、自動化」セクションで、 「コードスペース」をクリックします。
[ Dotfiles ]で、 [ Automatically install dotfiles (ドットファイルを自動的にインストールする)]を選択すると、GitHub Codespaces によって、作成するすべての新しいコードスペースにドットファイルが自動的にインストールされます。
[リポジトリの選択]をクリックし、ドットファイルのインストール元のリポジトリとして現在のスキル作業リポジトリ（skills-code-with-codespaces）を選択します。
アクティビティ: をdotfileリポジトリに追加し、コードスペースを実行します
もう一度コードスペースを作成をすると、今度はなぜか作成できた。さっきは制限されたのに。
VS Code エクスプローラー ウィンドウのコードスペース内から、新しいファイルを作成しますsetup.sh。
新しいファイルを作成するには、エクスプローラーで右クリックをして新しいファイルを選択。
ファイル内に次のコードを追加します。
#!/bin/bash
sudo apt-get update
sudo apt-get install sl
ファイルの変更をコミットします。VS Code ターミナルから次のように入力します。
git add setup.sh --chmod=+x
git commit -m "Adding setup.sh from the codespace!"
変更をリポジトリにプッシュして戻します。VS Code ターミナルから、次のように入力します。
git push
またコードスペースを作成。
setup.shファイルが VS Code エディターに存在することを確認します。
VS Code ターミナルから、次のように入力または貼り付けます。
/usr/games/slショーをお楽しみください!
GitHub Copilot を使用したコード作成（Code with Copilot）
GitHub Copilot を使用したコード作成（Code with Copilot）
GitHub Copilot は、オートコンプリート スタイルの提案を提供することでコーディングを支援します。GitHub Copilot の仕組みと、GitHub Copilot を使用する際の考慮事項について学習できます。GitHub Copilot は、編集中のファイルおよび関連ファイルのコンテキストを分析し、テキスト エディター内から提案を提供します。GitHub Copilot は、OpenAI によって作成された新しい AI システムである OpenAI Codex を利用しています。
ステップ 1: VS Code for Copilot でコードスペースを活用する
Copilot は、VS Code、Visual Studio、JetBrains IDE、Neovim などの多くのコード エディターで動作します。
さらに、GitHub Copilot は、パブリック リポジトリにあるすべての言語でトレーニングされています。言語ごとに、受け取る提案の質は、その言語のトレーニング データの量と多様性に依存する場合があります。
コードスペース内で Copilot を使用すると、GitHub の共同コーディングツールスイートを簡単に起動して実行できることがわかります。
アクティビティ: コードスペース内で Copilot を有効にする
リポジトリの[コード]タブに戻り、 [ファイルの追加] ドロップダウン ボタンをクリックして、 をクリックしますCreate new file。
空のテキスト フィールド プロンプトに次の内容を入力または貼り付けて、ファイルに名前を付けます。
.devcontainer/devcontainer.json
新しい.devcontainer/devcontainer.jsonファイルの本文に、次の内容を追加します。
{
// Name this configuration
"name": "Codespace for Skills!",
"customizations": {
"vscode": {
"extensions": [
"GitHub.copilot"
]
}
}
}
[ブランチに直接コミット]mainオプションを選択し、[新しいファイルをコミット]ボタンをクリックします。
画面の左上にある「コード」タブをクリックして、リポジトリのホームページに戻ります。
ページの中央にある「コード」ボタンをクリックします。
表示されるボックスの「コードスペース」タブをクリックします。
「メインにコードスペースを作成」ボタンをクリックします。
コードスペースが自動的に起動するまで、約 2 分間待ちます。コードスペースが実行されていることを確認します。ブラウザには VS Code の Web ベースのエディタが含まれており、次のようなターミナルが存在する必要があります。
拡張copilot機能は VS Code 拡張機能のリストに表示されます。拡張機能のサイドバー タブをクリックします。次の内容が表示されるはずです。
下の画像が出てCopilotが使えない。
任意のページで、右上隅にあるプロファイルの画像をクリックし、次に[Tri Copilot]をクリックします。
30日間の無料トライアル。試用期間終了後は有料サブスクリプションに変換されます。
クレジットカードかPayPalアカウントが必要。
これでCopilotが試せるようになる。
アカウント設定の [請求とプラン] に移動して、GitHub Copilot サブスクリプションを管理します。
プロフィールの設定/請求とプラン/プラント使い方でトライアルをキャンセルできる。
ステップ 2: Javascript ファイルで AI コードの提案を確認する!
アクティビティ: Javascript ファイルを追加してコードの作成を開始します
VS Code エクスプローラー ウィンドウのコードスペース内から、新しいファイルを作成します。
注: 上記でコードスペースを閉じた場合は、再度開くか、新しいコードスペースを作成してください。
ファイルに名前を付けますskills.js
新しいファイルが次のようになっていることを確認します。
ファイルにskills.js、次の関数ヘッダーを入力します。
function calculateNumbers(var1, var2)GitHub Copilot は、関数本体全体を灰色のテキストで自動的に提案します。以下はおそらく表示されるものの例ですが、正確な提案は異なる場合があります。
Tabを押して提案を受け入れます。
⌨️ アクティビティ: コードスペースからリポジトリにコードをプッシュします。
⌨️ アクティビティ: コードスペースからリポジトリにコードをプッシュします。
VS Code ターミナルを使用して、skills.jsファイルをリポジトリに追加します。
git add skills.js次に、VS Code ターミナルステージから変更をリポジトリにコミットします。
git commit -m "Copilot first commit"最後に、VS Code ターミナルからコードをリポジトリにプッシュします。
git push
約 60 秒待ってから、次のステップに備えてリポジトリのランディング ページを更新します。
ステップ 3: 複数の提案を含む GitHub Copilot タブを表示する
アクティビティ: 最新のコードを Codespace リポジトリにプルします。
注記
プルは次のアクティビティの前に実行する必要があります。
VS Code ターミナルを使用して最新のコードを取得します。
git pull
⌨️ アクティビティ: 別の Javascript メソッドを追加し、すべての提案を表示します
VS Code エクスプローラー ウィンドウのコードスペース内から、新しいファイルを作成します。注: 上記でコードスペースを閉じた場合は、再度開くか、新しいコードスペースを作成してください。
ファイルに名前を付けますmember.js
ファイルにmember.js、次の関数ヘッダーを入力します。
function skillsMember()入力を中止し、赤い波線の上にマウスを移動してコパイロットの提案を表示し、...（赤い波線の上に移動しても表示されず。（）の後にスペースを入力するとコード提案が表示された）
をクリックしますOpen Completions Panel。Copilot は約 10 個の異なるコード提案を合成します。次のようなものが表示されるはずです。
好みの解決策を見つけて、 をクリックしますAccept Solution。
ファイルmember.jsはソリューションで更新されます。
⌨️ アクティビティ: コードスペースからリポジトリにコードをプッシュします。
VS Code ターミナルを使用して、member.jsファイルをリポジトリに追加します。
git add member.js次に、VS Code ターミナルステージから変更をリポジトリにコミットします。
git commit -m "Copilot second commit"最後に、VS Code ターミナルからコードをリポジトリにプッシュします。
git push
約 60 秒待ってから、次のステップに備えてリポジトリのランディング ページを更新します。
ステップ 4: コメントを使用して Copilot でコードを生成する
アクティビティ: 最新のコードを Codespace リポジトリにプルします。
注記
プルは次のアクティビティの前に実行する必要があります。
VS Code ターミナルを使用して最新のコードを取得します。
git pull
⌨️ アクティビティ: コメントから Copilot の推奨コードを生成します。
VS Code エクスプローラー ウィンドウのコードスペース内から、新しいファイルを作成します。(上からコードスペースを閉じた場合は、再度開くか、新しいコードスペースを作成してください。)
ファイルに名前を付けますcomments.js。
次のコメントをファイルに入力します。
// Create web serverを押してenter新しい行に移動します。
Copilot がコード ブロックを提案します。
赤い波線の上にマウスを移動し、...
注記
コパイロットのコード ブロックの提案や、赤い波線と 3 つの点 が表示されない場合は、次のように入力して GitHub コパイロットの完了パネルを表示...できます。control + enterをクリックしますOpen Completions Panel。Copilot は、約 10 個の異なるコード提案を合成します。次のようなものが表示されるはずです。
好みの解決策を見つけて、 をクリックしますAccept Solution。
ファイルcomments.jsはソリューションで更新されます。
⌨️ アクティビティ: コードスペースからリポジトリにコードをプッシュします。
VS Code ターミナルを使用して、comments.jsファイルをリポジトリに追加します。
git add comments.js次に、VS Code ターミナルステージから変更をリポジトリにコミットします。
git commit -m "Copilot third commit"最後に、VS Code ターミナルからコードをリポジトリにプッシュします。
git push
約 60 秒待ってから、次のステップに備えてリポジトリのランディング ページを更新します。
Page updated
Google Sites
Report abuse