こんにちは、Webフロントのエンジニアをやっております田村と申します。
1年半ほど前までは大学院でエジプトの植物とにらめっこする生活を送っていたんですが、そんな退屈した日々を送っていた折に、去年の5月ごろに友人からレアゾン・ホールディングスのインターンに誘われまして、それがまぁあまりに楽しすぎてですね。その勢いのまま大学院を辞めて入社しちゃった☆という人間でございます。
しかも当時の自分はビジネスサイドとして入社したんですが、何をとち狂ったのか、入社して半年ほど経った去年の年末頃に突如エンジニアを志ざし、そこから猛勉強して何とか今年の新卒エンジニア研修に参加させていただいたという立場でございます。（こんな突飛なチャレンジを応援していただいた会社には感謝が尽きないです…。）
さて、今回の記事の内容は Git 研修ということで、チーム開発経験はおろかコーディングの経験すら非常に乏しかった当時の僕の目線で、ご紹介させていただければと思います。
研修の概要はオウンドメディアの記事で詳しく紹介していますので、こちらからご覧ください。
→「Gitを恐れない」
講義の流れに沿ってご紹介していきたいと思います。
まずは基本となる概念からですね。
経験豊富なエンジニアの方々からすればすでに知っている内容だったかもしれませんが、使ったことはあってもきちんと学んだことがない、というメンバーも一定数いるようですし、これから実務で使っていく上ではきちんと理解しておきたい内容でした。
基本となる概念
リポジトリ:
Gitでプロジェクト全体のファイルや履歴を管理する場所。
ローカルリポジトリとリモートリポジトリがあり、リモートリポジトリは GitHub や GitLab などのサーバーに存在する。
コミット:
変更をステージングエリアからリポジトリに保存する操作。
各コミットはスナップショットとして、プロジェクトの特定の状態を記録し、履歴として残る。
ステージングエリア:
コミットする前に変更を一時的に保管する領域。
ここにファイルを追加してからコミットを行うことで、変更内容を整理しつつ管理できる。
ツリー:
Git の内部で管理されるファイルの構造。
ディレクトリやファイルの状態がツリーとして管理され、コミットごとにその時点のツリーの状態が保存される。
ブランチ:
プロジェクトの異なるバージョンを管理するための機能。
各ブランチは異なる開発や修正を行うために使用され、最終的にマージして統合できる。
また、「コミットごとに、差分だけでなくプロジェクト全体の完全なスナップショットを持っているのは何が嬉しい？」というような質問が投げかけられたりもしました。このような深い理解を求める癖を研修時につけてくれるのはとてもありがたいですね〜
※ちなみに上記の問いに対する答えは「高速でブランチを切ったりマージしたりできるようにするため」となります。例えばブランチを作成する場合、コミットが差分だけを持っている場合だと、親ブランチの差分の計算をした上で全ファイルを新たなディレクトリにコピーする必要が生じますが、コミットがスナップショットを持っている場合だと、新しいブランチに、コミットオブジェクトに対する参照を追加するだけで済みます。マージの場合は、スナップショットを持つことで差分の計算を省略できるようになります。
リポジトリをクローンして、ブランチを切って作業してコミットしてプッシュしてプルリクエストを出して、さらに他のメンバーのプルリクエストをレビューしてマージするところまでを実際に行いました。
Git用語の簡単な説明とコマンド例
リポジトリをクローンする: リモートリポジトリ（GitHubなど）にあるプロジェクトの複製を自分のローカル環境にコピーして作業すること。
git clone https://github.com/user/repository.git
ブランチを切る: メインの開発ライン（masterやmain）から独立した作業ラインを作成して、他の作業に影響を与えずに開発を進めることができる。
git checkout -b new-branch-name
コミットする: 自分が行った変更を記録し、リポジトリの履歴に残すこと。コミットメッセージにはその変更の内容を説明する。
git add .
git commit -m "説明を入力"
プッシュする: ローカルリポジトリの変更をリモートリポジトリに反映すること。これにより、他の開発者が自分の変更を共有できる。
git push origin new-branch-name
プルリクエストを出す: 他の開発者に自分が行った変更を確認してもらい、必要であればレビューや修正を行ってもらうためのリクエストを出すこと。
レビューする: 他のメンバーが行った変更を確認し、コードの質や正確性、動作に問題がないかを確認するプロセス。
マージする: 他のブランチで行った変更を現在のブランチに統合すること。
git checkout main
git merge new-branch-name
会社で働く上で基本となるチーム開発を模した実習。この実習で特に嬉しかったのは「コンフリクトを起こす」ことが実習内容に含まれていたことですね。チーム開発経験などが豊富でない”コンフリクト恐怖症”のエンジニアが、研修後に安心して実務に取り組めるようになるためのありがたい内容でした。
↑もう怖くない！
コミット履歴の改変や stash, pop などの便利なコマンドについて学びました。
コミットの取り消し (履歴保持なし): 過去のコミットを取り消す操作。作業内容はそのまま保持されるが、コミットがなかったことにする。
コミットの取り消し (履歴保持あり): 過去のコミットを取り消す操作。ただし、取り消しの操作自体も新しいコミットとして記録されるため、履歴が破壊されない。
コミットメッセージの変更: 直前のコミットメッセージを変更する操作。まだプッシュしていない場合にのみ使用できる。
git commit --amend -m "new commit message"
履歴の確認: ローカルリポジトリのすべての参照操作を記録したログの確認。過去に移動したブランチやリセット、チェックアウトなどの操作を追跡できる。
作業状態の一時保存: 現在の作業状態を一時的に保存し、作業ディレクトリをクリーンな状態に戻す操作。作業内容は「stash」として一時保存され、後で復元できる。
一時保存した作業内容の復元: git stashで一時的に保存した作業内容を復元し、同時にスタッシュリストから削除する操作。未完了の作業を再開するときに使用する。
実際の活用例が学べるのは自社開発を行っている企業ならではですね〜
実務に入ってからも、どのようにプロジェクト全体が管理されているかのイメージを持つことは非常に重要だと感じてます
↑こちらは社内のゲーム事業部のモデルですが、社内の別の事業部ではまた違ったモデルが用いられていて、興味深いなと感じました。
実は講義の内容とは別に、このGit研修の日から始まった取り組みがあります。それは、「Gitによる日報管理」です。
新卒エンジニアは研修期間中（3ヶ月間）日報を書いたのですが、なんと、それらの日報は全てGitで管理するというルールでした。日報用のリポジトリに自分の日報をプッシュして、同期の日報（プルリクエスト）を見てコメントをつけ、承認してマージする、、、といった生活を3ヶ月続けたおかげで、全員が自然とGitに慣れることができました。
当時の僕はGitにほとんど触れたことがなかったのもあってついてくのがやっとでした。。（ChatGPTくんとエンジニアの先輩方に質問しまくって何とかついていけました）
レアゾン・ホールディングスは新規事業の立ち上げが非常に多い会社で、様々なプロジェクトが日々立ち上がっていますが、どのプロジェクトに携わるにしてもGitは切っても切り離せません。
そんな環境に飛び込んできた身として、しっかりとGitの基礎を固めてから実務に入っていけるのはとても安心感があってありがたいですね。
レアゾン・ホールディングスは、「世界一の企業へ」というビジョンを掲げ、「新しい”当たり前”を作り続ける」というミッションを推進しています。
現在、エンジニア採用を積極的に行っておりますので、ご興味をお持ちいただけましたら、ぜひ下記リンクからご応募ください。
Be the first to comment
