Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

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

297 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Ingenieurwesen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

今さら聞けない人のための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

×