Zenn
めがね〜ずPublicationへの投稿
👥

卒研で知識ないメンバに最初に覚えてもらった最低限のGit

てべすてん
2024/02/08に公開
Git
GitHub
#
チーム開発
tech

卒業研究で「みんしゅみ」というWebサービスをチームで開発しました。

当初自分を除くメンバ全員がGitの存在も知らない状態だったので、最低限の知識をキャッチアップしてもらいました。

その中でどんな知識を扱ったかを本記事にまとめておきます。学生の開発チームでは「これからチーム開発するけどメンバの中にGitを触ったことない子がいる」はあるあるなので、そんなチームに届くといいなー

https://minshumi.com/

前提

今回紹介する知識は「全員ではないがGitを触ったことがないメンバがいるチーム」での話になります。

「自分はGit触ったことあるけど触ったことないメンバもいるんだよな」な人が対象読者です。

Step1 Gitの基礎知識をさらっとインプットする

以下のサイトで1週間弱くらいかけて「ブランチとは何か？」とか「コミットは何か？」といった基本的な知識に目を通してもらいました。このStepでは「コミット？ブランチ？リポジトリ？なんか聞いたことあるぞ」程度になることが目標です。

https://backlog.com/ja/git-tutorial/

全てが全て必要、というわけではないので、上記サイトのうち、以下のページについて学習メモをつけながら流し読みしてもらいました。

  • 入門編
    • Gitの基本
    • リポジトリの共有
    • 変更履歴の統合
  • 発展編
    • ブランチ
    • リモートリポジトリ
    • コミットの書き換え
  • プルリクエスト編
    • プルリクエスト
    • マージできない場合は？

Step2 実践的なフローを叩き込む

1 開発方針を示す

初めに開発方針を示しておきます。

要はmainブランチにコミットするんじゃねえぞっていうことが言いたいわけです。

2 開発の流れを示す

次に メインとなる開発の流れ を示します。
「この開発の流れを割り振ったタスクごとにこなしていってね」というニュアンスも一緒に伝えると良さそうです。

後の実践練習のために流れを掴んでもらいましょう。

Notionなどにまとめて（↓をコピペして少し修正してもらってもOKです）

その1 【Github】issueを作成・確認

  • どんな機能を作るか、どんな変更を加えるかをあらかじめissueとして登録しておきます。
  • issueを登録することでメンバ間でやるタスクが被ることを防ぐ目的があります。
  • はじめのうちはXXXが登録します。←←←流れがわかってきたら見つけたバグを自分で登録しよう的な話もできると良き

その2 【ローカル】issueをこなすためのブランチを作成

# ブランチを作成して、mainブランチからそのブランチに移動
git checkout -b ブランチ名 main
  • ローカルリポジトリにブランチを作成します
  • 既に作成済みの場合は上記の代わりに git checkout ブランチ名 でブランチを移動します。

その3 【ローカル】ソースコードを編集してコミットする

  • ソースコードに編集を加えます。
git add .
git commit -m "コミットメッセージ"
  • キリのいいところまで編集できたら以下のコマンドでコミットをします。

ここでコメントメッセージを例示してあげると非常に良きです。

  • コミットメッセージの例
    • 〇〇をインストール
    • 投稿機能を追加
    • リロードするとエラーが発生するバグを修正
    • hogehoge.pyをリファクタリング

その4 リモートにpushする

  • ローカルリポジトリでのコミットをリモートリポジトリに反映します。
git push origin issue-xxx

その5 【ローカル】issueが解決したらGithub上でPull Requestを作成

  • pushを繰り返してコミットがリモートリポジトリに溜まっていき、issueが解決した(ex ページや機能が作成できた・バグが修正できた など)と思ったらPull Requestを作成します。
  • このプロジェクトではmainブランチへのマージはチーム管理者が行うことにしているので、自分のブランチでの変更をチーム管理者(チームメンバ)にお願い(Pull Request)します。
  1. Pull Request ページにアクセス
  2. New pull request をクリック

  1. テンプレに沿って入力

Pull Requestのテンプレはメンバがわかりやすいようにしっかり用意しておきましょう！

その6 レビューを受けてmainブランチにマージされるのを待つ

  • 他のメンバが pushされたコードのレビューをします。指摘点があれば3に戻って編集・コミット・プッシュを指摘がなくなるまで行います。
  • 指摘がなければ、後は管理者がマージするのを待ちます。無事マージされればあなたのコードがプロダクトコードに反映され無事タスク終了です。

Step3 開発フローを実践練習する

開発フローを実践練習してみます。なるべくペアプロして行った方が良いです。（メンバが何に詰まっているのかが見えるため）

今回の卒業研究ではマークダウンで自己紹介を書くリポジトリを用意して、メンバに実践してもらいました。

https://github.com/megane-s/team-develop-practice

実践するときは ディスプレイを2分割して、左にStep2をまとめたNotionなどを、右にエディタを置いておくとみながら実践練習を進められるので、メンバにおすすめしておきましょう。

その1 リモートリポジトリを確認

その2 リモートリポジトリを自分のPCにcloneする

リモートリポジトリを確認出来たらローカルにcloneしてきましょう。(📝クローン先のフォルダも指定してあげるといいかも)

cd クローンしたいフォルダ
git clone リモートリポジトリのURL .

その3 issueを確認

  • 自分に割り当てられたissueをGithubで確認します。
    • 📝 リポジトリへのリンクを貼っておく
  • issueから自分が何を実装すればいいのかを確認します。

その4 ブランチを切る

ブランチ名を確認し、issueに対応するブランチを作成します。

本プロジェクトでは、ブランチ名は issue-<issue番号> (例 issue-1)とします。

git checkout -b ブランチ名 main

その5 ソースコードを編集してcommitする

issueを達成するためにソースコードを編集してcommitします。これでローカルに編集履歴がたまっていきます。

git add .
git commit -m "コミットメッセージ"

その6 pushする

ある程度commitできたらcommitをリモートリポジトリに反映します。

git push origin ブランチ名

pushしたことで他の人も変更を（見ようと思えば）見れる状態になったことを伝えておくと理解が進むかもしれません。

その7 PRを作ってマージされるのを待つ

  • issueが解決したらPull Requestを作ってレビューを待ちます。
  • PRに指摘コメントが入ったら修正をして 再度 commit, push します。

Step4 よくあるTipsを共有

以上で基本的な流れは抑えてもらえたはずです。
あとはエラーなどで詰まったら都度わかるメンバを呼んでもらいながらではありますが、開発を進めていけるはずです。

その際、以下の2点については何回も起きえるのでTipsとして紹介しておきます。

  • ブランチを移動する
git checkout 移動先のbranch
  • mainにMergeされた他の人のcommitを自分のブランチに取り込む (最新のmainを持ってくる)
# mainブランチに移動
git checkout main

# origin/main (github上のmainブランチ) を mainブランチに反映する
git pull origin main

# 自分のブランチに移動
git checkout 自分のブランチ

# mainブランチの変更を自分のブランチに反映する。
# その際変更箇所が被るとコンフリクトします
# Conflictしたらわかるメンバを呼んでください
git rebase main

# 依存関係をダウンロードしなおす <- 📝 プロジェクトの内容に応じて具体的なコマンドを示しておく
  • コンフリクト

初めのうちはわかる人と一緒に解消するのが鉄則です（初心者が変に解消しようとしてコードが消えてしまっては大変なので）。ドキュメントに「conflictというエラーが出てきたら俺をよべ」と太字で書いておきましょう。

学生開発チームに幸あれ。

めがね〜ず
めがね〜ずPublication

学生5人による卒業研究プロジェクトチームです👓 好きな作品を共有できる「みんしゅみ」の開発を行っています！ github.com/megane-s

Discussion