Git・Git-flowについて @nerusan 1

• 経歴 • 動画の会社でプレイヤー開発 • iOSプレイヤーSKD開発 • フロントエンド開発 • React、TypeScript • 活動 • 勉強会 • スクラムの⼀部導⼊ • ドキュメント化推進 ⾃⼰紹介 2 @nerusan_main

⽬次 1. Git基礎 2. Gitflow 3. まとめ 3

⽬次 1. Git基礎 2. Gitflow 3. まとめ 4

• バージョニングで管理 • 卒業論⽂@WEPD卒業論⽂@WEPDTʜ • ⽇付で管理 • NBJO@UTNBJO@UTNBJO@UTʜ • 名前で管理 • NBJO@@⼭⽥太郎UT NBJO@@⽥中UT Git基礎︓Git導⼊前のファイル管理⽅法 5

• ファイル内ではコメントで対応 Git基礎︓Git導⼊前のファイル管理⽅法 6 /* 2022/4/21(⾦)⼭⽥太郎 追加 */ console.log(“追加”) /* 2022/4/21(⾦)⼭⽥太郎 追加 */ /* 2022/4/21(⾦)⼭⽥太郎 削除 */ /* 2022/4/21(⾦)⼭⽥太郎 削除 */ // console.log(“削除”) /* 2022/4/21(⾦)⼭⽥太郎 修正 */ // console.log(“削除”) console.log(“変更”) /* 2022/4/21(⾦)⼭⽥太郎 修正 */

• ファイルとコードが多すぎてよくわからなくなる • 新しいバージョン保存するたびに容量が 倍 倍になっていく • 誰が編集したの︖どこが修正されたの︖本当にあっている︖ • ⼈で数年かけたプロジェクトでは、ファイル数百・数千 すべて共有 • リファクタリングとしてディレクトリ・ファイル構成を変えるとさらにわけわからない ʜ Git基礎︓Git導⼊前のファイル管理⽅法の問題点 Gitで管理することで解決 7

⼀⾔でいうとバージョン管理システムの つ • ⼤まかに以下の問題を解決 • 誰がいつ修正したのかテキストレベルですぐわかる • 前リリースのソースコードにすぐ切り替えられる • 作業中でも他⼈のソースコードを⾃⾝の環境にすぐ切り替えられる • 容量が⼩さいく、動作も軽量 • 別時間軸でも管理が可能 チームで並⾏開発が容易 Git基礎︓Gitとは︖ 8

各時間軸のことをブランチ、合体することをマージ 例)機能AとBを並⾏で開発するとする Git基礎︓処理の⼤まかな流れ mainブランチ 元バージョン Aブランチ Bブランチ Aʼブランチ 機能A追加 Bʼブランチ 機能B追加 Mainʼブランチ 機能AとB追加 ②機能追加 ①各作業者がブランチ を切る ③マージ 9

• 各ブランチでは、コミットを⾏える • コミットとは、コードの追加修正箇所をさらに細かくGitに登録すること Git基礎︓コミットとは︖ 1. パッケージ導⼊のためパッケージファイル更新 2. 機能Aのソースコードは不要になったので削除 3. メールフォーマットを検証する関数追加 4. フォーマッターをかけた ・ ・ 適切にコミットして、レビューしやすくすることが⼤事 決して1ブランチ1コミットとはしないこと 10

• コミットを参照しやすくするために、わかりやすい名前を付けるもの • バージョン管理などに利⽤される Git基礎︓タグとは︖ 1. 機能A追加←(タグ: v1.0.0) 2. パッケージ導⼊のためパッケージファイル更新 3. 機能Aのソースコードは不要になったので削除 4. メールフォーマットを検証する関数追加 5. フォーマッターをかけた←(tag: v1.1.0) 11

• Git command(おすすめ度1 • CUIベースで、コマンド量が多く、細かい操作ができないこともある× • Tig(おすすめ度4 • CUIベースで素早くコマンド操作が可能○ • グラフィックが⾒やすい○ • ⾃⾝でコマンドカスタマイズもできる○ • VScode(おすすめ度3 • GUIベースでわかりやすい○ • マウス操作がめんどくさい× • VScodeを利⽤していたら何もインストール不要○ • Source Tree(おすすめ度2 • GUIベースでわかりやすい○ • マウスがめんどくさい× • 別途インストールする必要がある× Git基礎︓Git操作する⽅法 $ git switch ‒c branchA $ git add . $ git commit ‒m “コード追加” 12

⽬次 1. Git基礎 2. Git-flow 3. まとめ 13

• ブランチを切って並⾏で開発はできるようになったけど、実際に開発運⽤って なると、どうやって進める︖ • ブランチ名は︖ • チーム開発において、バラバラにブランチ管理されたら、どれが最新のコードな のか、リリースブランチなのかがわからなくなる........ Git-flow︓Gitでチーム開発するときの問題 Git-flowでルールに則って開発することで解決 14

Git-flowはチーム開発するときのGit運⽤ ルール • Driessen⽒が考案した開発モデル • リンク: http://nvie.com/posts/a-successful-git- branching-model/ Git-flow︓Git-flowとは︖ 15

• main(master)ブランチ • 現在本番に適⽤されているソースコードのブランチ • developブランチ • 開発を⾏うためのブランチ • リリース前はこのブランチが最新バージョンとなる • featureブランチ • 個々のタスク開発・修正を⾏うブランチ • 開発ブランチよりブランチを切る • releaseブランチ • リリースのため機能がすべて適⽤されたブランチ • ステージング環境に適⽤するブランチ • hotfixブランチ • 本番適⽤のブランチに緊急を要するバグ⾒つかった場合に対応するブランチ 16 Git-flow︓各ブランチについて

17 Git-flow︓処理の流れ main First commit Tag: 0.0.1 develop feature deveopブランチはmain から切る

18 Git-flow︓処理の流れ main develop feature タスクができたら(MR)PR 各タスクはdevelopブランチから featureブランチ切って対応 マージリクエスト レビューを依頼すること

19 Git-flow︓処理の流れ main develop feature 承認されたらマージ developに機能が追加される

20 Git-flow︓処理の流れ develop feature/issue2 feature/issue1 タスクごとにfeatureブランチを 切り対応

21 Git-flow︓処理の流れ main release/0.1.0 develop 0.1.0リリースの タスクすべて完了 0.1.0リリースのリリースブランチを切る releaseブランチをSTG環境にデプロイ検証 STG動作確認で何かバグあれば、修正 STG(ステージング環境) ⼀般公開しないが、本番と同等の環 境であり、主に検証を⾏う環境

22 Git-flow︓処理の流れ main release/0.1.0 develop 動作確認完了でmainにマージ 本番デプロイ tag: 0.1.0 不具合修正コミットしたら developへのマージも忘れずに

23 Git-flow︓リリースを切る理由 develop release/0.1.0 develop Feature/issue10 0.2.0の機能開発 リリースブランチで開発を⽌めることなく動作確認ができる 動作確認

24 Git-flow︓hotfixブランチについて main hotfix/0.1.1 develop パスワードなくても⾒れる！！ 次のリリース待たずに今すぐに対応する必要がある

25 Git-flow︓hotfixブランチについて main hotfix/0.1.1 develop パスワードなくても⾒れる！！ 不具合修正コミットしたら developへのマージも忘れずに 不具合を修正 Tag:0.1.1

⽬次 1. Git基礎 2. Gitflow 3. まとめ 26

• Gitは開発現場においては必須のスキルです︕ • 各現場に応じてよりよりGit管理の仕⽅をする必要がある • Gitコマンド他にも… • rebase • cherry-pick • restore • reset • blame • stash • 機会があれば、またTigの使い⽅の資料を発表します 27 まとめ