Git & ブランチモデルで学ぶ バージョン管理入門
•
0 gefällt mir•343 views
バージョン管理について聞いたことが無いレベルの人が、（実操作は差し置いて）バージョン管理システムを実運用できるレベルを目指すためのスライドです。
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Git & ブランチモデルで学ぶ バージョン管理入門
Ähnlich wie Git & ブランチモデルで学ぶ バージョン管理入門 (20)
Git & ブランチモデルで学ぶ バージョン管理入門
- 2. 目次 • バージョン管理システム • Git • ブランチモデル(バージョン管理ワークフロー) – git-flow – GitHub Flow – GitLab Flow – GitFeature Flow • まとめ
- 4. バージョン管理システム
- 5. バージョン管理システム 概要 こんなファイルの管理方法をしていませんか？ 同一のファイルに対して日付を付けたり、bakとか orgとかの拡張子を付けて管理していると… 後々、 “何のために”,“どこを変更したのか”分か らなくなる。
- 6. バージョン管理システム 概要 運用上の問題点 プログラマーにとっては、多くのコードを編集した上 で何か不具合が起きたときに、元のバージョンへ戻 すことは日常茶飯事 バージョン管理せずに更新する場合、古いバー ジョンに戻すのは手作業になるので手間が掛か り、ミスが発生しやすくなる。
- 8. バージョン管理システム 概要 バージョン管理システムとは ファイルに対して「誰が」「いつ」「何を変更したか」と いうような情報を記録することで… • 変更履歴の記録、追跡 • 用途毎に分岐して管理 • 過去のある時点の情報を復元 • ある時点の状態と差分を表示 これらを実現できるシステム
- 10. Git
- 11. Git • 分散型バージョン管理システムのバージョン管理が 簡単にできるツール • アジャイル ソフトウェア開発の事実上の業界標準 • Git自身はコマンドで操作するCUIツール • Git をGUIで操作するためのツールも複数存在する GUIだと使えない・制限があるコマンドがあったり、 使いたいコマンドの操作を探すのが大変だったり するので、CUIも使えるようになっておくべき
- 12. Git 各種ツール • VSCODE(Win/Mac) IDEの切り替えなしで使えるので、ソースコードのみ の管理であれば、これ一択かも • TortoiseGit(Win) エクスプローラ上で使える右クリックメニューが便利 Ofiice系の比較をGUI上でできる • Soucetree(Win/Mac) Macで最も人気、git-flowを標準でサポート 2021年現在はVSCODEがあるので、微妙な選択肢か も
- 13. Git GUIツールのトレンド
- 14. Git Gitでできること • 古いバージョンに簡単に戻せる • 新旧のファイルを一元管理できる • 編集した履歴を複数人で共有できる • 複数人で修正した部分を一つに統合（マージ） できる
- 15. Git その他の作業にも活用できる テキストデータや画像データ、Excelファイルなども 管理することができる 修正が発生するありとあらゆるファイルに活用 でき、複数人で修正前後の変化を確認できる ので、業務の効率化ができる。
- 16. Git 基本用語 リポジトリ（repository） ファイルやディレクトリを入れて保存しておく貯蔵庫 のようなもので、 Gitにおけるリポジトリはリモートリ ポジトリとローカルリポジトリの二種類に分かれてい る。
- 17. Git 基本用語 リモートリポジトリ サーバー上に設置して複数人で共有するためのリ ポジトリ 作業内容を共有する・他のユーザーの作業内容を 把握するときに使用する ローカルリポジトリ ユーザーごとのローカルマシン内のリポジトリ、 普 段の作業用として使用する
- 18. Git 基本用語 ワークツリー ユーザーが編集している作業中のディレクトリ インデックス コミットの対象ファイルとなる目印 作業場所であるワークツリーの中に配置しても、コ ミットの対象とならないため、一度インデックスに登 録(add操作)する必要がある
- 20. Git 基本操作 コミット(commit) ファイルやディレクトリの変更をローカルリポジトリに 記録する操作 実行するごとにファイルを編集した日時・内容を記 録したファイルが生成される アド(add) 編集したファイルをリポジトリへコミットするためにイ ンデックスへ登録（add）する操作
- 21. Git 基本操作 プッシュ(push) ローカルリポジトリにあるファイルをリモートリポジト リに反映する機能 アップロードのような操作 プル(pull) 共有されているリモートリポジトリに保存されている ファイルの最新版をダウンロードする
- 22. Git 基本操作 ブランチ (branch) ファイルの編集履歴を分岐させて記録していく機能 複数のユーザーで平行して行われるバグの修正や、 機能の追加などのファイル編集作業を正確に管理 できる ブランチモデルでは役割毎に名称が決められており、 メインのブランチ名を”master”ブランチと呼称してい る。
- 24. Git 操作名 その他 init , log, status, diff, reset, revert, checkout, branch, remote, fetch, rebase, config, show, tag, reflog, rm, chery-pick など GUIのツールでは相当する機能がなかったりする ので、CUIが使えるようになると便利
- 26. Git リポジトリの取得から更新までのフロー ① リモートリポジトリをclone操作でロー カルリポジトリとして取得する ② ワークツリーで自分が作成したファ イルを編集する ファイル追加する場合はadd操作で インデックスを付ける ③ 作業内容をcommit操作でローカル リポジトリに保存する ④ push操作でローカルリポジトリをリ モートリポジトリに反映し、他の人と 共有できる状態にする ① ② ③ ④
- 31. ブランチモデル
- 32. ブランチモデル 概要 ブランチモデルは、開発を進めるにあたって、 どのようにブランチを活用していくかのルール バージョン管理ワークフローとも呼ばれる
- 33. ブランチモデル 概要 なぜ必要か？ ルールのないGitを取り扱うと… Gitのブランチは自由に簡単に作ることができるが… 自由度が高さが混乱の元になる どのリポジトリにも全員からPUSHできる状態にな るので危険 安全に運用するならルールが必要
- 34. ブランチモデル 採用のメリット • バージョン管理のワークフローの見通しがよくな る ⇒コンテンツ管理フロー・管理履歴の明確化 • 複数人で協力して開発するときに共通の指針と なり、非常に便利 • 誤ったブランチへマージしてしまうなどの事故の 防止 • コンフリクトの低減
- 35. ブランチモデル 採用のデメリット • ワークフローの管理が複雑になって効率化どころか 負担増になる場合がある • ワークフローが複雑すぎて使われないという状況に 陥いる場合がある 導入にはトレーニングが必要
- 36. ブランチモデル TIPS • コンテンツ作成の初期は手直しが多数発生すること が多いので、初期からの導入には工数が膨らむ可 能性がある 前工程ではワークフローを強制しない方が良く、 内容が固まりだしてから取り入れるのもあり
- 37. ブランチモデル モデルの種類 代表的なモデルは、以下の４種類 • git-flow • GitHub Flow • GitLab Flow • GitFeatureFlow それぞれ一長一短あり 全て学習してプロジェクト毎に使い分ける
- 40. git-flow 概要 • Gitブランチを活用するために最初に提案されたブラ ンチモデル • 他のブランチモデルと比べると、大規模で複雑 • リリースサイクルがあらかじめ決まっているプロジェ クトに適している
- 44. git-flow(各branchの役割) release プロダクトリリース前に準備、微調整をおこなうブラ ンチ リリース予定の機能やバグフィックスがほぼ反映し た状態のものをdevelop ブランチから分岐する 機能追加中で未使用のコードなどを含めないように する リリース準備が整ったら master にマージする 分岐元：develop 分岐先：master
- 46. git-flow フロー図 – 通常の開発 開発開始 機能１ 機能２ ※修正等によるcommitは図から省略 開発終了 • masterからdevelopを作成する • developから開発対象の機能の数 だけ、featureを作成する • それぞれのfeatureの開発が完了 したらdevelopにマージし、feature を削除する。 • 全ての機能developにマージしたら releaseを作成する • releaseでテストを行い、不具合修 正が終わったら、masterとdevelop にマージし、releaseを削除する。
- 47. git-flow フロー図 – リリース後の不具合対応 不具合発生 • 不具合発生後、対応用のブランチとして、 hotfixを作成する。 • 修正後は、hotfixをmasterとdevelopにマー ジする。 ※修正等によるcommitは図から省略
- 48. git-flow フロー図 – リリース前不具合の持ち越し • releaseで見つかった不具合等を持ち越す 場合、releaseからdevelop,featureを作成す る。 ※修正等によるcommitは図から省略 不具合発覚
- 49. git-flow メリット • 管理が他のフローよりもしっかりしている • fix(不具合)の数、マイルストーンの遷移が一目瞭然 • 本番リリースしたデータと、開発中のデータの区別 が明確になり、リリースした内容も確認しやすい • 役割毎に明確に使うタイミングや意図が分けられて いる • コミットツリーを見ることでどのように作業が進んだ かを俯瞰して把握しやすい • 修正、リリース、機能追加などのいくつもの種類の 違う作業を並行して進められる
- 50. git-flow デメリット • ブランチの種類が多いことや、その開始地点やマー ジ先が多岐にわたっているため複雑になりやすい。 • 複雑なツリーになることが多いので迷子になりやす い • ブランチ間の移動や、複数ブランチへのマージの発 生量が多くなりがち 開発者の負担が少し多くなるかもしれない • オーバーヘッドが多いため、毎日リリースするような 用途には向いていない
- 51. GitHub Flow
- 52. GitHub Flow 概要 • 「GitHub」の開発で使用されているワークフローで、 最もシンプルな構成 • developブランチがなく、Pull Request機能が追加され ている
- 53. GitHub Flow 用語 • Pull Request 変更内容をレビュワーに通知し、マージを依頼する 機能 1人で作ると気がつかないコードの指摘やバグや記 述ミスの発見 品質向上 • レビュワーにとっても、他人が書いたコードを読むこ とで新しい書き方を発見できる 技能向上
- 54. GitHub Flow ブランチの種類 • master 常にデプロイ可能な状態かつ、テスト済みの状態に しておく必要がある 分岐元： feature 分岐先： feature
- 55. GitHub Flow ブランチの種類 • feature(topic) 機能追加用/不具合修正に用いる 開発完了時にブランチを削除する 分岐元：master 分岐先：master
- 56. GitHub Flow ルール • masterブランチは常にデプロイ可能である←重要！ • 作業用featureブランチをmasterから作成する • 作業用featureブランチをmasterへ定期的にプッシュ する • マージにはプルリクエストを活用する • プルリクエストが承認されたらmasterへマージする • masterへマージが完了したら直ちにデプロイを行う
- 57. GitHub Flow フロー図 – 通常の開発 • 開発開始時にmasterからfeature作成する • featureの開発が完了後、テストを行う • feature からmasterへプルリクエストを発行し、レ ビューを行う • プルリクエストが承認されたらmasterへマージす る。 • masterへマージが完了後、直ちにデプロイを行う • 追加の開発が始まると、再度masterからｆｅａｔｕｒｅ を作成する ※修正等によるcommitは図から省略
- 58. GitHub Flow フロー図 – 開発中のmaster更新発生 • masterをfeature/2にマージし、変更箇所を取り込 む • 通常の開発時と同様にfeature/2の開発・テスト完 了後にmasterにプルリクエストする • masterの不具合や新規機能追加により、 feature(/2)の開発中にmasterが更新された場合 、本対応を行う ※修正等によるcommitは図から省略
- 59. GitHub Flow メリット • 最も単純で学習コストが低い • 承認フローがあるので、見られる意識からソース コードが汚れにくい⇒品質向上 • テストを自動化しておくことで「masterにマージする たびにデプロイ」といった運用も取れるので、リリー ス作業を簡略化できる⇒サーバサイドとの親和性が 非常に高い
- 60. GitHub Flow デメリット１ • アプリの場合、１つの作業単位ごとにリリースをする とも限らないので、どのcommitがリリース対象か区 別がつきにくくなる。 • 環境（ステージング環境、テスト環境等）を分けてデ プロイしたい場合、デプロイタイミングとブランチとの 結びつきが不明確になる。
- 61. GitHub Flow デメリット２ • リリース前検証をfeatureブランチで行うことになり、 調べたいときのタイミングで、どの環境がどの featureに割り当たっているのか判断が難しい。 • marge済みのブランチがmaster一本のため、どの commitが環境に適用されているか分からなくなる。
- 62. GitHub Flow 運用時の注意点 • プルリクエストが放置されやすい ⇒直接声掛けする等のフォローが必要、 これは他のフローのマージリクエストでも同じ
- 63. GitLab Flow
- 64. GitLab Flow 概要 • GitLab がベストプラクティスとして提唱 • 「GitHub Flow + 各環境ごとのブランチ」の構成に なっている • コミットされたものが順次下流へ流れるワークフロー • プルリクエストの代わりに、マージリクエスト機能が 追加されている Pull RequestとMarge Requestは同等の機能
- 65. GitLab Flow ブランチの種類 • master メインのブランチ ステージング環境やApple・google審査対応apk用 分岐元：feature 分岐先：feature,pre-production
- 66. GitLab Flow ブランチの種類 • (feature/hotfix) 開発用・不具合対応用のブランチ 分岐元：master 分岐先：master
- 67. GitLab Flow ブランチの種類 • pre-production リリース前のテスト用または社内配布apk用のブラン チ 分岐元：master 分岐先：production
- 68. GitLab Flow ブランチの種類 • production リリース済みまたは本番apk用のブランチ 分岐元： pre-production 分岐先： production
- 69. GitLab Flow フロー図 － 通常開発 • masterブランチからfeatureを作成し、 featureで開発を進める。 • featureの開発完了後、featureから masterにマージリクエストを発行する • “ステージング環境”へデプロイして masterをテストする • masterからpre-productionブランチへマ ージリクエストを発行する • pre-productionでリリース前テストを実施 する • pre-productionからproductionへマージ リクエストを発行する • 承認後、マージを行い、即時リリースする • マージ済みのfeatureブランチを削除する ※修正等によるcommitは図から省略
- 70. GitLab Flow メリット • コミットが下流へ流れる構造のため、すべての環境 で全てテスト済みであることが保証される • 承認フローがあるので、見られる意識からソース コードが汚れにくい
- 71. GitLab Flow デメリット • GitHub Flowと比べるとフローが複雑 • リリースしたいタイミングが違う開発をマージするこ とができない（してはいけない）ため、追加要望や不 具合修正の割り込みがリリース完了するまで、 feature/hotfixからマージができず、柔軟性が低い 次ページにて解説
- 72. GitLab Flow デメリット － 開発中の割り込み • masterからhotfixブランチを作成後、 通常の開発と同様のフローで進める。 • 平行して実施していたfeatureに masterをマージし、開発を進める。 • featureの開発は、完了した場合でも、 不具合対応の修正がリリースされるま で待機する • 不具合対応完了後、suru hotfixにリリ ースされるとリリース後にfeatureから masterにマージする 不具合発生 不具合修正後 にマージ ※修正等によるcommitは図から省略 開発後待ち発生
- 73. GitFeature Flow
- 74. GitFeature Flow 概要 • ぐるなびの小山直樹さんが３つのブランチモデルの 欠点を補うために考案 • GitHub Flowの構成にテスト環境やステージング環境 等のブランチが追加されているフロー • featureブランチが他のブランチと依存関係が無い
- 75. GitFeature Flow ブランチの種類 • master 本番環境用ブランチ 分岐元： feature 分岐先： feature
- 76. GitFeature Flow ブランチの種類 • feature/hotfix 開発、不具合修正用ブランチ 分岐元： master 分岐先： master, test-env, stg-env
- 77. GitFeature Flow ブランチの種類 • test-env テスト環境用ブランチ 分岐元： feature 分岐先： なし • stg-env ステージング環境用ブランチ 分岐元： feature 分岐先： なし
- 78. GitFeature Flow フロー図 － 通常の開発 ① featureの開発完了後、featureからmasterへ マージリクエストを発行する レビュワーは、マージ可否をfeatureの開発者 に回答する 承認した場合でも、マージの実行は禁止 ② 承認後にfeatureからtest-envにマージし、 test-envでテストを行う ③ テスト完了後、featureからstg-envへマージし 、ステージング環境でテストする ④ テスト完了後、 featureからmasterにマージ する ① ② ③ marge requestのレビューは master×feature以外比較禁止 ④ ※修正等によるcommitは図から省略
- 79. GitFeature Flow フロー図 ー 開発中のバグ対応 ① test-envでテスト中にバグを発見 ② feature内で修正し、masterへのマージリクエス トからやり直す ① ② ③ ④ ⑤ バグ発見 バグ修正版 ※修正等によるcommitは図から省略
- 80. GitFeature Flow フロー図 ー 複数平行開発 • 複数平行開発しても本番環境へのリリース は常時可能な状態になっているので、任意 のタイミングでmasterへのマージまで進める タイミングを気にせず リリース可能 不具合対応 機能１ 機能2 ※修正等によるcommitは図から省略
- 81. GitFeature Flow メリット • 複数機能を平行して開発している場合でも、他の開 発完了を、待たずにリリースできる ⇒複数案件を同時に開発するのが容易 • featureブランチが他のブランチと依存関係が無いの で他の開発や不具合修正の影響を受けない • 複数環境を想定しているので、開発が終わっても marge待ちの状態に陥らない • テスト完了やアプリ申請ができた機能からリリースす ることができる、毎日リリース等も対応が可能
- 82. GitFeature Flow デメリット • 複数案件をまとめてリリースする場合も別々に各ブ ランチにマージする必要があるので、手間が増える。 • 依存している機能の開発に対し、後追いで開発して も、追い抜くことができ、その場合は不具合に繋がる • Gitリポジトリ管理ソフトウェアが想定していないフ ローがあるので、運用は慎重に行う必要がある – masterへ承認してはいけないPull Requestを発行するフ ローと承認できるフローが存在する – test-env,stg-envに対するPull Requestはレビューしてはいけ ない
- 83. ブランチモデルまとめ
- 84. ブランチモデル 4モデル比較表
- 85. ブランチモデル 実運用TIPS • ブランチモデルは一長一短、そのプロジェクトに最適 なモデルを選定すること • 今回説明したブランチモデルに必ず適合させる必要 はなく、以下の様にプロジェクト毎にテーラリング(開 発)を行い、使いやすい形で活用すること GitLab Flowの項目で説明したfeature/hotfixについて、実 は公式のフローでは記載されていない、実運用では必要 になる可能性が高いため記載していた GitHub Flow に Release を追加 GitLab Flow から PreProductionを省く など