業務フローから学ぶgit、GitHub入門
はじめに
社内勉強会を開催するにあたって、扱った内容の一部を記事にしました。
今やweb系エンジニア業界でほぼ必須と言えるgit、GitHubについて
「なんとなく分かるけど実際、業務でどう使うの？」
と感じているエンジニア1年生のための記事になります。
近頃は便利なGUIツールが多く存在しますが基本的な概念を知らずにそれらのツールを使用してgitがブラックボックス化してしまうとチームメンバー迷惑をかけてしまうことや自分の進捗が吹っ飛ぶことにつながりかねません。
前提知識
- gitの基本的概念がざっくり分かる(ローカルリポジトリ、リモートリポジトリ、クローン、コミット、プッシュなど)
- GitHubとは何か知っている
上記の二つは分かりやすく説明されている記事が大量にあると思うので今回は割愛します...
git-flowを知ろう
git-flowとは
簡単にいうと、gitのブランチにおける分岐モデルのことです。多くの企業ではgit-flowやそれに類似したモデルに沿って開発していくと思います。
git-flowの概念図↓
画像左に記されているのがbranch名です。
- master(main)※
実際のプロダクトが動いてるコードを管理しているブランチ。名前の通りこのブランチが全てのブランチの大元となる - hotfix
緊急で対応しなければならないバグ用のブランチ - release
プロダクトのリリースの際に関連する作業を行うブランチ - develop
開発の起点となるブランチ。基本的な作業はこのブランチから切って行う - feature
昨日の追加や修正等を行うブランチ。developブランチから切ったもの
何やら分からない単語が増えましたね。大丈夫です。基本的には新人エンジニアが意識する必要があるのは「developブランチ」と「featureブランチ」です。詳しくは次の章で解説します。
※GitHubでは2020年10月5日以降に作成されたプロジェクトにおいて、デフォルトのブランチがmasterからmainに変更されました
開発の流れ
実際にgit,GitHubを使用してどのように開発していくかの流れを説明します。
それぞれの流れについてgit、GitHubの用語を用いた説明と実際に入力するコマンドを記載しています。
0. ネットワーク上のコード保管場所から自分のPC環境に保管場所を複製する
git用語を用いた説明
リモートリポジトリからローカルリポジトリにcloneする
実際に入力するコマンド
git clone [リポジトリのurl]
解説
こちらはいわゆる「環境構築」で行うものです。よって最初一回行えばそれ以上行う必要はありません。以降は1~6を繰り返す流れになると思います。
1. 自分のPC環境のコードの保管状態を最新にする
git用語を用いた説明
リモートリポジトリから最新の状態のdevelopブランチをpullする
実際に入力するコマンド(developブランチにcheckoutしている状態で)
git pull origin develop
解説
リモートリポジトリのdevelop branchの状態をローカルのdevelop branchに反映させます。
git pullコマンドはgit fetchコマンドとgit mergeコマンドを合わせたものなのですが、やや複雑な概念なので最初のうちは無理して理解する必要はないかもしれません。(が遅かれ早かれ理解しなければならない時は来ます)
参考リンク
コンフリクト※する恐れがあるので作業する際は最新の状態のdevelopブランチからブランチを切って作業することを心がけましょう。
※コンフリクトとは他の人の変更内容と自分の変更内容がぶつかってしまうことです。今回は詳しい説明は省きますがエンジニアをしていれば必ず遭遇することですね(コンフリクトの解消はめんどくさい)
2. 自分がこれから作業を保存していくセーブデータを既存のデータから分岐させる。
git用語を用いた説明
developブランチからfeatureブランチをきる
実際に入力するコマンド
git checkout -b [作業するブランチ名]
解説
branch名に関しては分かりやすい&シンプルな名前をつけましょう。prefixとしてfeature/をつける場合が多いです。
ユーザーのtodoを作成する機能を実装するbranchであればfeature/create_todo_function_of_user などが良いかもしれません。
3. 作業内容を保存対象にする。保存する。
git用語を用いた説明
作業内容をステージングエリアにあげ、commitする。またはそれらを繰り返す
実際に入力するコマンド
ステージングエリアにあげる
git add [ステージングエリアにあげたいファイルのパス]
commitする
git commit -m [コミットメッセージ]
解説
addで保存対象にする。commitで保存するといった流れを繰り返します。
コードレビューをする人がレビューしやすくするためにも、分かりやすく簡潔なcommitメッセージでこまめにcommitすることをお勧めします。
4. ネットワーク上のコード保管場所に作業内容を送信する
git用語を用いた説明
リモートリポジトリにpushする
実際に入力するコマンド
git push origin [作業したブランチ名]
解説
この作業によって初めて他の人が自分の書いたコードを見ることが出来る様になります。
5. 自分の作業内容を実際のアプリケーションのコードに反映させる許可証を作成する
GitHub用語を用いた説明
pull requestを作成する
実際に行う行動
GitHubの「Pull requests」タブからpull requestを作成
解説
このpull requestはチーム開発においてとても重要な「レビュー」を行う上で大切なものです。
レビューとはいわゆるコードの添削のようなもので、基本的にチームの中である程度技術力のあるメンバーが行います。これによって書いたコードの過不足や問題の有無、typoなどのケアレスミスの防止が期待できます。
レビューによって修正必要箇所が出た場合は3番、4番のセクションをpull requestがapprove(承認)されるまで繰り返します。
6. 許可が降りれば自分のコードが反映される
GitHub用語を用いた説明
作業したfeatureブランチがdevelopブランチにmergeされる(する)
解説
承認されたpull requestをGitHub上でマージすることでdevelop branchに作業内容が反映されます。
ここまでくれば一安心。実際にユーザーが使用するプロダクトに反映される(develop branchの内容がmaster branchに反映される)まではもう少し時間がかかりますがあなたのタスクは完了と言えるでしょう。
最後に
gitやGitHabは開発効率やUI/UXに直接寄与するわけではないですが、エンジニアの素養とも言えるものです。しっかり学んでいきましょう！
Discussion