これは フィヨルドブートキャンプ Advent Calendar 2024 の9日目の記事です。
昨日(12/8)はmotohiro-mmさんによる Rails7.2でChromeDevToolsのデバイスモードを変更して操作するとエラーが出る話 でした。自分もどこかで同じ問題を踏みそうなので、参考にさせていただきます！
フィヨルドブートキャンプ(以下、FBC)のアドベントカレンダーに空きがあるとのことで、急遽筆を取った次第です。自分はメンターとして関わらせていただいていますので、カリキュラムの話、特にいま関心のあるGitの話をちょっと書きたいと思います。
Git、基本の学習環境はすでに提供済み
Git、あるいはその他のバージョン管理ツールは、プログラミングを仕事にしている人にとって必須のツールですが、それ以外の人はまず触れたことがないというケースが多いのではないでしょうか。「コードを書く仕事が主ではないけど、分析のためにSQLは書ける」という人は複数知っていますが、「コードを書く仕事が主ではない && バージョン管理ツールを使いこなせる」という人は滅多におられない*1と思います。なので、FBCに入ってすぐの初学者のみなさんにとって、Gitとの出会いはまさに「未知との遭遇」と言えるでしょう。
FBCの学習カリキュラムでは、かなり早い段階でGitの基本的な操作の練習コンテンツが準備されています。練習以降は、GitHub上にソースコードをpushしたり、さらにレビュー結果に応じて変更をcommitしたり等の実践的な使用が始まります。ソースコード提出はみなさん概ね問題なく進めておられるので、基本を学んでもらうという点では、現在のコンテンツは充分に役割を果たしていそうです。
「複雑なGitの活用シーン」はいつかどこかで出会うんだよな
しかしながら、あくまでプラクティスでの実践は「1人開発」にかなり近い環境であるため、より複雑なGitの活用シーンに出会う機会は終盤の「チーム開発」*2に至るまで意外と無い…というケースになりがちな気がしています。「チーム開発」では並行してブランチが走っており、また、そこに至るまでの過程で皆さん充分な自走力(自力で調べて解決まで導くチカラ)を備えておられるので、それらの状況がGitを使いこなすスキルの糧となります。が、より早い段階でGitを使いこなせていたり、トラブルに対処できるようになっていたりすると、途中のプラクティスやチーム開発をよりスムーズに進める助けになるはずです。
「複雑なGitの活用シーン」は、例えば次のようなことがあるかなと思っています。
- いっぱいコードを書いたけど、2機能分の変更内容があるので、2commitに分けて歴史を積みたい
- commitしちゃったけどやっぱりやり直して2commitに積みなおしたい
- 歴史が長くなりすぎたのでmerge前にイイ感じに統合したい
- 作業ブランチがいつの間にかmainから遠く離れており、すさまじくconflictが発生する
- Aブランチで実装していた一部の機能が他ブランチにも必要になってきたので、その機能部分だけBブランチとして先行してmainに取り入れたい
- ローカルのmainブランチに誤ってcommitを積んでしまった
- ローカルのmainブランチを誤って消してしまった
- (etc...)
なんで出来るようになったんだっけ→それはいっぱい問題を踏み抜いて実体験したから
上記シーン例は自分の心当たりのあることばかりなのですが、これらに最初出会った時はどうしていいかわからなくて困った覚えがあります。今、それができるようになったのは「実体験したから」という一言に尽きます。転じて言えば、実体験を積めばおのずと身につく のではないかと考えています。
FBCのプラクティスのひとつとして、複雑な状況をわざと用意しておき、それらをGitを活用して解決してもらう…というのがいいのではと思ってアイデアを練っているところです。
まだメンターMTGで言えてない(すみません)
つらつら書いたのですが、実は、月次のメンターMTGではまだ「やります！」宣言ができておりません…。もうちょっと具体でモノを作ってみて、いけそうだと分かってからお伝えしようと思っていたのですが、期せずしてアドベントカレンダーのネタにしてしまいました…。komagataさん、machidaさん、メンター陣のみなさん！1月のMTGにてカンバンのタスクを拾わせていただこうと思っていますので、よろしくお願いします！🙇
アイデアメモ
どんなプラクティスにするかツラツラ考え中…。作っていくうちにボツにしたり、メンター陣のみなさんのレビューで磨かれるので全部載らないような気がしていますが…。
- mainブランチへのrebaseをするときにちょっとしたconflictが発生し、解決する。よくありがちかなと思うので事前体験してほしい。
- git cherry-pick で1件のcommitだけを別ブランチに抜き出す。適切な粒度にしておくとこんな便利なこともできるよということを知ってほしい。
- 無駄commitだらけのブランチを適切な粒度のcommit数個に再整形する。
git add -pは覚えておくと便利だと思う。 --force-with-lease、--force-if-includesを使って同名ブランチの上書きpushをする。ちょっとこれは自分も改めて勉強しなおす必要がある。- 適切なコミットメッセージを書くという意識をもってもらいたい。
- …などの作業を仮想体験するための、それなりのボリューム感のあるソースコードが必要。
- 雛形リポジトリと問題の発生しているブランチ群を用意 → forkしてもらい、解決したものをPullRequestとして提出してもらう。
- レビューに使う体力が極力少ないカタチを目指す。時間をかけずにレビューできれば、その分速くお返事ができたり、多くのレビューができたりするので。
余談
同様の「実体験を積めばおのずと身につく」の方針で過去に原案を準備させてもらったプラクティスが、
の2件です。受講生でこれらのプラクティスを通過された方は、”プログラムを修正する"ということを「実体験」していただけたかなと思いますが…特に後者のほうで…どうでしょう？ うまくいっているといいのですが🤔
これらの準備にも3〜5ヶ月くらいかかった気がするので、Gitのプラクティスを準備し始めたとして、実際に使えるようになるまでは結構かかりそうです。お正月にガッツリ時間取れるかな〜。がんばるか〜。
