Gitによるソースコード管理入門.pdf

Git初学者の方に向けた説明資料です。

Transcript

1. Git による ソースコード管理入門 Red Hat K.K. Technical Sales
2. Git概要
3. Gitとは • バージョン管理システム (VCS: Version Control System) の1つ • 分散したリポジトリ(保管場所)間で複製/同期を しながら管理 ◦ 複数人での共同管理に有用 • 今日における VCS のデファクトスタンダード ◦ GitHub, GitLab, Bitbucket など様々な Git ベースの サービスがある ※バージョン管理システム (VCS: Version Control System) • 一つのファイルやファイルの集合に対し変更を記録する システム • バージョン管理システムを利用することで、以下のような ことが実現できる ◦ 誰が/いつ/どこをどう/なぜ変更したかの履歴を記 録する ◦ 過去の変更内容を比較する ◦ ファイル/ディレクトリを以前の状態まで戻す time v1.0 v1.1 v1.2 v1.3 . . . 3
4. 使用例: Windows PC & GitLab 4 [1] https://code.visualstudio.com/ [2] https://gitforwindows.org/ [3] https://www.gitlab.jp/ 開発端末(ローカル) Visual Studio Code[1] サーバー(リモート) Git Bash[2] GitLab[3] コードの開発 アップロード(Push) テスト・共有・管理
5. なぜGitを使うのか 5 仕組みを使って 「人がカバーする」余地を減らす • 複数人でのコラボレーション ◦ リポジトリ/ブランチで目的に応じた並行開発が可能に ◦ 複数ユーザの変更による不整合 (コンフリクト) を検知 • 履歴はすべて Git の仕組みで記録/参照が可能 Git との連携を前提としたサービス • 最近のツール/ソフトウェアは Git との連携を前提としているも のが数多くある • サービスの入力情報を Git で管理: ◦ 役割分担を明確にする ◦ Git のイベントをトリガーとして自動でアクション
6. Gitのない世界では… 6 コードの共有は「人が同期をとる」 • 1つのファイルを複数人で編集する場合に、オリジナルを上書きす るタイミング/方法をケアする必要がある • 人の力で保つため事故が発生する File server (1)Copy (4)Copy (2)Copy (5) Copy (5) Edit (3) Edit (6) Override badly
7. Gitのない世界では… 7 「変更履歴」情報がまとまらない • 接尾字の追加を繰り返して大量のバックアップファイルができる ◦ 変更情報 (日付, 作成者名... ) をファイル名で管理 ◦ 名称はしばしば人に依存し、決まりは簡単にやぶられる • 誰が/いつ/何のために作った/変更したか、まとまった情報がない ◦ テキストファイルを Excel 等で管理することに 高コストな「変更追跡」の例 1. 運用手順書通りに実施したら事故が発生 2. 原因は判明したが、該当箇所は誰が /いつ/なぜ変更したのか不明 3. 過去のバックアップファイルを 1つ1つ開いて確認 4. 変更履歴が適切に更新されていなかった場合は追跡不可 $ ls -1 hello.yml* hello.yml hello.yml.20200301 hello.yml.20200309_suzuki hello.yml.2000315 hello.yml.bk hello.yml.org
8. Repository Gitリポジトリ 8 ファイルやディレクトリの変更を記録する場所 • 変更履歴を管理したいファイルやディレクトリ群をリポジトリ配下に配置 • gitレポジトリ直下に.gitディレクトリが存在し、ファイルやディレクトリの変更を 記録 Files Directories .git $ ls -ap ./your_git_repo ./ ../ .git/ .gitignore handson/ README.md $ ls -p ./your_git_repo/.git/ branches/ COMMIT_EDITMSG config description HEAD hooks/ index info/ logs/ objects/ packed-refs refs/
9. Local Repository Files Directories Local Repository リモートリポジトリとローカルリポジトリ 9 • リモートリポジトリ : 複数人で共有するためのリポジトリ。サーバ上に作られる。 (GitHub, GitLabがポピュラー) • ローカルリポジトリ : 各個人がファイル を編集するためのリポジトリ。各端末上に作られる。 • 開発者はリモートリポジトリからローカルリポジトリにファイルを反映 (pull)し、 編集後にリモートリポジトリへ変更を反映する (push) リモートリポジトリ、ローカルリポジトリの 2種類 Remote Repository Files Directories push pull pull push GitHub GitLab Files Directories
10. コミット 10 ファイルの変更を記録するための操作または変更記録そのもの 時系列に並んだコミットがリポジトリの歴史 Version 1.0 Version 2.0 Version 3.0 File A File B A1 B B1 A1 Repository B2 A2update update update update コミット コミット コミット new • コミットすると、前回コミット時の状 態から現在までの変更記録を作 成する。 • この変更記録はコミットまたはリ ビジョンと呼ばれる。 • コミットからハッシュ値を生成して IDとして利用する。 • コミットはメタ情報を含む。 ◦ コミットオーサ ◦ コミット日時 ◦ コミットメッセージ 89fb027 9fdfba5 32dea40 old
11. ブランチ 11 コミットの流れを分岐させて記録するための機能 異なる目的の変更を並行で行うことが可能となる • リポジトリ作成時点では、 master ブランチのみ存在する。 • 各ユーザでブランチを作成して切 り替えて使う。 • あるブランチのコミットは、他のブ ランチに影響しない。 • 分岐したブランチは、マージする ことで元のブランチに反映でき る。 あるバグを修正するためのブランチ ある機能を拡張するためのブランチ マージ 分岐したブランチで進めた開 発を他のブランチ(分岐元)に 取り込む masterブランチ Repository
12. マージリクエスト 12 ブランチ間で変更内容を反映させるためのリクエスト チーム内で変更内容の検証などを行い、コードの品質を維持できる • マージはメンテナーなど限られた役 割だけが実行できるようにするのが 一般的である。 • 一般ユーザは自身のブランチに加え た変更をマージしたい場合は、マー ジリクエストを作成する。 • メンテナーはマージする対象の変更 内容をレビューし、リクエストを承認 / 拒否する。 • Gitそのものの機能ではなく、 VCSが 提供する機能である。 ◦ GitHubでは『プルリクエスト』と呼ば れる あるバグを修正するためのブランチ ある機能を拡張するためのブランチ masterブランチ Repository 開発者 メンテ ナー マージ リクエスト
13. [参考]コンフリクトとその対処 13 同じファイルの同じ箇所を 2つのブランチで変更したことで発生する不整合 • コンフリクトが発生するとマージ処 理は中断され、対象のファイルに コンフリクトマーカーが付与され る。 • 対象ファイルを開き、コンフリクト マーカーの情報を元に内容を修 正する。 • 対象ファイルを修正した後は、再 度 git commit コマンドを実行しコ ミットし直す。 Repository A B C D master feature master のコミットBと feature の コミットD で 同ファイルの同じ箇所を更新 マージ失敗 $ git merge feature Auto-merging hello.yml CONFLICT (add/add): Merge conflict in hello.yml Automatic merge failed; fix conflicts and then commit the result $ vi playbook.yml <<<<<<< HEAD - name: Ensure httpd is present ======= - name: Ensure httpd is existing >>>>>>> feature # 例えば上記を以下のように修正 - name: Ensure httpd is installed $ git commit -m”modify: conflict between master and feature”
14. 共有用の保管場所 = リモートリポジトリ Git アーキテクチャ全体像 14 GitHub GitLab 目的に応じた同時開発の仕組み → ブランチ 変更を記録する仕組み → コミット 個人用の保管場所 = ローカルリポジトリ ブランチ コミット 共有/個人のファイル を同期する仕組み clone, push ... Files Directories ユーザはローカルでファイル編集 共同開発をサポートする機能を有する Files Directories
15. 頻繁に使用する Gitコマンド例
16. Gitコマンドについて 16 Gitコマンドは自身のローカル開発環境において Gitリポジトリに対する操作を行う際に使用します。 各コマンドの意味や用語を理解し、それぞれの操作に慣れることがスムーズに開発を進める上で重要となります。 Local Repository Remote Repository git pull git add git commit git push git fetch Local branch Index Working tree
17. • git cloneを行うとローカルリポジトリには リモート追跡ブランチ とローカルブランチ の二つが作成されます。 • ローカルからリモートブランチを参照する場合、 ”origin master”という名前で確認ができます。 （”origin/master”にするとリモート追跡ブランチが対象となるため注意） git clone 17 リモートリポジトリの情報をローカル環境にコピー $ git clone -b master https://gitlab.com/sample-org/sample-app Remote Repository Files Directories GitHub GitLab master リモートブランチ Local Repository clone Files Directories origin/master master リモート追跡ブランチ ローカルブランチ
18. • リモートブランチに加えられた変更をローカル環境のリモート追跡ブランチに反映します。 • ブランチ名を指定する代わりに --all オプションを付けるとリモートの全てのブランチの変更を取得します。 • リモート側で削除されたブランチがローカル環境に残ってしまっている場合、 --prune オプションを付けることで削除が可 能です。 git fetch 18 リモートブランチでの変更をリモート追跡ブランチに反映する $ git fetch origin master Remote Repository Files Directories GitHub GitLab master リモートブランチ Local Repository fetch Files Directories origin/master リモート追跡ブランチ
19. git pull 19 リモートブランチでの変更をローカルブランチに取り込む $ git pull origin master Local Repository • git pull は git fetch と git merge を一度に実行するコマンドです。まずリモートブランチの変更をリモート追跡ブランチに反 映し、その後ローカルブランチに変更を追加します。 • ローカルにあるブランチの変更を取り込む場合は、 git pullではなくgit mergeを使いましょう。 (git mergeについては後述 ) Remote Repository Files Directories fetch GitHub GitLab Files Directories master リモートブランチ origin/master master リモート追跡ブランチ ローカルブランチ merge
20. git checkout 20 ローカルリポジトリでの現在の作業ブランチを変更する $ git checkout feature Local Repository • git checkoutは自分の現在の作業ブランチを切り替える際に使用します。 • 新たなブランチの作成とブランチの切り替えを同時に実施したい場合、 -b オプションを使用しましょう。 • ここで登場するHEADとは現在の自分の作業ブランチを表すポインタです。 Files Directories master ローカルブランチ feature 変更前 変更後 変更先ブランチが既に存在する場合 Local Repository Files Directories master ローカルブランチ feature 変更先ブランチの作成を合わせて行う場合 $ git checkout -b feature origin/feature origin/feature リモート追跡ブランチ 作成 HEAD HEAD
21. git add 21 ローカルブランチでの変更をインデックスに追加する $ git add new-file Local Repository • Gitの管理対象となるディレクトリやファイルのことをワーキングツリーと呼びます。 • git add はワーキングツリーの変更をインデックスと呼ばれるステージング領域に追加します。 new-file feature インデックス add ワーキングツリー new-file
22. git commit 22 インデックスに追加された内容から新たなコミットを作成する $ git commit -m “new-file is added” Local Repository • 変更履歴として新たなコミットを作成します。 • コミットにはメッセージを追加できるため、コミットの内容を簡潔に表す説明文を追加します。 new-file feature インデックス ワーキングツリー new-file commit 7d04337 1509954 HEAD
23. git push 23 ローカルブランチへの変更をリモートブランチに反映する $ git push origin feature Local Repository • ローカルブランチで作成したコミットをリモートブランチに反映します。 feature 7d04337 1509954 Remote Repository GitHub GitLab push feature 1509954 HEAD
24. git reset 24 誤って git add や git commit を実施した場合などに操作を取り消すことができます Local Repository • ワーキングツリーの状態は変えず、インデックスを指定し たコミットに合わせます。また HEADの位置についても指定 したコミットに変更します。 • 誤って本来コミットすべきでない内容をコミットした場合など に利用できます。 new-file feature インデックス ワーキングツリー 7d04337 1509954 $ git reset --mixed HEAD^ $ git reset --hard HEAD^ HEAD Local Repository feature インデックス ワーキングツリー 7d04337 1509954 HEAD • ワーキングツリー、インデックス、 HEADを指定したコミット の位置に変更します。 • git reset --hard origin/feature を実行すると、現在のディ レクトリを作業前の状態に戻すことができます。 git resetのデフォルト動作 --hardオプション使用時
25. git diff ワーキングツリー、インデックス、コミット間で、変更差分を確認することができます $ git diff $ git diff 7d04337 Local Repository • ワーキングツリーとインデックスの間での変更差分を確認 します。（ワーキングツリーに新規追加したファイルは Untracked fileとなり対象外） file A feature インデックス ワーキングツリー 7d04337 1509954 HEAD Local Repository feature インデックス ワーキングツリー 7d04337 1509954 HEAD • ワーキングツリーと指定したコミット間の変更差分を確認し ます。 file B file A diff file A diff コミットを指定しない場合* コミットを指定する場合 *: インデックスに変更が無い場合はワーキングツリーと HEADとの差分を出力します
26. git merge 異なるブランチに加えられた変更をブランチに取り込みます $ git merge feature Local Repository • 異なるブランチのコミットを現在のブランチに取り込みま す。マージを行うとマージを実施したことを表すマージコ ミットが作成されます。 • 取り込んだ変更箇所が元のブランチの内容と矛盾する場 合、コンフリクトとなります。 master feature Merge commit Local Repository • マージする二つのブランチに分岐したコミットが無い場合、 マージを実行してもマージコミットが作成されない Fast-Forward(早送り)マージとなります。 (オプションでマー ジコミットを作成することも可能 ) お互いのブランチに変更がある場合 片方のブランチのみ変更がある場合 master feature HEAD HEAD
27. git rebase ブランチの分岐元コミットを変更します $ git rebase master Local Repository master feature Local Repository リベース実施前 リベース実施後 HEAD • リベースを実行するとブランチの分岐元となるコミットを変更します。この時作業ブランチ (上図のfeature)で作成していた コミットは一度破棄され、新たなコミット IDが振られた上で新たに分岐元となるコミットの後ろに再作成されます。 • リモートにプッシュ済みのブランチでリベースを実施すると、正しいコミットログを追うことが難しくなる原因となるため注意 が必要です。 master feature HEAD
28. Gitのブランチ戦略
29. ブランチ戦略 Gitを利用してチームでの開発を行う場合、アプリケーションの開発やテスト、商用環境への提供といったアプリケー ションの開発/提供サイクルを管理するため、Gitのブランチ戦略が必要となります。 自身の開発チームの状況を踏まえて適切なブランチ戦略を採用する必要があります。 代表的なブランチ戦略 ブランチ戦略 使用するブランチ 特徴 デメリット Git Flow main, develop, feature, release, hotfix ・各環境（開発、ステージング、商用）とブラ ンチが1:1の関係になる ・中〜大規模開発向き ・ブランチ数が多くマージのプロ セスが複雑 ・初期学習コストが高い GitHub Flow main, feature, (hotfix) ・他のブランチ戦略と比較しブランチの数 が少なくシンプル ・小〜中規模開発向き ・リリース時や、リリース後の bugfixがやや複雑 GitLab Flow main, feature, staging, production, hotfix ・Git Flowに近いが、upstreamファースト でbugfixを行う ・中〜大規模開発向き ・ブランチ数が多くマージのプロ セスが複雑 ・初期学習コストが高い
30. merge request hotfix Git Flow ・mainからdevelopブランチを作成 ・developからfeatureブランチを作成し、開発者は featureで作業 ・featureからdevelopにマージリクエストを作成し、レビュー実施後にマージ ・developからreleaseを作成し、ステージング環境にてテスト実施 ・releaseからmainにマージリクエストを投げ、レビュー実施後にマージし、 　商用環境へリリース ・商用環境で発生したバグは hotfixにて修正し、mainにマージ main feature merge develop release merge merge merge Tag: v1.0 Tag: v1.0.1 merge 開発の流れ ・featureからdevelopへのマージリクエストが作成された時 ・featureがdevelopにマージされた時 ・release / mainに新たなcommitが作成された時 CI実行の契機(例)
31. merge request hotfix ※本来GItHub Flowはmainブランチを常にリリース可能としますが、運用として難しい場合が多いため若干修正を加えています GitHub Flow ・mainからfeatureブランチを作成し、開発者は featureで作業 ・featureからmainにマージリクエストを作成し、レビュー実施後にマージ ・マージ後のmainをステージング環境にリリースしテスト実施 ・テスト完了後、リリースタグを作成し商用環境へリリース ・商用環境で発生したバグは hotfixにて修正し、新たにリリースタグを作成 main feature merge merge Tag: v1.0 Tag: v1.0.1 ・featureからmainへのマージリクエストが作成された時 ・featureがmainにマージされた時 ・新たなリリースタグが作成された時 ・hotfixに新たなcommitが作成された時 開発の流れ CI実行の契機(例)
32. merge request hotfix GitLab Flow ・mainからstaging / productionブランチを作成 ・mainからfeatureブランチを作成し、開発者は featureで作業 ・featureからmainにマージリクエストを作成し、レビュー実施後にマージ ・mainをstagingにマージし、ステージング環境でテスト実施 ・stagingからproductionにマージリクエストを投げ、レビュー実施後に 　マージし、商用環境へリリース ・hotfixはmainから作成。stagingに修正を取り込む際は cherry pickを行う production feature merge main staging merge merge Tag: v1.0 Tag: v1.0.1 merge ・feature / hotfixからmainへのマージリクエストが作成された時 ・feature / hotfixがmainにマージされた時 ・staging / productionに新たなcommitが作成された時 cherry pick merge request merge 開発の流れ CI実行の契機(例)
33. まとめ
34. Git操作に慣れてモダンな開発を進めよう • Gitは現代のアプリケーション開発において デファクトスタンダードなバージョン管理手法 となっていま す。 • 新たにGitに取り組む場合、覚えなければならないことは 少なく無いですが、まずは使い始め、操作に慣れていくこ とで着実にスキルが身に付いていきます 。 • DevSecOpsやGitOpsといったアプリケーションの開発 / 運用におけるベストプラクティスも Gitがベースとなってい ます。更なるステップアップを目指すためにまずは第一 歩を踏み出してみましょう。
35. linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Red Hat is the world’s leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you