Download to read offline
![リポジトリ操作実行例
$ 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.
33](https://image.slidesharecdn.com/201219git-201219023742/75/Git-2020-12-19-33-2048.jpg)
![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.
42](https://image.slidesharecdn.com/201219git-201219023742/75/Git-2020-12-19-42-2048.jpg)
Uploaded byVirtualTech Japan Inc./Begi.net Inc.
今さら聞けない人のためのGit超入門 2020/12/19
今さら聞けない人のためのGit超入門 2020/12/19 ODC2020版
More Related Content
Similar to 今さら聞けない人のためのGit超入門 2020/12/19
今さら聞けない人のためのGit超入門 2020/12/19
- 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万円 • 売上高：18,167万円（2019年7月期） • 本社：東京都渋谷区渋谷1-8-1 • 取締役：宮原 徹（代表取締役社長兼CEO） • 伊藤 宏通（取締役CTO） • スタッフ：8名（うち、6名が仮想化技術専門エンジニアです） • URL：http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術を導入したシステムの構築・運用サポート – OpenStackの導入支援・新規機能開発・運用サポート – 自動化・DevOps支援 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団 4
- 5.
- 6. 日本仮想化技術株式会社は • 仮想化技術のエキスパート集団 • 進取の精神 •豊富な検証機材で新技術を追求 • 自由な雰囲気の職場 6
- 7. 一緒に頑張ってくれる仲間を募集中 • サーバー、ネットワークエンジニア – 新卒からキャリアアップしたい経験者まで –クラウド技術、自動化技術に興味がある人 – DevOpsソリューション開発をやっています – リモートワークもOK（現在1名、北海道在住） • コンサルタント – 5G、MECなど次世代通信ソリューションに興味の ある方 • インターン – 学生（春夏）はもちろん、社会人も可 – 遠方の方もOK 7
- 8. 主な業務内容 • 仮想化技術を活かしたコンサルティング – オンプレからクラウドまで –DevOps案件のOpsとして運用・IaC開発 • 新技術のコンサルティング・PoC – 新しい仮想化技術に関する調査 – PoCによる実証検証 – 5G、MEC、GPU、コンテナなど幅広く 8
- 9.
- 10.
- 11.
- 12. 充実の福利厚生 • マッサージチェア • 充実のフリードリンクコーナー –お茶、ネスプレッソなど多種多様に取り揃え • 誕生日はケーキでお祝い • 雑誌年間購読制度 – 何でも好きな雑誌を1誌年間購読 • 書籍購入支援制度 – 技術書の購入は無制限（当然） – 好きな書籍（漫画も可）を1万円／年購入 • 在宅勤務手当て：2万円/月 – 交通費は実費精算（といってもごく稀） 12 完全在宅勤務で 中断中
- 13.
- 14. 本日のアジェンダ • Gitを利用した開発モデル • GitLabを使って試してみよう •GitLabにプロジェクトを作成する • DevOpSaaSに向けて • CI/CDを支える中心的な技術であるコード管 理の代表的なGitの使用方法を講師なりに勉 強して仕組みを理解できるように解説します 14
- 15.
- 16. Gitを利用したバージョン管理 • ソースコード等の共有 – 変更履歴を記録、追跡（バージョン管理） –履歴の用途毎に分岐して管理（ブランチ） – 切り戻しが容易 • プルリクエスト（マージリクエスト）機能によ りレビューを可視化 • 他のツールとの連携 – Jenkins – Redmine 16
- 17.
- 18.
- 19. デモ環境について 『GitLab実践ガイド』を参考に • CentOS 8.1にGitLab13.0 Enterprise Editionをインストール – Enterprise Editionでもライセンスを有効にしな ければCommunity Edition相当（GitLab Core） – Omnibusインストールで必要なものがまとまっ て入ります – yum updateでアップデートできます 19
- 20. GitLabをインストールする • GitLabのWebページ 「OfficialLinux package (recommended installation)」を参考に環境を構築 – https://about.gitlab.com/install/#centos-8?version=ce – Kubernetesやクラウド上へのインストールも可能 1. GitLabのWebページ（https://about.gitlab.com/）の メニューから「Install GitLab」を選択 2. インストールしたいOS・環境を選択 3. 手順に従ってインストール 20
- 21. CentOS 8.1へのインストール 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/gitlab/gitlab- ee/script.rpm.sh | sudo bash 7. sudo EXTERNAL_URL="http://gitlab.example.com" yum install -y gitlab-ee 注）逆引き名前解決でコケるとconfigに失敗します 8. sudo EXTERNAL_URL="http://gitlab.example.com" gitlab- ctl reconfigure 21 ←必ず実行
- 22. GitLab 13インストールの注意点 • Let'sEncryptによるTLS化がデフォルトに – ドキュメントでのインストール時の EXTERNAL_URLの指定が"https://○○"に →オンプレ、ローカルIPアドレスだとLet's Encrypt のTLS証明書生成がコケてインストール失敗 – EXTERNAL_URLの指定を"http://○○"に • DNSの逆引き名前解決の設定が必要 – /etc/hostsではダメ – インストールスクリプト（Chef利用）がコケるので、 gitlab-ctl reconfigureの実行が必要 22
- 23.
- 24. GitLabの管理単位 ファイルサーバーと大体同じと思えばOK • ユーザー – 各開発者のアカウント •グループ – ユーザーをまとめた管理単位 • プロジェクト – ソースコードのリポジトリを含めた開発プロ ジェクトに必要なもの一式 – ユーザー、あるいはグループに紐付けられる 24
- 25. GitLabで初期設定作業 1. http://gitlab.example.comにアクセス 2. ユーザーrootのパスワードを設定 3.ユーザーrootでログイン 4. 新しいユーザーを作成 5. 指定したメールアドレスにメールが届く – http://gitlab.example.comへのリンクが埋め込まれ ている 6. 新規ユーザーのパスワード設定 7. 新規ユーザーでログイン 25
- 26. プロジェクト作成とクローン ユーザーtmiyaharを作成しています 1. 新規プロジェクトtestを作成 2. クライアントにリポジトリをクローン –git clone http://gitlab.example.com/tmiyahar/test.git • ユーザー認証が必要 26
- 27.
- 28. Gitのリポジトリ種別 • ローカルリポジトリ – 開発作業用クライアントに作成される –リモートリポジトリをクローンすると作成される • クローンが一番分かりやすい – 作業は他の開発者には影響しない • リモートリポジトリ – GitLab上に作成される – 各開発者で共有される 28
- 29. ローカルリポジトリの確認 • クローンしたリポジトリを確認 – $cd ~/test – $ ls -a – 現時点では空っぽです – .gitディレクトリが作られており、リポジトリの各 種情報が格納されている 29
- 30. ステージングとコミットの関係 30 作業用 ディレクトリ ステージング 領域 ローカル リポジトリ $ git checkout $git add $ git commit リポジトリは ブランチ毎の ファイルセットを 保持している master develop
- 31.
- 32. リポジトリにファイルを追加 1. 作業ディレクトリにファイルを追加 – $touch README.md 2. ファイルをステージング – $ git add README.md 3. ステージングしたファイルをコミット – $ git commit 4. コミットしたファイルをリモートにプッシュ – 同時にローカルリポジトリのアップストリーム設定 – $ git push --set-upstream origin master • masterブランチのアップストリームをリモートリポジトリの master（remotes/origin/master）に設定 32
- 33. リポジトリ操作実行例 $ 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. 33
- 34. ブランチの流れ 34 master develop ① $ gitbranch ③ $ git merge develop ②コミットを繰り返す
- 35. ブランチを作成する 1. ブランチの確認 – $git branch – 現時点ではローカルのmasterだけ 2. ブランチの作成 – $ git branch develop 3. ブランチの切り替え（チェックアウト） – $ git checkout develop – $ git checkout –b develop で作成＆移動も 4. ブランチの確認 – $ git branch – 作業しているブランチがdevelopに変更されている 35
- 36. ブランチ作成実行例 $ git branch *master $ git branch develop $ git checkout develop Switched to branch 'develop' develop branch $ git branch * develop master 36
- 37. 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ブランチでの修正が影響していない事を 確認 37
- 38. developブランチをマージする 1. developブランチをmasterにマージする – $git merge develop 2. README.mdを確認 – developブランチで行った修正が反映される • マージは取り込む側のブランチで行う – だから、取り込んで欲しいときは「マージ（プ ル）リクエスト」を作成する 38
- 39.
- 40. 修正の重複（コンフリクト）の解消 • git push時に既にリモートが更新されているとプッ シュに失敗する •git pullするとコンフリクト発生が通知され、対象と なるファイルが以下のようになる • 適切に修正し、再度コミット＆プッシュ 40 developブランチで修正 <<<<<<< HEAD ローカルのmasterブランチで修正 ======= Webブラウザで修正 >>>>>>> fcfafd335fd5d6a4bb8938c1c2dcbe17788debf5
- 41. コンフリクト解消手順 1. WebブラウザでREADME.mdを確認 – この時点では空っぽです 2.Editボタンを押して何か書く – 他のユーザーがpushしたのと同義 3. $ git push – Webブラウザの変更が取り込まれておらず失敗 4. $ git pull – コンフリクトが発生し、自動マージに失敗 5. README.mdを編集してコンフリクトを解消 6. 再度、コミット＆プッシュします – 今度は成功します 41
- 42. 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. 42
- 43. git pullするとコンフリクト発生 $ gitpull 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. 43
- 44. ブランチ戦略を考える よくある質問 • Q. 「どのブランチ戦略がいいんですか？」 •A. 「ケースバイケース」 • 考慮すべき事（順不同） – 開発者の人数や規模 – コミットやマージの頻度や粒度 – テストの頻度や方法 – リリースの頻度や方法 44
- 45. この先に考えたい事 • テスト駆動やチケット駆動との連携 • テストの自動化 –コードコミット→テスト→マージリクエストのサ イクルの自動化 – 粒度が小さいとマージ処理する人が大変 • チケットの自動化 – テスト失敗時に自動的にチケット発行 – テスト成功時に自動的にチケットクローズ 45
- 46.
- 47. DevOpsの想定される進め方 1. ToBeモデルの構築 2. 現時点での課題の抽出 3.優先順位の策定 4. PoC環境の構築と運用 5. PoC環境からのフィードバックと改善 6. 小規模社内展開 47 自社だけではスピード感のある DevOps推進は困難
- 48.
- 49. DevOpSaaSが解決する課題 標準リファレンスモデル提供によるDevOpsの加速 • 各種ツールの組み合わせテスト済みパッケージの提供 – 標準機能はあらかじめ設定済み •各種ツールのバージョンアップ追従 – 既存開発・運用環境からの移行支援 • 独自機能の提供 – 可視化ツール、既存ツールのカスタマイズなど • 開発運用担当者の教育・サポート – 標準ドキュメント、教育コースの提供 • サンプルの提供 – 自動化・テストスクリプトのサンプル
- 50. 提供される主な機能 • チケット管理 • ソースコード管理 •テスト自動化 • デプロイ自動化 • プロジェクトマネジメント • コミュニケーション 50
- 51. サポートされる環境 • 開発：GitHub/GitLab/Jenkins/Redmine – CircleCI •構成自動化：Ansible – CloudFormation • インフラ：Kubernetes – AWS EKS • 運用監視：Prometheus – DataDog • テスト自動化：Serverspec/Selenium 51※実案件で実績あり
- 52. 改めて大募集 • 一緒にDevOpsにチャレンジする企業 – 一緒にカイゼンしていきませんか？ •一緒にDevOpsにチャレンジするエンジニア – 一緒に成長していきませんか？ – 沢山の開発者を支えるお仕事です – マジで人手が足りてません – このままだと掛け声倒れになりかねない 52
- 53.