GitHubとは？（第2回）～Codespacesでコードを書いて動かしてみる（超初心者向け）～

パソコン GitHubでつくって学ぶ

はじめに

前回は、Git・GitHubとは何か、そしてGitHub Codespacesという「ブラウザだけで開発環境が使える機能」があることを紹介した。

GitHubとは？～ プログラミング学習を「つくって学ぶ」ための土台～
はじめに本ブログのカテゴリ「GitHubでつくって学ぶ」では、実際にコードをGitHub Codespaces上で試しながら学習を進めていく記事を扱っている。「Reactで学ぶ 予定管理アプリ開発」シリーズも、このカテゴリに入る。本記事では...
pc-labo.online
2026.07.21

今回は、実際に手を動かして、以下を一通り体験してみよう。

  1. GitHub上に自分のリポジトリを作る
  2. Codespacesを起動する
  3. C言語で「Hello, PC-LABO!」と表示するだけの簡単なプログラムを書く
  4. それを実行して、画面に表示されることを確認する
  5. 書いたコードをGitHubに保存する

難しいことは一切やらない。「プログラミングを書いて、動かして、保存する」という一連の流れを、体で覚えることが今回のゴールである。

事前準備

GitHubアカウントを持っていない場合は、github.comでアカウントを作成しておく（無料）。
アカウント作成の手順は今回は割愛する。

Step 1：新しいリポジトリを作る

GitHubにログインした状態で、画面上部の「New」ボタンから、新しいリポジトリの作成画面に進む。

以下のように設定する。

  • Repository name：hello-codespaces（好きな名前でよい）
  • Public / Private：Private（今回は練習用なので、どちらでもよい）
  • Add a README file：チェックを入れる

入力できたら、緑色の「Create repository」ボタンを押す。

READMEはなぜ大切か

リポジトリ作成時にチェックを入れたREADME.mdは、そのリポジトリを開いた人が最初に目にする「説明書」にあたるファイルである。何のためのコードなのか、どう使うのかが書いていないと、後で自分自身が見返した時にも、他の人が見た時にも、中身が伝わらない。GitHub上でリポジトリを開くと、このファイルの中身が自動的に整形されて表示される仕組みになっている。

Markdown記法の初歩

README.mdの.mdはMarkdownという記法を表す拡張子である。Markdownは、簡単な記号だけで見出しや箇条書きなどの装飾ができる書き方で、難しいタグを覚える必要がない。最低限、以下を覚えておけば困らない。

書き方意味
# 見出し見出し（#の数で大きさが変わる。##なら少し小さい見出し）
- 項目箇条書き
**太字**太字
`コード`コード（等幅フォントで表示される）
```　（コードの塊）　```複数行のコードをまとめて表示する
[表示文字](リンク先URL)リンク（例：[GitHub](https://github.com/)）

試しに、作成したリポジトリのREADME.mdを開いて編集し、以下のように書き換えてみよう。

# hello-codespaces

Codespacesの練習用リポジトリである。参考：[GitHub Codespacesドキュメント](https://docs.github.com/ja/codespaces)

## やったこと

- C言語で「Hello, PC-LABO!」と表示するプログラムを書いた

Step 2：Codespaceを起動する

作成されたリポジトリのページで、緑色の「Code」ボタンを押す。

プルダウンの中の「Codespaces」タブを選び、「Create codespace on main」ボタンを押す。

しばらく待つと、ブラウザ上にVS Code風のエディタ画面が開く。これがCodespaceである。

Step 3：C言語のファイルを作る

ターミナルにも慣れよう

ここから、画面下の「ターミナル」を使っていく。ターミナルは、文字でコンピュータに指示を出すための画面である。Codespaceの中身はLinux（正確にはUbuntu系）というOSで動いている。以下を入力すると、OSの種類を確認できる。

cat /etc/os-release

NAME="Ubuntu"のような表示が出てくるはずである。ちなみにMacはもともとUNIX系のOSなので、Linuxのコマンドと共通する部分が多い。WindowsでもWSLを使えばLinux環境を扱えるので、すでに慣れていることもあるだろう。ふだんコマンド操作にあまり触れてこなかった場合は、とりあえず、以下の3つを覚えておこう。

コマンド意味
pwd今どこのフォルダ（ディレクトリ）にいるかを表示する（Print Working Directoryの略）
ls今いるフォルダの中にあるファイル・フォルダの一覧を表示する（listの略）
cd フォルダ名指定したフォルダに移動する（Change Directoryの略）。一つ上のフォルダに戻る場合はcd ..

試しに、pwdとlsを入力してみるとよい。今のフォルダの場所と、リポジトリに入っているファイル（README.mdなど）が確認できるはずである。

hello.cを作る

左側のファイル一覧（エクスプローラー）で、新しいファイルを作成する。ファイル名は hello.c とする。

ファイルを作成すると、画面中央（ターミナルより上）にhello.cの編集画面が開く。ここに、以下を入力する。

#include <stdio.h>

int main(void) {
    printf("Hello, PC-LABO!\n");
    return 0;
}

Step 4：.gitignoreを用意する

このあとC言語のコードをコンパイルすると、helloという実行可能ファイル（バイナリ）が生成される。このバイナリは、hello.cさえあればいつでも作り直せるものなので、GitHubには保存しない（＝pushしない）のが基本である。バイナリファイルは中身が人間には読めず、差分も確認しづらいため、リポジトリに含める意味が薄い。

これを防ぐため、.gitignoreという「pushしないファイルの一覧」を定義するファイルを用意する。

エクスプローラーで新しいファイル.gitignoreを作成し（先頭のドットを忘れずに）、画面中央（ターミナルより上）のエディタ画面で、以下の内容を入力する。ターミナルではなく、エディタ側に入力する点に注意する。

# コンパイル済みの実行ファイル
hello
*.o
*.out

これで、helloという名前の実行ファイルや、.o・.out拡張子のファイルは、この後コミットの対象に出てこなくなる。

Step 5：コンパイルして実行する

C言語は、書いたコードをそのまま実行できない。コンパイルという、コンピュータが理解できる形に変換する作業が必要になる。

画面下のターミナルに、以下を入力する。

gcc hello.c -o hello

エラーが出ずに一瞬で終われば成功である。続けて、以下を入力して実行する。

./hello

Hello, PC-LABO! という文字が表示されれば成功である。

もしgcc: command not foundのようなエラーが出た場合は、以下を実行してからもう一度試そう。

sudo apt-get update && sudo apt-get install -y build-essential

Step 6：GitHubに保存する

書いたコードは、まだCodespace（クラウド上の作業スペース）の中にあるだけで、GitHubのリポジトリ本体にはまだ反映されていない。保存（コミット・プッシュ）の操作をする。

左側のアイコンの中から、分岐マークのような「ソース管理（Source Control）」アイコンを選ぶ。

メッセージ入力欄に、変更内容を短く書く（例：add hello.c）。日本語でも問題ない。

入力したら「コミット」ボタンを押す。

hello.cと.gitignoreが反映されているのが確認できる。hello（バイナリ）はグレーアウトされている、というのがポイントである。

念のため、ターミナルで以下を実行して、push漏れがないか確認しておくとより確実である。

git status

nothing to commit, working tree cleanと表示されれば、すべての変更が正しくコミット・push済みという意味になる。まだ何か表示される場合は、コミットまたはpushが漏れている可能性があるので、ソース管理パネルを見直す。

Step 7：使い終わったら（停止ではなく削除する）

前回で触れた通り、Codespacesの無料枠には1か月あたりのストレージ・コンピューティング時間の上限がある。ここで一つ、見落としやすい注意点がある。

Codespaceのブラウザタブを閉じても、実はCodespace自体は停止しない。リモートのコンピューター上で実行され続けたままになる。明示的に「Stop」を押さない限り、非アクティブな状態が続いてタイムアウト（既定では30分）になるまで、Codespaceは動き続ける。

つまり、作業が終わったらタブを閉じるだけでなく、github.com/codespacesの一覧から明示的に「Stop」を押すか、タイムアウトで自動停止されるのを待つ必要がある。停止されると、コンピューティング時間の消費は止まるが、Codespace自体はストレージ上に残り続けるため、ストレージのクォータは引き続き使われたままになる。

しばらく使う予定がない場合は、停止するだけでなく、削除（Delete）しておくのがよい。GitHubの github.com/codespaces から、自分が持っているCodespaceの一覧と、それぞれの「Stop codespace」「Delete」の操作ができる。

削除しても心配はいらない。正常にpushできていれば、コード自体はGitHubのリポジトリ側に残っているので、同じリポジトリから改めてCodespaceを作り直せば、hello.cや.gitignoreを含む同じ状態からまた再開できる。

ただし一つだけ例外がある。Codespace上で個別にインストールしたツールやパッケージ（例えば、途中でsudo apt-get installした何か）は、リポジトリの中身ではなくそのCodespace固有の環境に入っているものなので、削除すると一緒に消える。次に作り直したCodespaceでは、あらためてインストールし直す必要がある。

今回のまとめ

  • GitHub上でリポジトリを作り、そのままCodespacesを起動できる
  • README.mdは、そのリポジトリが何なのかを伝える説明書であり、Markdownという簡単な記法で書ける
  • Codespacesの中身はLinux（Ubuntu系）で動いており、pwd・ls・cdなどの最低限のコマンドで操作できる
  • Codespaces上でファイルを作成・編集し、ターミナルでコンパイル・実行できる
  • コンパイル済みのバイナリファイルは.gitignoreで除外し、GitHubにpushしないのが基本
  • 変更した内容は、コミット→プッシュという操作でGitHub本体に保存される
  • 使い終わったCodespaceは「停止」だけでなく「削除」までしておくと、ストレージのクォータを圧迫しない。正常にpushしてあれば、削除しても同じ内容から再開できる

この「リポジトリを作る→コードを書く→プログラムを動かす→保存する」という流れは、言語が変わっても（C言語でもReactでも）基本的に同じである。今後の連載記事を読み進める際も、この流れを思い出しながら進めてもらえればと思う。

コメント

タイトルとURLをコピーしました