Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

今さら聞けない人のためのgit超入門

287 visualizaciones

Publicado el

「今さら聞けない人のためのgit超入門」の資料です。

Publicado en: Ingeniería
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

今さら聞けない人のためのgit超入門

  1. 1. 今さら聞けない人のための Git超入門 日本仮想化技術株式会社 代表取締役社長兼CEO 宮原 徹(@tmiyahar) http://VirtualTech.jp
  2. 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. 3. 3 『Software Desgin』で毎月 「宮原徹のオープンソース放浪記」連載中
  4. 4. 日本仮想化技術株式会社 概要 • 社名:日本仮想化技術株式会社 – 英語名:VirtualTech Japan Inc. – 略称:日本仮想化技術/VTJ • 設立:2006年12月 • 資本金:3,000万円 • 売上高:11,293万円(2018年7月期) • 本社:東京都渋谷区渋谷1-8-1 • 取締役:宮原 徹(代表取締役社長兼CEO) • 伊藤 宏通(取締役CTO) • スタッフ:8名(うち、6名が仮想化技術専門エンジニアです) • URL:http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術を導入したシステムの構築・運用サポート – OpenStackの導入支援・新規機能開発・運用サポート – 自動化・DevOps支援 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団 4
  5. 5. 情報サイト:EnterpriseCloud.jp • OpenStackで始めるエ ンタープライズクラウ ドの情報サイト • OpenStack導入手順 書のダウンロード • 各種プレゼン資料 • その他ブログ記事 5
  6. 6. 会社のご紹介 仲間募集のお知らせ
  7. 7. 日本仮想化技術株式会社は • 仮想化技術のエキスパート集団 • 進取の精神 • 豊富な検証機材で新技術を追求 • 自由な雰囲気の職場 7
  8. 8. 一緒に頑張ってくれる仲間を募集中 • サーバー、ネットワークエンジニア – 新卒からキャリアアップしたい経験者まで – クラウド技術、自動化技術に興味がある人 • コンサルタント – 通信系に強い人大歓迎 • インターン – 学生はもちろん、社会人も可 8
  9. 9. どんなオフィス? •渋谷駅より徒歩5分 •全員がゆったりデスク とアーロンチェア 9
  10. 10. オフィスは渋谷駅至近 10 日本仮想化技術 オフィス ハ チ 公 渋谷駅東口 交差点信号 渋 谷 駅 ヒカリエの中を通ると 雨の日にあまり濡れません 渋 谷 郵 便 局
  11. 11. 優れた環境が優れた成果を生む 渋谷駅徒歩5分の新オフィス 幅140cmのゆったりデスクとアーロンチェア MacBook Pro/Airと大型液晶モニタが標準 キーボード・マウスも自由 充実の検証環境 最新機材で作業 11
  12. 12. 充実の福利厚生 • マッサージチェア • 充実のフリードリンクコーナー – お茶、ネスプレッソなど多種多様に取り揃え • 誕生日はケーキでお祝い • 雑誌年間購読制度 – 何でも好きな雑誌を年間購読 • 書籍購入支援制度 – 技術書の購入は無制限(当然) – 好きな書籍(漫画も可)を1万円/年購入 12
  13. 13. 社会人インターンの成果 • コムシス情報システ ムよりインターン受け 入れ – 2018年3月〜8月 • Kubernetesに関する 共同検証を実施 • OpenStack Days Tokyo 2018にて共同 発表 13
  14. 14. お問い合わせ先 メールにて recruit@VirtualTech.jp 履歴書、職務経歴書をご用意ください ご紹介も是非。きっと何かいいことあります。 14
  15. 15. 本日のアジェンダ • Gitを利用した開発モデル • GitLabを使って試してみよう • GitLabにプロジェクトを作成する • DevOpSaaSに向けて • CI/CDを支える中心的な技術であるコード管 理の代表的なGitの使用方法を講師なりに勉 強して仕組みを理解できるように解説します 15
  16. 16. Gitを利用した開発モデル 16
  17. 17. Gitを利用したバージョン管理 • ソースコード等の共有 – 変更履歴を記録、追跡 – 履歴の用途毎に分岐して管理(ブランチ) – 切り戻しが容易 • プルリクエスト(マージリクエスト)機能によ りレビューを可視化 • 他のツールとの連携 – Jenkins – Redmine 17
  18. 18. git-flowの例 master hotfix-001 release-ver1 develop feature-001 feature-002 Ver.0.1 Ver.0.2 Ver.1.0 機能追加 Ver.1リリース準備 機能追加 18 緊急バグ修正 バグ修正
  19. 19. GitLabを使って試してみよう 19
  20. 20. デモ環境について 『GitLab実践ガイド』を参考に • CentOS 7.5にGitLab Community Editionを インストール – Enterprise Editionでもライセンスを有効にしな ければCommunity Edition相当 – Omnibusインストールで必要なものがまとまっ て入ります • 最新版で検証(9/23導入) 20
  21. 21. GitLabインストール時の注意点 • 「Installation using the Omnibus packages」を参考に 環境を構築 – GitLabのWebページ(https://about.gitlab.com/)から 「Resource」→「Install」を選択 – 普通にインストールページに行くと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 21
  22. 22. CentOS 7.5へのインストール 1. sudo yum 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. sudo yum install -y gitlab-ce 8. sudo gitlab-ctl reconfigure 22 ←必ず実行
  23. 23. GitLabにプロジェクトを作成する 23
  24. 24. GitLabの管理単位 • ユーザー – 各開発者のアカウント • グループ – ユーザーをまとめた管理単位 • プロジェクト – ソースコードのリポジトリを含めた開発プロ ジェクトに必要なもの一式 – ユーザー、あるいはグループに紐付けられる 24
  25. 25. GitLabで初期設定作業 1. http://gitlab.example.comにアクセス 2. ユーザーrootのパスワードを設定 3. ユーザーrootでログイン 4. 新しいユーザーを作成 5. 指定したメールアドレスにメールが届く – http://gitlab.example.comへのリンクが埋め込まれ ている 6. 新規ユーザーのパスワード設定 7. 新規ユーザーでログイン 25
  26. 26. ユーザーでプロジェクト作成 ユーザーtmiyaharを作成しています 1. 新規プロジェクトtestを作成 2. リポジトリのURLを確認 3. クライアントにリポジトリをクローン – SourceTree:URLを取得し、ユーザー認証 – gitコマンド: git clone http://gitlab.example.com/tmiyahar/test.git • ユーザー認証が必要 26
  27. 27. Gitのリポジトリ種別 • ローカルリポジトリ – 開発作業用クライアントに作成される – リモートリポジトリをクローンすると作成される • クローンが一番分かりやすい – 他の開発者には影響しない • リモートリポジトリ – GitLab上に作成される – 各開発者で共有される 27
  28. 28. ローカルリポジトリの確認 • クローンしたリポジトリを確認 – $ cd ~/test – $ ls -a – 現時点では空っぽです – .gitディレクトリが作られており、リポジトリの各 種情報が格納されている 28
  29. 29. リポジトリにファイルを追加 1. 作業ディレクトリにファイルを追加 – $ touch README.md 2. ファイルをステージング – $ git add README.md 3. ステージングしたファイルをコミット – $ git commit 4. コミットしたファイルをリモートにプッシュ – 同時にローカルリポジトリのアップストリーム設定 – $ git push --set-upstream origin master • masterブランチのアップストリームをリモートリポジトリの master(remotes/origin/master)に設定 29
  30. 30. リポジトリ操作実行例 $ touch README.md $ git add README.md $ git commit [master f439952] touch test 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.md $ git push --set-upstream origin master Counting objects: 3, done. Writing objects: 100% (3/3), 248 bytes | 248.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To http://gitlab.example.com/tmiyahar/test.git 1285f2f..f439952 master -> master Branch master set up to track remote branch master from origin. 30
  31. 31. ステージングとコミットの関係 31 作業用 ディレクトリ ステージング 領域 ローカル リポジトリ $ git checkout $ git add $ git commit リポジトリは ブランチ毎の ファイルセットを 保持している
  32. 32. ブランチを作成する 1. ブランチの確認 – $ git branch – 現時点ではローカルのmasterだけ 2. ブランチの作成 – $ git branch develop 3. ブランチの切り替え(チェックアウト) – $ git checkout develop – $ git checkout –b develop で作成&移動も 4. ブランチの確認 – $ git branch – 作業しているブランチがdevelopに変更されている 32
  33. 33. ブランチ作成実行例 $ git branch * master $ git branch develop $ git checkout develop Switched to branch 'develop' develop branch $ git branch * develop master 33
  34. 34. ブランチの流れ 34 master develop ① $ git branch ③ $ git merge ②コミットを繰り返す
  35. 35. 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ブランチでの修正が影響していない事を 確認 35
  36. 36. developブランチをマージする 1. developブランチをmasterにマージする – $ git merge develop 2. README.mdを確認 – developブランチで行った修正が反映される • マージは取り込む側のブランチで行う – だから、取り込んで欲しいときは「マージ(プ ル)リクエスト」を作成する 36
  37. 37. 修正の重複(コンフリクト)の解消 • git push時に既にリモートが更新されているとプッ シュに失敗する • git pullするとコンフリクト発生が通知され、対象と なるファイルが以下のようになる • 適切に修正し、再度コミット&プッシュ 37 developブランチで修正 <<<<<<< HEAD ローカルのmasterブランチで修正 ======= Webブラウザで修正 >>>>>>> fcfafd335fd5d6a4bb8938c1c2dcbe17788debf5
  38. 38. コンフリクト発生と解決 38 ローカル リポジトリ リモート リポジトリ ①コミット1をpush ②コミット2を未push ⑥pull ③別の開発者 がpush ⑦コミット3をpush ④コミット2をpush ⑤コンフリクト発生×
  39. 39. コンフリクト解消手順 1. WebブラウザでREADME.mdを確認 – この時点では空っぽです 2. Editボタンを押して何か書く – 他のユーザーがpushしたのと同義 3. $ git push – Webブラウザの変更が取り込まれておらず失敗 4. $ git pull – コンフリクトが発生し、自動マージに失敗 5. README.mdを編集してコンフリクトを解消 6. 再度、コミット&プッシュします – 今度は成功します 39
  40. 40. git push 失敗 $ git push To http://gitlab.example.com/tmiyahar/test.git ! [rejected] master -> master (fetch first) error: failed to push some refs to 'http://gitlab.example.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. 40
  41. 41. git pullするとコンフリクト発生 $ git pull remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From http://gitlab.example.com/tmiyahar/test 88ac94f..db377a7 master -> origin/master Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result. 41
  42. 42. ブランチ戦略を考える よくある質問 • Q. 「どのブランチ戦略がいいんですか?」 • A. 「ケースバイケース」 • 考慮すべき事(順不同) – 開発者の人数や規模 – コミットやマージの頻度や粒度 – テストの頻度や方法 – リリースの頻度や方法 42
  43. 43. この先に考えたい事 • テスト駆動やチケット駆動との連携 • テストの自動化 – コードコミット→テスト→マージリクエストのサ イクルの自動化 – 粒度が小さいとマージ処理する人が大変 • チケットの自動化 – テスト失敗時に自動的にチケット発行 – テスト成功時に自動的にチケットクローズ 43
  44. 44. DevOpSaaSに向けて 44
  45. 45. DevOpsの想定される進め方 1. ToBeモデルの構築 2. 現時点での課題の抽出 3. 優先順位の策定 4. PoC環境の構築と運用 5. PoC環境からのフィードバックと改善 6. 小規模社内展開 45 自社だけではスピード感のある DevOps推進は困難
  46. 46. DevOpSaaSが解決する課題 標準リファレンスモデル提供によるDevOpsの加速 • 各種ツールの組み合わせテスト済みパッケージの提供 – 標準機能はあらかじめ設定済み • 各種ツールのバージョンアップ追従 – 既存開発・運用環境からの移行支援 • 独自機能の提供 – 可視化ツール、既存ツールのカスタマイズなど • 開発運用担当者の教育・サポート – 標準ドキュメント、教育コースの提供 • サンプルの提供 – 自動化・テストスクリプトのサンプル
  47. 47. 提供される主な機能 • チケット管理 • ソースコード管理 • テスト自動化 • デプロイ自動化 • プロジェクトマネジメント • コミュニケーション 47
  48. 48. サポートされる環境 • 開発:Git/Jenkins/Redmine • 構成自動化:Ansible • インフラ:Kubernetis • 運用監視:Prometheus • テスト自動化:Serverspec/Selenium 48
  49. 49. 改めて大募集 • 一緒にDevOpsにチャレンジする企業 – 一緒にカイゼンしていきませんか? • 一緒にDevOpsにチャレンジするエンジニア – 一緒に成長していきませんか? – 沢山の開発者を支えるお仕事です – マジで人手が足りてません – このままだと掛け声倒れになりかねない 49
  50. 50. ありがとうございました 50
  51. 51. OSCからのお願い • 休憩時間に少しでもいいので展示会場に 足を運んでください! • 展示に人が行かないと、OSCに協賛・出展 するメリットが無いと判断されてしまいます • 結果的にOSCが開催できなくなります・・ • ご理解とご協力をよろしくお願いします 51

×