Gitで始めるバージョン管理入門

開発者に限らずインフラエンジニアでも避けては通れないものにバージョン管理ツールがあります。近年では、DevOpsやInfrastructure as Code(IaC)の流行によりインフラ構築を自動化しようという動きが活発になりました。環境構築がコード化されたことで、そのコードを管理するための手法の1つであるバージョン管理にも関心が向けられています。システム開発において「誰が」「いつ」「どこを」「どのように」変更したのかという情報はとても大切です。そのような情報を履歴として残していく時に強力にサポートしてくれるツールがバージョン管理システムです。今回は、幅広く使われているGitの基本的な概念について学びましょう。

1. Gitで始めるバージョン管理入門 〜チームの開発生産性を高めよう〜 日本仮想化技術株式会社 代表取締役社長兼CEO 宮原 徹(@tmiyahar) http://VirtualTech.jp
2. 自己紹介 • 本名：宮原 徹 • 1972年1月 神奈川県生まれ • 1994年3月 中央大学法学部法律学科卒業 • 1994年4月 日本オラクル株式会社入社 – PCサーバ向けRDBMS製品マーケティングに従事 – Linux版Oracle8の日本市場向け出荷に貢献 • 2000年3月 株式会社デジタルデザイン 東京支社長および株 式会社アクアリウムコンピューター 代表取締役社長に就任 – 2000年6月 （株）デジタルデザイン、ナスダック・ジャパン上場（4764） • 2001年1月 株式会社びぎねっと 設立 • 2006年12月 日本仮想化技術株式会社 設立 • 2008年10月 IPA「日本OSS貢献者賞」受賞 • 2009年10月 日中韓OSSアワード 「特別貢献賞」受賞 • ガンダム勉強会主宰・好きなモビルスーツはアッガイ
3. 日本仮想化技術株式会社 概要 • 社名：日本仮想化技術株式会社 – 英語名：VirtualTech Japan Inc. – 略称：日本仮想化技術／VTJ • 設立：2006年12月 • 資本金：3,000万円 • 売上高：26,000万円（2021年7月期） • 本社：東京都渋谷区渋谷1-8-1 • 取締役：宮原 徹（代表取締役社長兼CEO） • 伊藤 宏通（取締役CTO） • スタッフ：10名（うち、8名が仮想化技術専門エンジニアです） • URL：http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術を導入したシステムの構築・運用サポート – OpenStackの導入支援・新規機能開発・運用サポート – 自動化・DevOps支援 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団
4. 本日のアジェンダ • Gitを利用した開発モデル • GitHubを使って試してみよう • CI/CDを支える中心的な技術であるコード 管理の代表的なGitの使用方法を講師なり に勉強して仕組みを理解できるように解説 します
5. Gitを利用した開発モデル
6. Gitを利用したバージョン管理 • ソースコード等の共有 – 変更履歴を記録、追跡（バージョン管理） – 履歴の用途毎に分岐して管理（ブランチ） – 切り戻しが容易 • プルリクエスト（マージリクエスト）機能により レビューを可視化 • 他のツールとの連携 – Jenkinsなどの自動化ツール – Redmineなどのチケット管理ツール – IaCやGitOpsなどインフラ周りも
7. git-flowの例 main hotfix-001 release-ver1 develop feature-001 feature-002 Ver.0.1 Ver.0.2 Ver.1.0 機能追加 Ver.1リリース準備 機能追加 緊急バグ修正 バグ修正
8. GitHubを使って試してみよう
9. Gitの始め方 • ローカルだけで始める – チーム開発はできない • GitLabをオンプレに導入 – ソースコードを外部に出したくない場合 – Community Editionなら無料（機能は制限） • SaaSのGitHub/GitLabを使う – あれこれしたい時は有償サブスクリプション ※他にもいろいろありますが、オーソドックスなパターンとして
10. GitHubで始めるには ローカルクライアント • Gitのインストール GitHub 1. GitHubアカウントの作成 2. 2要素認証の設定 3. SSH公開鍵のアップロード 4. リポジトリの作成
11. Gitのインストール • Windows – Git for Windowsのインストール • macOS – Xcode Command Line Toolsのインストール – gitコマンドを実行しようとすると案内されます • Linux – gitが含まれるパッケージをインストール • AlmaLinuxではgit-coreパッケージ – gitコマンドを実行しようとすると案内されます
12. Gitの環境設定 • gitconfigコマンドを実行 • システム全体、ユーザー、リポジトリの3分 類で設定可能 • とりあえずユーザー名とメールアドレスは 設定しておく • 後でもう1回設定する項目が出てきます % git config --global user.name ”Toru Miyahara” % git config --global user.email tmiyahar@begi.net
13. プロジェクト作成とクローン ユーザーtmiyaharを作成しています 1. 新規リポジトリtestを作成 2. クライアントにリポジトリをクローン – % git clone git@github.com:tmiyahar/test.git – ユーザー認証が必要 % git clone git@github.com:tmiyahar/test.git Cloning into 'test'... Enter passphrase for key ‘/Users/tmiyahar/.ssh/id_rsa’: ※パスフレーズ remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (3/3), done.
14. リモートリポジトリ ローカルリポジトリ リポジトリをクローン 同一内容 リポジトリのクローン
15. Gitのリポジトリ種別 • ローカルリポジトリ – 開発作業用クライアントに作成される – リモートリポジトリをクローンすると作成される • クローンが一番分かりやすい – 作業は他の開発者には影響しない • リモートリポジトリ – GitHub上に作成される – 各開発者で共有される
16. ローカルリポジトリの確認 • クローンしたリポジトリを確認 – % cd ~/test – % ls -a • 最初は空っぽか、README.mdだけ – リポジトリ作成時にREADME.mdを作るオプ ションをチェックした場合 • .gitディレクトリが作られており、リポジトリ の各種情報が格納されている
17. ステージングとコミットの関係 作業用 ディレクトリ ステージング 領域 ローカル リポジトリ $ git switch $ git add $ git commit リポジトリは ブランチ毎の ファイルセットを 保持している main develop
18. リモートリポジトリ ローカルリポジトリ 自分のコミットをPUSH プッシュとプル リモートリポジトリ ローカルリポジトリ 他人のコミットをPULL
19. リポジトリにファイルを追加 1. 作業ディレクトリにファイルを追加 – % touch README.md 2. ファイルをステージング – % git add README.md 3. ステージングしたファイルをコミット – % git commit 4. コミットしたファイルをリモートにプッシュ – 同時にローカルリポジトリのアップストリーム設定 – % git push
20. リポジトリ操作実行例 % touch README.md % git add README.md % git commit [main 4436930] README.mdを追加 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.md % git push Enter passphrase for key '/Users/tmiyahar/.ssh/id_rsa': Enumerating objects: 4, done. Counting objects: 100% (4/4), done. Writing objects: 100% (3/3), 269 bytes | 269.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 To github.com:tmiyahar/test.git fbb6ead..4436930 main -> main
21. ブランチの流れ main develop ① $ git switch -c develop ③ $ git merge develop ②コミットを繰り返す ブランチを切り替え mainブランチから developブランチの コミットをマージ
22. ブランチを作成する 1. ブランチの確認 – $ git branch – 現時点ではローカルのmainだけ 2. ブランチの新規作成と切り替え – $ git switch -c develop – 従来のgit checkout -b相当 3. ブランチの確認 – $ git branch – 作業しているブランチがdevelopに変更されている
23. ブランチ作成実行例 % git branch * main % git switch -c develop Switched to a new branch 'develop’ $ git branch * develop main
24. developブランチで作業 1. developブランチのREADME.mdを修正 – エディタで何か書きます 2. 修正をステージングとコミット – % git add README.md – % git commit – % git commit -a でまとめて実行も可能 3. mainブランチのREADME.mdを確認 – % git switch main – % cat README.md – developブランチでの修正が影響していない事を 確認
25. developブランチをマージする 1. developブランチにコミットされた修正差分 をmainブランチにマージする – % git merge develop 2. README.mdを確認 – developブランチで行った修正が反映される • マージは取り込む側のブランチで行う – だから、取り込んで欲しいときは「プル（マー ジ）リクエスト」を作成する ※GitHubはプル（＆マージ）リクエスト、GitLabは（プル＆）マージリクエスト
26. コンフリクト発生と解決 ローカル リポジトリ リモート リポジトリ ①コミット1をpush ②コミット2を未push ⑥pull ③別の開発者 がpush ⑦コミット3をpush ④コミット2をpush ⑤コンフリクト発生 ×
27. 修正の重複（コンフリクト）の解消 • git push時に既にリモートが更新されているとプッ シュに失敗する • git pullするとコンフリクト発生が通知され、対象と なるファイルが以下のようになる • 適切に修正し、再度コミット＆プッシュ developブランチで修正 <<<<<<< HEAD ローカルのmainブランチで修正 ======= Webブラウザで修正 >>>>>>> fcfafd335fd5d6a4bb8938c1c2dcbe17788debf5 ※コンフリクトは同じ場所を別々に修正した場合に発生。通常は起きにくい
28. コンフリクト解消手順 1. WebブラウザでREADME.mdを確認 – この時点では空っぽです 2. Edit（鉛筆）ボタンを押して何か書く 3. 「Commit changes」ボタンをクリックしてコミット – 他のユーザーがpushしたのと同義 4. git pushする – Webブラウザ側での変更が取り込まれておらず失敗 5. git pullする 6. マージ方法についてのエラーが発生するので設定を行う – % git config pull.rebase false 7. 再度git pullする – コンフリクトが発生し、自動マージに失敗 8. README.mdを編集してコンフリクトを解消 9. 再度、コミット＆プッシュします – 今度は成功します
29. 4. git push 失敗 % git push Enter passphrase for key '/Users/tmiyahar/.ssh/id_rsa': To github.com:tmiyahar/test.git ! [rejected] main -> main (fetch first) error: failed to push some refs to 'github.com:tmiyahar/test.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
30. 5. git pullするとエラー発生 % git pull Enter passphrase for key '/Users/tmiyahar/.ssh/id_rsa': remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), 924 bytes | 924.00 KiB/s, done. From github.com:tmiyahar/test 4436930..c8ce96f main -> origin/main hint: You have divergent branches and need to specify how to reconcile them. hint: You can do so by running one of the following commands sometime before hint: your next pull: hint: hint: git config pull.rebase false # merge hint: git config pull.rebase true # rebase hint: git config pull.ff only # fast-forward only hint: hint: You can replace "git config" with "git config --global" to set a default hint: preference for all repositories. You can also pass --rebase, --no-rebase, hint: or --ff-only on the command line to override the configured default per hint: invocation. fatal: Need to specify how to reconcile divergent branches.
31. 6. 7. 再度git pull % git config pull.rebase false % git pull Enter passphrase for key '/Users/tmiyahar/.ssh/id_rsa': Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result.
32. 8. 9. コンフリクト修正と再push % vi README.md % git commit -a [main 45d2bd4] Merge branch 'main' of github.com:tmiyahar/test % git push Enter passphrase for key '/Users/tmiyahar/.ssh/id_rsa': Enumerating objects: 10, done. Counting objects: 100% (10/10), done. Delta compression using up to 10 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (6/6), 643 bytes | 643.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0), pack-reused 0 To github.com:tmiyahar/test.git c8ce96f..45d2bd4 main -> main
33. この先に考えたい事 • テスト駆動やチケット駆動との連携 • テストの自動化 – コードコミット→テスト→マージリクエストのサ イクルの自動化 – 粒度が小さいとマージ処理する人が大変 • チケットの自動化 – テスト失敗時に自動的にチケット発行 – テスト成功時に自動的にチケットクローズ
34. ありがとうございました