Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

プログラミング勉強会「オトナのGit入門」

706 views

Published on

2017年8月16日に熊本で開催されたプログラミング勉強会「オトナのGit入門」の資料です。

Published in: Software
  • Be the first to comment

プログラミング勉強会「オトナのGit入門」

  1. 1. オトナのGit入門 2017年8月16日 山ノ内祥訓 ~ バージョン管理はプログラマーのたしなみ ~
  2. 2. 自己紹介 名前 年齢 住まい お仕事 山ノ内 祥訓(よしのり) 0x25 熊本県 現在は某大学病院の特任助教で臨床研究のデータ マネージャとして主に臨床研究データに関する設 計及び開発と運用をやっています。 某SIerで医療情報システムの導入及び開発を10年 ぐらいやっていました。 SNS Facebook https://www.facebook.com/yoshinori.yamanouchi.12 Github https://github.com/eolla1013 資格等 修士(医科学) 現在博士課程 医療情報技師 Yoshinori Yamanouchi
  3. 3. 今日のお話 バージョン管理ついての基礎 Gitのしくみ Gitの基本的な使い方 Gitを使った開発基盤の構築
  4. 4. さて問題です。 どのファイルが最新でしょうか
  5. 5. ファイルの履歴管理 ファイルの変更履歴を残すためにファイル名を変えてみたり フォルダに分けて保存してみたりというルールを決めていると ころは多い・・・はず。 また、日々のバックアップをとることで間違えて修正したりし たときに元に戻せるようにしているところもある・・・はず。 でもこれをルール付けして運用していくのは なかなか難しいのが実情。 運用でカバーにも限界がある!
  6. 6. そこで生まれたのがバージョン管理 バージョン管理というのはファイルの変更履歴を保存してお きその変更部分を確認できるようにしたり、昔のファイルに 戻したりするためのシステムのこと。 これを導入することにより変更にまつわる課題の解決がしや すくなります。 最近はファイルのバージョン管理以外にもいろいろ機能があ るので構成管理と呼ばれることもあります。
  7. 7. バージョン管理システムいろいろ  CVS  Subversion  Git  Mercurial  Visual Source Safe(VSS)  Team Foundation Server(TFS) ※他にもたくさんありますが、自分が使ったことがあるものを載せています。
  8. 8. 更新方法による違い  ロック方式 まず最初にファイルをチェックアウトすると、そのファイル はロック状態となり他の人は編集できなくなる。 自分で編集後チェックインすることで大元のファイルを更新 し、更新が終わるとロックが解除されて他の人が編集できる。 ロックされると他の人が触れないので更新待ちが発生する。 ・・・解除し忘れて帰る人もww チェックアウト チェックイン 編集 ロック この期間は チェックアウト した人以外編集 できない
  9. 9. 更新方法による違い  コピー・マージ方式 最初にチェックアウトしてもそのファイルはロックされずに 他の人が編集できる。 自分で編集後チェックインするときにリポジトリのファイル と比較し違いがある場合はファイルの内容をマージしてから リポジトリのファイルを更新する。 マージできるファイル形式(基本的にテキスト形式)でないと 上書きするしかない。 チェックアウト マージ 編集 この期間は他の 人も編集できる コミット
  10. 10. 構造による違い  集中型 大元のファイル置き場(リポジトリという)は1つで、すべ てのメンバーはリポジトリから自分の作業コピーにファ イルをチェックアウトして編集作業を行う。 作業結果はコミット(チェックイン)することでリポジト リのファイルが更新される。 リポジトリが1つなので必ずネットワーク経由で作業をす ることになる。 リポジトリ 作業コピー 作業コピー 作業コピー
  11. 11. 構造による違い  分散型 リポジトリは1つではなく複数個所に置くことができる。 メンバーは必要なリポジトリから自分のリポジトリに ファイルをクローンして編集作業を行う。 作業結果は自分のリポジトリにコミットしたあとに任意 のリポジトリへコミット(プッシュ)することができる。 リポジトリA ローカル リポジトリ リポジトリB ローカル リポジトリ 作業コピー 作業コピー
  12. 12. 更新単位による違い  ファイル単位 ファイル一つ一つについてバージョン番号を持っている。 同じタイミングでコミットしても、これまでの更新回数 によってファイル毎に異なるバージョン番号が振られる。 ファイルA Ver1 ファイルB Ver1 ファイルC Ver1 ファイルA Ver2 ファイルA Ver3 ファイルB Ver2 ファイルA Ver4 ファイルB Ver3 ファイルC Ver2 コミット1 コミット2 コミット3 コミット4
  13. 13. 更新単位による違い  チェンジセット単位 ファイル単位ではなくリポジトリ単位にどこにどんな更新が あったかを記録する方式。ファイル毎ではなく1回のコミッ トに含まれる複数のファイルをまとめて一つのバージョン番 号が振られる。このファイルのグループをチェンジセット (変更セット)という。 ファイルA Ver1 ファイルB Ver1 ファイルC Ver3 ファイルA Ver2 ファイルA Ver3 ファイルB Ver3 ファイルA Ver4 ファイルB Ver4 ファイルC Ver4 コミット1 コミット2 コミット3 コミット4
  14. 14. 今回勉強するGitは・・・ 分散型のバージョン管理システムとなります。 更新方式はコピー・マージ方式で、 チェンジセットで履歴管理されます。 https://git-scm.com/ GitはもともとLinuxの開発管理を行うために開発されたオープ ンソースのバージョン管理システムです。OSという大規模ソフ トウェアの開発に使われているだけあって高速に動作し信頼性 の高いソフトウェアといわれています。 ちなみに当初はLinuxの開発者であるリーナス・トーバルズさん がメインコミッタでしたが、現在は濱野純さんとなっています。
  15. 15. Gitの大まかな仕組みと主な用語 作業コピー ローカル リポジトリ リモート リポジトリ ブランチ クローン(初回のみ) プル (フェッチ) プッシュ コミット ステージング (トラック) チェックアウト マージ ブランチ コンクリフト ※説明用に一部簡略化していますので注意!! アンステージング
  16. 16. Gitの大まかな仕組みと主な用語 ※説明用に一部簡略化していますので注意!! コミット ブランチ ヘッド マージ time タグVer1.0
  17. 17. Gitの基本操作 1. 配布したユーザ名、パスワードで Cloud9(https://c9.io/)にログイン。 2. otona_gitというプロジェクトを開く。 3. 下に表示されているコンソールエリアを中心に使います。 枠が小さいので適宜広げてください。 4. バージョン管理したいフォルダの作成と初期化 mkdir localgit cd localgit git init
  18. 18. Gitの基本操作(ファイルの追加) 1. 左側のファイルツリーからlocalgitフォルダ に”hello.py”のファイルを作成。 2. とりあえずprint文を1行書いて保存。 3. ファイルをバージョン管理対象としてコミット。 git status git add hello.py git status git commit –m “最初に作成したファイルです” git status
  19. 19. Gitの基本操作(ファイルの更新) 1. ”hello.py”の内容を書き換えて保存。 2. 差分を確認してコミット。 3. 新しいファイル”world.py”を作成。こちらもprint文を1 行書いて保存。 4. 追加ファイルのステージングと更新分のコミット。 git diff git commit –a –m “更新したファイルです” git status git add world.py git commit –a –m “追加したファイルです” git status
  20. 20. Gitの基本操作(履歴の確認) 1. これまでの更新履歴を確認。 2. 最後のコミット情報の確認。 git log git show
  21. 21. Gitの基本操作(ファイルの復旧) 1. “world.py”を左のツリーから削除。 2. ファイルが削除状態となっていることを確認。 3. 作業コピーの変更をすべて元に戻す。 4. “world.py”が元に戻っていることを確認。 git status git reset --hard
  22. 22. Gitの基本操作(コミット取消) 1. 取り消したい履歴を確認。 2. hello.pyを更新した履歴のハッシュ値を使用してコミッ トを取り消す。 3. 取り消した内容がコミットしてあることを確認。 4. Hello.pyを開いて元に戻っていることを確認。 git log git revert %ハッシュ値% git status git log
  23. 23. Gitの基本操作(過去の作業コピー) 1. 取り消したい履歴を確認。 2. 履歴のハッシュ値を使用してチェックアウト。 3. 最新の状態に戻す。 git log git checkout %ハッシュ値% git checkout master ※過去の状態で編集作業を進めたい場合は次の説明にあるブランチ機 能を使用し、一時作業ブランチを作成して編集後に元のブランチに マージすること。
  24. 24. ブランチの操作(ブランチの作成) 1. dev1というブランチを作成。 2. 現在のブランチ一覧を表示。 3. 作業コピーをdev1に切り替え。 4. 現在のブランチが切り替わったことを確認。 git branch dev1 git branch git checkout dev1 git branch
  25. 25. ブランチの操作(ブランチの更新) 1. hello.pyの内容を変更。 2. 変更をコミット。 git add *.py git commit -m "開発ブランチでの変更"
  26. 26. ブランチの操作(元ブランチの更新) 1. 元のブランチに切り替え。 2. hello.pyを変更。 3. 変更したファイルをコミット。 git checkout master git branch git add *.py git commit -m "マスタブランチでの変更"
  27. 27. ブランチの操作(ブランチのマージ) 1. 現在のブランチ(master)に開発ブランチ(dev1)をマー ジ。 2. コンクリフトを起こしていることを確認。 3. hello.pyを開いて修正。 4. 変更したファイルをコミット。 git merge dev1 git status git diff git commit -a -m "開発ブランチのマージ"
  28. 28. ブランチの操作(ブランチの削除) 1. 開発ブランチ(dev1)を削除。 git branch -d dev1 git branch
  29. 29. これまでの操作履歴を見てみる git logで確認
  30. 30. リモートリポジトリを使う これまでは全て自分のローカルリポジトリだけで操作しま したがこれからはリモートリポジトリを使って操作します。 別のフォルダに移って下さい。 cd .. mkdir rmtgit cd rmtgit
  31. 31. リモートリポジトリの取得 1. 下記URLのgitリポジトリをクローン。 2. リポジトリフォルダへ移動。 git clone http://174.138.24.29/otona/samplegit.git cd samplegit
  32. 32. リモートリポジトリの最新化 1. リモートリポジトリから最新の状態を取得。 git pull
  33. 33. リモートリポジトリの最新化 1. リモートリポジトリから最新の状態を取得。 git pull ※こちらでファイルを修正しますので 修正後実行してください。
  34. 34. リモートリポジトリへの更新 1. 自分のユーザ名(%username%の部分を変更)でファイ ルを作成。 2. 作成したファイルをコミット。 3. コミットした内容をリモートリポジトリに送信。 git add %username%.py git commit -m "%username%のファイルを追加" git push ※push時にユーザ名とパスワードを聞かれるので Cloud9のユーザ名とパスワードを入力してください
  35. 35. リモートリポジトリへの更新 1. 何人かの人はpush時にエラーになったはずです。この エラーを解消するため何回かpullとpushを繰り返します git pull git push ※ファイル名を%%のままにしたり、他の人のファ イル名と重複していたらコンクリフトが起きます。 その場合はTAへ
  36. 36. 共同作業の基本 リモートリポジトリの基本操作が分かったところで共同作 業を行う上でよく使う操作をします。 操作の流れは以下のようになっています。 1.自分の作業ブランチの作成 2.自分の作業ブランチでファイルを更新 3.最新のリモートmasterブランチのマージ 4.作業完了時のプッシュ 5.masterブランチへのマージ(講師デモ)
  37. 37. 共同作業の基本(作業ブランチ作成) 1. 自分の作業用ブランチを作成。 2. 作業コピーを自分の作業用ブランチに切り替え。 git branch develop%username% git checkout develop%username%
  38. 38. 共同作業の基本(ブランチの更新) 1. hello.pyの内容を変更。 2. 自分が追加したファイルを変更。 3. 変更した内容をコミット。 4. コミットした内容をリモートリポジトリに送信。 git commit -a -m "dev%username%でファイル更新“ git push --set-upstream origin develop%username%
  39. 39. 共同作業の基本(最新のマージ) 1. 最新のリモートリポジトリを取得。 2. 最新のリモートブランチをマージ。 3. 多分コンクリフトしているのでhello.pyを変更。 4. 変更した内容をコミット 5. コミットした内容をリモートリポジトリに送信。 git pull git merge origin/master git commit –a –m “helloへのマージ” git push origin
  40. 40. 共同作業の基本(統合マージ) 1. 最新のリモートリポジトリを取得。 2. masterブランチに切り替え。 3. 各作業ブランチの内容をマージ。 4. 変更した内容をコミット 5. コミットした内容をリモートリポジトリに送信。 git pull git checkout master git merge develop%username% git commit -a -m “develop%username%の内容を マージ" git push ※講師側作業
  41. 41. ブランチ開発の種類 個人や数名で小規模な開発を行う場合であればmasterブラ ンチにすべての変更を反映させてもよいですが、自社パッ ケージやサービスの開発など一般的な開発業務を行うので あれば先ほどのようなブランチを駆使した開発を行ったほ うがミスが少なく早い開発速度が望めます。 ここではいくつかの開発のパターンを紹介します。
  42. 42. Github flow githubで開発するときによく使われる開発フローです。 http://scottchacon.com/2011/08/31/github-flow.html https://gist.github.com/Gab-km/3705015 (日本語訳) シンプルな6つのルールで構成されているので一番わかり やすいと思います(注プルリクエストはGithubの機能)。 1. masterブランチのものは何であれデプロイ可能である 2. masterから説明的なブランチを作成する 3. 名前をつけたブランチに定期的にpushする 4. いつでもプルリクエストを作る 5. マージはプルリクエストがレビューされた後だけ 6. レビューのあとは直ちにデプロイする
  43. 43. Github flow master いつでもデプロイ(リリース)可能 new-func プルリクエストでレビュー依頼 レビュー完了時にマージ Issue1234 1タスク1ブランチで作業
  44. 44. Git flow Gitで大規模開発を行う場合のフローです。 https://jeffkreeftmeijer.com/2010/why-arent-you- using-git-flow/ http://keijinsonyaban.blogspot.jp/2010/10/a- successful-git-branching-model.html (日本語訳) 各ブランチがそれぞれの目的をもっています。一見複雑で すが担当ごとに触るブランチが決まりますので管理しやす いと思います。 1. リリースされたものを保持するmasterブランチ 2. 現在の新規開発を行うdevelopブランチ 3. 機能開発を行うために作成するfeatureブランチ 4. リリース準備作業を行うために作成するreleaseブランチ 5. リリース済のものを修正するために作成するhotfixブランチ
  45. 45. Git flow 「A successful Git branching model」 より引用 更新できるブランチ ・開発担当 →develop feature ・リリース担当 →release master ・保守担当 →hotfix develop
  46. 46. その他のブランチ開発 master 複数バージョンのシステムを並行開発するときの例。 developブランチは必要に応じて作成。 version1 version2 開発のメインブランチ version1の開発凍結で分岐 version1のバグフィックスをマージ version2の開発凍結で分岐 version1-dev1 version1リリース
  47. 47. その他のブランチ開発 master さらにユーザごとのカスタマイズがある場合の例 version1 version2 開発のメインブランチ userA userB userBの開発開始で分岐 userAの開発開始で分岐 userAリリース userBリリース
  48. 48. 他のツールと連携する gitではコミットやプッシュなどいくつかのイベントが 発生したときに特定のスクリプトを実行する「フック」 という機能があります。この機能を使用することで開発 に関わるいろんな付随作業が自動化できます。 gitのフックはリポジトリフォルダにある.git/hooksとい うフォルダに格納されます。 連携の例)  pre-commitでコードの静的チェックを行う。  post-commitやpost-receiveフックで変更内容を通 知する。  post-checkoutでバージョン管理外で必要なファイル のダウンロードや環境設定を行う。  post-receiveでビルドを実行する。
  49. 49. 継続的インテグレーション(CI) CI(Continuous Integration)とは前回の勉強会で出てき たアジャイル開発のなかでXP(Extreme Programming) といわれるもののプラクティスの一つ。コードの実装、 ビルド、テスト、リリースのサイクルを継続的に実行で きる環境を整えることでソフトウェアの品質と納期の短 縮を目指すこと。 このCI環境を構築するうえでgitなどのバージョン管理 システムとその連携を行うシステムを組み合わせが重要 になります。
  50. 50. CIの構成例 開発者 (1)プッシュ (2)リリース/ビルド リクエスト (7)結果通知 (3)ビルド実行 ビルドサーバ リリースリポジトリ (4)リリース ファイル送信 (5)リリース実行 (6)最新リリース取得 &デプロイ ※このほかに毎日夜間処理で(4)まで実行するなどのパターンを作成できる。
  51. 51. バージョン管理外のファイル gitでは通常フォルダ内のすべてのファイルをバージョ ン管理下に置きますが、証明書ファイルや、巨大なバイ ナリファイル、中間ファイルなど、バージョン管理下に 置くと問題があるファイルを除外することができます。 除外したいファイルを「.gitignore」というファイルに 記載しておくとこのフォルダ以下が除外対象となります。 特定の拡張子は除外したい 特定のフォルダは除外したい *.suo *.user [Dd]ebug/ [Oo]bj/
  52. 52. GUIツール 今回の勉強会では基本ということでgitコマンドでの操 作を行いました。 が、実際はほとんどコマンドを打つことはなく画面上で 操作できるツールがたくさんあります。 GUIツールについてはOSやそれぞれの開発環境によっ て大きく異なるため今回は紹介だけしておきます。 https://git-scm.com/downloads/guis 統合開発環境(IDE)の付属 Windows Mac Visual Studio, eclipse, Xcode, … SourceTree, TortoiseGit, … SourceTree, gitk, tower, …
  53. 53. gitの最近の話題 つい先日(8/10)gitの脆弱性が発見されています。とい うよりSVNやCVS、Mercurialといった他のシステムと 共通の脆弱性で、clone時に任意のシェルスクリプトが 実行されてしまう、というものです。 CVE-2017-1000117で検索するといろいろでてきます。 http://blog.recurity-labs.com/2017-08-10/scm-vulns https://access.redhat.com/security/cve/cve-2017-1000117 https://oss.sios.com/security/git-security-vulnerabiltiy-20170813 修正されたgitのバージョンは2.14.1です。 まだ最新のバージョンに置き換えていない人は勉強会後に 最新化をお願いします。
  54. 54. 参考資料 gitに関してはWeb上の資料が充実しています。下記の URLあたりを一通り読めば問題なく使えると思います。 サルでもわかるGit入門 http://www.backlog.jp/git-guide/ こっそり始めるGit/GitHub超入門 http://www.atmarkit.co.jp/ait/series/3190/ https://codeiq.jp/magazine/category/git-ai/ マンガでわかるGit

×