Git・Git-Flowについて簡単にスライドにまとめてみました。
Git・Git-flowについて@nerusan1
View Slide
• 経歴• 動画の会社でプレイヤー開発• iOSプレイヤーSKD開発• フロントエンド開発• React、TypeScript• 活動• 勉強会• スクラムの⼀部導⼊• ドキュメント化推進⾃⼰紹介2@nerusan_main
⽬次1. Git基礎2. Gitflow3. まとめ3
⽬次1. Git基礎2. Gitflow3. まとめ4
• バージョニングで管理• 卒業論⽂@WEPD卒業論⽂@WEPDTʜ• ⽇付で管理• NBJO@UTNBJO@UTNBJO@UTʜ• 名前で管理• NBJO@@⼭⽥太郎UT NBJO@@⽥中UTGit基礎︓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-flow3. まとめ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ブランチ• 本番適⽤のブランチに緊急を要するバグ⾒つかった場合に対応するブランチ16Git-flow︓各ブランチについて
17Git-flow︓処理の流れmainFirst commitTag: 0.0.1developfeaturedeveopブランチはmainから切る
18Git-flow︓処理の流れmaindevelopfeatureタスクができたら(MR)PR各タスクはdevelopブランチからfeatureブランチ切って対応マージリクエストレビューを依頼すること
19Git-flow︓処理の流れmaindevelopfeature承認されたらマージdevelopに機能が追加される
20Git-flow︓処理の流れdevelopfeature/issue2feature/issue1タスクごとにfeatureブランチを切り対応
21Git-flow︓処理の流れmainrelease/0.1.0develop0.1.0リリースのタスクすべて完了0.1.0リリースのリリースブランチを切るreleaseブランチをSTG環境にデプロイ検証STG動作確認で何かバグあれば、修正STG(ステージング環境)⼀般公開しないが、本番と同等の環境であり、主に検証を⾏う環境
22Git-flow︓処理の流れmainrelease/0.1.0develop動作確認完了でmainにマージ本番デプロイtag: 0.1.0不具合修正コミットしたらdevelopへのマージも忘れずに
23Git-flow︓リリースを切る理由developrelease/0.1.0developFeature/issue100.2.0の機能開発リリースブランチで開発を⽌めることなく動作確認ができる動作確認
24Git-flow︓hotfixブランチについてmainhotfix/0.1.1developパスワードなくても⾒れる!!次のリリース待たずに今すぐに対応する必要がある
25Git-flow︓hotfixブランチについてmainhotfix/0.1.1developパスワードなくても⾒れる!!不具合修正コミットしたらdevelopへのマージも忘れずに不具合を修正Tag:0.1.1
⽬次1. Git基礎2. Gitflow3. まとめ26
• Gitは開発現場においては必須のスキルです︕• 各現場に応じてよりよりGit管理の仕⽅をする必要がある• Gitコマンド他にも…• rebase• cherry-pick• restore• reset• blame• stash• 機会があれば、またTigの使い⽅の資料を発表します27まとめ