最初に
以前、42Tokyoの課題をGitHubで管理する方法について考えた。
42Tokyoの課題をGitHubで管理する | tsito.me
GitHubを利用した課題の管理・Norminetteの自動化を考えた
この時点ではまだ入学前だったため、Moulinetteがどこまで提出物を見るのか、.github/以下のファイルが存在しても問題ないのか、かなり推測で書いていた。
その後42Tokyoに入学し、最初の課題であるlibftをクリアした。
実際に課題を進めてみると、GitHub管理そのものは便利だった一方で、前回作っていた42-c-templateについては考え直す必要があった。
結論
現状の42TokyoでC言語の課題として必須のものがlibft, ft_printf, get_next_line, push_swapくらいであれば、汎用的なC言語課題用テンプレートを用意する意味はあまり大きくないと思った。
理由は単純で、それぞれの課題で求められる構成や成果物が違うからである。
libftではlibft.aを作る。
ft_printfもライブラリとして扱うが、実装する関数やファイル構成はlibftとは違う。
get_next_lineは提出ファイルがかなり絞られている。
push_swapは最終的に実行ファイルを作る課題で、これもまた別の構成になる。
つまり、最初からsrc/, inc/, 汎用Makefile, CI設定を全部入りで用意しても、結局は課題ごとにかなり直すことになる。
それなら、テンプレートに合わせて課題を始めるより、subjectを読んでその課題に必要な最小構成から作る方が安全だと感じた。
2026-05-03 追記
libftでわかったこと
少なくとも自分が提出したlibftでは、GitHubで管理していたリポジトリをそのまま提出してMoulinetteに通った。
当時のリポジトリには、課題本体以外に以下のようなファイルやディレクトリが含まれていた。
.github/workflows/README.md.gitignore
ただし、これを「どの課題でも余分なファイルを置いてよい」と解釈するのは危ない。
42の課題では、subjectに書かれている提出ファイルやディレクトリ構成がかなり重要になる。
libftでたまたま問題にならなかったものが、別の課題やレビューで問題にならないとは限らない。
前回の記事では、Moulinetteの流れを以下のように予想していた。
提出物をクローン
↓
Norminette
↓
コンパイル
↓
テスト
↓
結果集計実際の内部実装は見えないが、makeで指定された成果物を作れて、Norminetteに通り、関数の挙動が正しければ評価される、という見方は大きく外れていなさそうだった。
一方で、課題に関係ないファイルを含めてよいかどうかは、Moulinetteだけでなくレビューでも見られる。 そのため、提出リポジトリはできるだけsubjectに書かれたものだけで構成する方が無難だと思う。
テンプレートの存在意義は薄い
入学前に作った42-c-templateでは、一般的なCプロジェクトを意識してsrc/やinc/を用意していた。
GitHub - tsito2602/42-c-template: 42 subject template for C
42 subject template for C. Contribute to tsito2602/42-c-template development by creating an account on GitHub.
しかしlibftのsubjectでは、Makefile, libft.h, ft_*.cをルートに置く前提だった。
この時点で、テンプレート側のsrc/やinc/はむしろ邪魔になる。
さらに、現在のカリキュラムにおけるC言語課題を考えても、共通化できる部分は思ったより少ない。
libftはlibft.aを作るft_printfはlibftに近いが、ディレクトリ構成が異なるget_next_lineはそのそもプログラムではなく関数を作れという課題であり、ファイル数はかなり限定されpush_swapは実行ファイル、引数処理、アルゴリズム、checkerなど別の論点が増える
GNLを除き、どの課題にもMakefileやNorminetteは出てくるが、それだけならテンプレートリポジトリをcloneするほどではない。
むしろ、最初にテンプレートを置いてしまうことで「この構成を課題に合わせてよいのか」「このファイルは提出してよいのか」を毎回考えることになる。
結局、42のC課題では「テンプレートに課題を合わせる」のではなく、「subjectを読んで、その課題に必要な構成を作る」方が正しい。
GitHub Actions自体は便利
テンプレートの価値は薄いと思ったが、GitHub Actions自体は便利だった。
特に、push時に以下を自動で確認できるのは助かる。
c_formatter_42を実行する- Norminetteを実行する
- 結果をDiscordに通知する
ローカルでも確認するが、push後にもCIで失敗に気づけるのは安心感がある。 42の課題は、実装が正しくてもNormエラーで落ちる可能性があるので、そこを機械的に確認できるのは有用だった。
ただし、CI設定を提出リポジトリに含めるかどうかは別問題である。
.github/がsubject上の提出ファイルに含まれないなら、提出前に外す運用も考えた方がよい。
GitHub Actionsは「課題リポジトリに必ず入れるテンプレート」ではなく、「普段の開発を助ける道具」として扱うのがちょうどよさそう。
テスターはリポジトリに入れない
libftでは先輩方が作ってくれたテスターをかなり使った。
GitHub - usatie/libft-tester-tokyo: Tester for the libft project of 42 school
Tester for the libft project of 42 school. Contribute to usatie/libft-tester-tokyo development by creating an account on GitHub.
GitHub - Tripouille/libftTester: Tester for the libft project of 42 school
Tester for the libft project of 42 school. Contribute to Tripouille/libftTester development by creating an account on GitHub.
ただし、テスターは課題リポジトリに混ぜない方がよい。
手元でcloneして実行するのはよいが、提出対象のリポジトリにテストコードや外部ツールを含めると、subjectの提出条件に触れる可能性がある。 自分の場合は、テスターはローカルで使うだけにして、提出用の管理対象には含めないようにした。
また、libft-tester-tokyoはMacOSでしか正常に動作しないため注意。
リモート運用はそのままでよかった
前回考えていた、GitHubをorigin、vogsphereを42_v1のような名前で追加する運用はそのまま使えた。
git remote add 42_v1 <vogsphereのURL>
git push 42_v1 mainリトライが必要になった場合は、42_v2, 42_v3のように増やしていけばよい。
GitHub側には普段の作業履歴を残し、提出時だけvogsphereにpushする。 この分離は扱いやすかった。
ただし、Gitのremoteを分けることと、自分のPCからvogsphereへSSH接続できることは別問題である。 自分の端末からvogsphereへSSH接続するには、校舎内Wi-Fiに接続している必要がありそうだった。
そのため、提出時のpushは校舎iMac、または校舎内Wi-Fiに接続した自分の端末から行う前提で考えておくのがよいと思う。
SSH接続については以下の記事にまとめた。
:::embed[https://tsito.me/blog/2026-04-25]
今の運用方針
libftを通した後の運用方針は、前回よりかなりシンプルになった。
- 課題ごとにGitHubリポジトリを作る
- まずsubjectを読み、提出ファイルと成果物を確認する
- 必要なファイルだけを作る
- GitHub Actionsは必要なら参照するが、提出ファイルとして含めないよう注意する
- テスターはローカルで使い、提出リポジトリには入れない
make,make clean,make fclean,make reを確認する- 校舎端末または校内Wi-Fiに接続したPCからvogsphereへpushする
テンプレートから始めるのではなく、subjectから始める。 今のところ、これが一番ミスが少なそうだと感じている。
まとめ
入学前は、42のC課題を効率よく始めるためにテンプレートがあると便利だと思っていた。
しかし実際にlibftを進めてみると、C言語課題の数が限られているうえに、それぞれの課題で求められる構成が違うため、汎用テンプレートの出番はあまり多くなさそうだった。
GitHub管理、remoteの分離は今後も使える。 一方で、提出リポジトリの中身は毎回subjectに合わせて最小限にする方がよい。
テンプレートを整えるより、課題ごとにsubjectを読み、提出条件に素直な構成を作ることを優先したい。