Download to read offline
Uploaded byVirtualTech Japan Inc./Begi.net Inc.
今さら聞けない人のためのGit超入門
今さら聞けない人のためのGit超入門 3/13 ニフクラエンジニアミートアップ版
More Related Content
Similar to 今さら聞けない人のためのGit超入門
今さら聞けない人のためのGit超入門
- 1.
- 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アワード 「特別貢献賞」受賞 • ガンダム勉強会主宰・好きなモビルスーツはアッガイ 2
- 3.
- 4. 日本仮想化技術株式会社 概要 • 社名：日本仮想化技術株式会社 –英語名：VirtualTech Japan Inc. – 略称：日本仮想化技術／VTJ • 設立：2006年12月 • 資本金：3,000万円 • 売上高：10,702万円（2017年7月期） • 本社：東京都渋谷区渋谷1-8-1 • 取締役：宮原 徹（代表取締役社長兼CEO） • 伊藤 宏通（取締役CTO） • スタッフ：9名（うち、7名が仮想化技術専門エンジニアです） • URL：http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術を導入したシステムの構築・運用サポート – OpenStackの導入支援・新規機能開発・運用サポート – 自動化・DevOps支援 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団 4
- 5.
- 6. DevOpsとは？ • 開発と運用が密に連携して協力しあう開発 手法 – DevOpsを支援する技術やツールを積極的に 利用 –開発は新しい機能を安心してリリースできる – 運用は新しい機能を安心して受け入れられる ↓ 変化に対して前向きに進みやすくする 6
- 7. DevOpsを支える要素・技術 • 自動化 – テストの自動化 –インフラ構築の自動化 • 効率化 – 継続的インテグレーション(CI) – 継続的デリバリー(CD) • チーム開発（共有化？） – 運用モデルに基づくバージョン管理 – チケット駆動開発によるタスクの明確化 7
- 8. 継続的インテグレーション(CI) • ビルドやテストを短期間で繰り返し行い開発 効率を上げる手法 – 定期的に実行（デイリービルド） –バグを早期に発見（短期間で繰り返しテスト） – 他のツールと連動（進捗管理等） • 代表的なツール – Jenkins – Atlassian Bamboo – CircleCI (SaaS) – Travis CI (SaaS) 8
- 9. 継続的デリバリー(CD) • CIの仕組みをインフラ構築まで拡張 – テストした成果物を自動デプロイメント •インフラ構築自動化と組み合わせることで 短時間で構築可能 – テスト環境と本番環境を同等の構成で構築 – インフラを含めた結合テストを自動化 9
- 10.
- 11. Gitを利用したバージョン管理 • ソースコード等の共有 – 変更履歴を記録、追跡 –履歴の用途毎に分岐して管理（ブランチ） – 切り戻しが容易 • プルリクエスト（マージリクエスト）機能によ りレビューを可視化 • 他のツールとの連携 – Jenkins – Redmine 11
- 12. Gitを利用したバージョン管理 A successful Gitbranching model http://nvie.com/posts/a-successful-git-branching-model/ – リリース用と開発用の2つのメインブランチを 用意 – 機能追加、バグフィックス等Issue登録を行う毎 にメインブランチから切り出す – 問題が起きても本番用ブランチや他の人の開 発には影響しない – GitLabではマージリクエスト機能によりレ ビューを可視化 12
- 13.
- 14. バージョン管理とCI/CD • インフラ環境を自動構築しテスト – クラウドやコンテナを活用 –本番同様のインフラ環境でテストが可能 • 本番環境へのリリース時も毎回新規構築 – リリース直後に問題が発生した場合でも、旧 環境へすぐに切り戻せる 14
- 15. CI/CD/DevOpsの範囲 コード修正 静的テスト ビルド 単体テスト/ 統合テスト インフラ構築 / デプロイメント 本番 運用 継続的インテグレーション(CI) 継続的デリバリー(CD) DevOps
- 16.
- 17. デモ環境について 『GitLab実践ガイド』を参考に • CentOS 7.4にGitLabCommunity Editionを インストール – Enterprise Editionでもライセンスを有効にしな ければCommunity Edition相当 – Omnibusインストールで必要なものがまとまっ て入ります 17
- 18. GitLabインストール時の注意点 • 「Installation usingthe Omnibus packages」を参考に 環境を構築 – 普通にインストールページに行くとEEになっている – https://about.gitlab.com/installation/#centos-7 • CEをインストールしたい場合は、上記ページの一 番下の「CE or EE」をクリックし、さらに一番下の 「Install GitLab Community Edition」をクリック – https://about.gitlab.com/installation/#centos- 7?version=ce • ホスト名の決定方法がやや難解です 18
- 19. CentOS 7.4へのインストール 1. sudoyum install -y curl policycoreutils-python openssh-server 2. sudo systemctl enable sshd 3. sudo systemctl start sshd 4. sudo firewall-cmd --permanent --add-service=http 5. sudo systemctl reload firewalld 6. curl https://packages.gitlab.com/install/repositories/gitl ab/gitlab-ce/script.rpm.sh | sudo bash 7. yum install -y gitlab-ce 19
- 20. ホスト名の指定と構成変更の適用 • 以下の条件の場合、インストールの最後で自 動的に構成変更が適当される – ホスト名が正しく設定されている –逆引きDNSでホスト名を返す • 【重要】ホスト名を指定して、構成変更の適用 を行う必要がある – /etc/gitlab/gitlab.rbが設定ファイル • external_url ‘http://gitlab.example.com’ – 設定後再構成を実行 • sudo gitlab-ctl reconfigure 20
- 21. GitLab関連コマンド • GitLabの起動状態確認 – gitlab-ctlstatus • GitLabの起動／停止／再起動 – gitlab-ctl start/stop/restart – 後ろに個別のサービス名を付けることも可能 21
- 22.
- 23. GitLabの管理単位 • ユーザー – 各開発者のアカウント •グループ – ユーザーをまとめた管理単位 • プロジェクト – ソースコードのリポジトリを含めた開発プロ ジェクトに必要なもの一式 – ユーザー、あるいはグループに紐付けられる 23
- 24. GitLabで初期設定作業 1. http://gitlab.example.comにアクセス 2. ユーザーrootのパスワードを設定 3.ユーザーrootでログイン 4. 新しいユーザーを作成 5. 指定したメールアドレスにメールが届く – http://gitlab.example.comへのリンクが埋め込まれ ている（） 6. 新規ユーザーのパスワード設定 7. 新規ユーザーでログイン 24
- 25. ユーザーでプロジェクト作成 ユーザーtmiyaharを作成しています 1. 新規プロジェクトtestを作成 2. リポジトリのURLを確認 3.クライアントにリポジトリをクローン – SourceTree：URLを取得し、ユーザー認証 – gitコマンド： git clone http://gitlab.example.com/tmiyahar/test.git • ユーザー認証が必要 25
- 26. Gitのリポジトリ種別 • ローカルリポジトリ – 開発作業用クライアントに作成される –リモートリポジトリをクローンすると作成される • クローンが一番分かりやすい – 他の開発者には影響しない • リモートリポジトリ – GitLab上に作成される – 各開発者で共有される 26
- 27. ローカルリポジトリの確認 • クローンしたリポジトリを確認 – $cd ~/test – $ ls -a – 現時点では空っぽです – .gitディレクトリが作られており、リポジトリの各 種情報が格納されている 27
- 28. リポジトリにファイルを追加 1. 作業ディレクトリにファイルを追加 – $touch README.md 2. ファイルをステージング – $ git add README.md 3. ステージングしたファイルをコミット – $ git commit 4. コミットしたファイルをリモートにプッシュ – 同時にローカルリポジトリのアップストリーム設定 – $ git push --set-upstream origin master • masterブランチのアップストリームをリモートリポジトリの master（remotes/origin/master）に設定 28
- 29. ステージングとコミットの関係 29 作業用 ディレクトリ ステージング 領域 ローカル リポジトリ $ git checkout $git add $ git commit リポジトリは ブランチ毎の ファイルセットを 保持している
- 30.
- 31. ブランチを作成する 1. ブランチの確認 – $git branch – 現時点ではローカルのmasterだけ 2. ブランチの作成 – $ git branch develop 3. ブランチの切り替え（チェックアウト） – $ git checkout develop – $ git checkout –b develop で作成＆移動も 4. ブランチの確認 – $ git branch – 作業しているブランチがdevelopに変更されている 31
- 32. ブランチの流れ 32 master develop $ git branch$ git merge
- 33. developブランチで作業 1. developブランチのREADME.mdを修正 2. 修正をステージングとコミット –$ git add README.md – $ git commit – $ git commit -a でまとめて実行も可能 3. masterブランチのREADME.mdを確認 – $ git checkout master – $ cat README.md – developブランチでの修正が影響していない事を 確認 33
- 34. developブランチをマージする 1. developブランチをmasterにマージする – $git merge develop 2. README.mdを確認 – developブランチで行った修正が反映される • マージは取り込む側のブランチで行う – だから、取り込んで欲しいときは「マージ（プ ル）リクエスト」を作成する 34
- 35. 超入門の次のステップは？ • 修正の重複（コンフリクト）の解消 – gitpush時に既にリモートが更新されている – git pullするとコンフリクト発生 – 適切に修正し、再度コミット＆プッシュ 35 developブランチで修正 <<<<<<< HEAD ローカルのmasterブランチで修正 ======= Webブラウザで修正 >>>>>>> fcfafd335fd5d6a4bb8938c1c2dcbe17788debf5
- 36. ブランチ戦略を考える よくある質問 • Q. 「どのブランチ戦略がいいんですか？」 •A. 「ケースバイケース」 • 考慮すべき事（順不同） – 開発者の人数や規模 – コミットやマージの頻度や粒度 – テストの頻度や方法 – リリースの頻度や方法 36
- 37. この先に考えたい事 • テスト駆動やチケット駆動との連携 • テストの自動化 –コードコミット→テスト→マージリクエストのサ イクルの自動化 – 粒度が小さいとマージ処理する人が大変 • チケットの自動化 – テスト失敗時に自動的にチケット発行 – テスト成功時に自動的にチケットクローズ 37
- 38. ニフクラとGitLab • メモリが4GBは必要（100ユーザー見込み） – 月額まぁまぁの金額 –ただし、GitLabはかなり高機能なのでGitリポ ジトリとしてだけ使うのはもったいない • オンプレ側に置いてVPN接続？ • もう少し軽いものを使う？ – BitBucket？ • 外部サービスとの連携 – GitHub.comとかGitLab.comとか 38
- 39. ニフクラとDevOps • API連携を試したい！ • コンテナを使いたい！ •PaaSサービスを充実して欲しい！ • エンジニア同士の情報共有を図りたい！ 39 今後もミートアップでアレこれ話しましょう
- 40.