メインコンテンツまでスキップ

はじめてのグループ開発

いくつかの Issue に取り組む準備ができたら、開発グループを編成し、席を移動して作業に入ります。
各グループには、少なくとも一人は開発経験のあるメンバーが入るようにします。

開発に慣れていないメンバーは、経験者の作業を見ながら自由に質問したり、自分なりにコードを書いてみることで学んでいきましょう。
経験者は、進めながら周囲に説明したり、意見を聞いたりして、チームの雰囲気を良くすることも意識してみてください。

💡 経験者の方へ
少し大変に感じるかもしれませんが、チームでの開発では「教える」経験も大切なスキルです。
この取り組み自体が良い訓練になりますので、ぜひ前向きにチャレンジしてみてください。

Git の基本操作：commit からはじめよう​

Git に不慣れな人は、まず経験者に操作方法を尋ねたり、どんなコマンドを使っているかを観察することから始めましょう。
すぐに覚える必要はありません。一年を通じて少しずつ慣れていけば大丈夫です。

Semantic Commit Message ルール​

Git の commit メッセージには「何の目的で変更をしたのか」がわかるような prefix（接頭語）を付けるルールがあります。

以下は代表的な例です：

  • feat: ユーザー向けの新機能の追加
  • fix: バグ修正
  • docs: ドキュメント関連の変更
  • style: コードの見た目やフォーマットのみの修正（挙動は変更なし）
  • refactor: リファクタリング（例：変数名や関数整理など）
  • test: テストコードの追加や改善（動作コードの変更なし）
  • chore: ツールや設定などの更新（実装コードの変更なし）

🔗 参考：Semantic Commit のルール（gist）

Pull Request を出す​

グループ内で開発した内容の動作確認ができたら、Pull Request（プルリクエスト） を作成しましょう。
COJT では、Pull Request を作成した本人がレビューを受けたあと、マージの操作まで行うことが原則です。

Pull Request を出すと、自動的に Cloudflare によるプレビュービルドが行われ、変更内容が Web 上で確認できるようになります。
他のメンバーや講師にも共有しやすくなります。

Pull Request と Issue の関連付け​

Pull Request を作成するときは、対応する Issue を必ず紐づけるようにしてください。
Issue に対して「この Pull Request が解決策である」と GitHub 上で記録されるようになります。

Pull Request がマージされると、対応する Issue は自動的にクローズ（完了）されます。

マージされたら自動デプロイ​

COJT サイトでは、Pull Request が main ブランチにマージされると、Cloudflare によって自動的に本番サイトへ反映されます。
このしくみについては、授業内で Cloudflare のダッシュボードを見ながら解説していきますので、安心してください。