バージョン管理

1,758 views

Published on

バージョン管理というかGitのお話@パンゲア

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,758
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

バージョン管理

  1. 1. バージョン管理所属  adingo(Fluctチーム)Twitter @_zoo名前  Misa Kondo
  2. 2. 何故バージョン管理?
  3. 3. Webサービスここにいる人の大半はWebサービスと呼ばれるものの製造に関係するはず。Webサービスは、ペースの違いはあるけど、日々改修を加えていく。改修を加えていく中で必ずついて回るものがある。
  4. 4. バグ・障害
  5. 5. バグは必ず生まれるもの基本的にバグとは生まれるもの。テストをいくら入念にやろうと、どこかで生まれてしまうもの。と、考えていた方がよいです。少なくとも5年間開発していて、バグがなかったサービスはなかったです。
  6. 6. バグが出た!→修正します!修正するのはもちろんだけど、現状、本番で動いているものにバグがあるのはまずい。バグの重要度にもよるが、例えば、会員登録制のサービスで、ログイン機能や会員登録機能が使えないなんてありえない。
  7. 7. なので、流れとしてはこうバグが出た!↓バグが生まれていなかった時点までサービスを戻す↓
  8. 8. バグが生まれていなかった時点 、にきり戻さないといけない
  9. 9. 例えば、あるWebサービスで4月1日に春のキャンペーンのため、いくつかのページデザインを変更。GW前に新機能の追加をやることに。ユーザに向けた新機能の追加告知を4月5日にやり、リリース日は4月18日。
  10. 10. 予定通り4月18日リリース完了
  11. 11. だがしかし
  12. 12. リリース後2時間、バグ発生。
  13. 13. バグが生まれていなかった時点 、にきり戻さないといけない
  14. 14. バージョン管理していない場合4月1日にリリースされたもの latest4月5日にリリースされたもの latest4月18日にリリースされたもの latest
  15. 15. バグが生まれていなかった時点 = ????
  16. 16. バージョン管理している場合4月1日にリリースされたもの revision1014月5日にリリースされたもの revision1024月18日にリリースされたもの revision103
  17. 17. バグが生まれていなかった時点 = revision102
  18. 18. Gitによるバージョン管理 (分散バージョン管理)
  19. 19. Gitのインストール 下記のサイトにいき、各自の環境にあわ せてインストールしてください。 http://git-scm.com/
  20. 20. Gitの初期設定# user.nameとuser.emailの設定$ git config --global user.name "John Smith"$ git config --global user.email "john@gmail.com"# リポジトリ単位で設定する場合$ cd repository_dir$ git config user.name "janky"$ git config user.email "janky@gmail.com"
  21. 21. Gitリポジトリの作成# ディレクトリの作成$ mkdir sample# ディレクトリの移動$ cd sample# リポジトリの作成$ git initInitialized empty Git repository in〜↑が出力されれば成功
  22. 22. ファイルの作成# ファイルの作成$ touch README.md# ファイルの更新$ emacs README.md
  23. 23. コマンドで確認$ git status# On branch master# Initial commit# Untracked files:# (use "git add <file>..." to include in what willbe committed)# README.mdnothing added to commit but untracked filespresent (use "git add" to track)
  24. 24. 現在の状況
  25. 25. 新規のファイル
  26. 26. stageにあげる $ git add README.md $ git status # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached <file>..." to unstage) # new file: README.md
  27. 27. 現在の状況
  28. 28. ステージされている
  29. 29. Gitでの初コミット # コミット $ git commit -m コミットメッセージ $ git status # On branch master nothing to commit (working directory clean) # 確認 $ git log
  30. 30. 現在の状況
  31. 31. コミットされている
  32. 32. ローカルにgitリポジトリを作成$ git init何かファイルを作成$ touch README.mdファイルをコミット$ git add README.md$ git commit -m first commit
  33. 33. 全員が終了したら終わり
  34. 34. 複数人での開発リモートリポジトリとローカルリポジトリ
  35. 35. 複数人での開発作業・全員がローカルリポジトリで進めていたら、作業の共有ができない・中心となる中央リポジトリが必要・今回の研修ではGitHubに中央リポジトリを配置
  36. 36. リモートとローカル
  37. 37. GitHubのアカウント作成 既に持っている人も、今回のは社内用な ので会社のメールアドレスで私用とは別に 作成してください。 https://github.com/signup/free
  38. 38. GitHubのSSH鍵登録 下記の2つの作業を行う ・SSHの鍵を作成 ・作成した鍵の公開鍵をGitHubに登録 鍵の作成手順と、GitHubへの登録手順は ↓のサイトを参考にしてください。 http://help.github.com/linux-set-up-git/
  39. 39. GitHubのアカウント共有 これからの作業ではみんなで1つのリモー トリポジトリを編集する。 今作ったGitHubカウントを下記のスプレッ ドシートに追記する。 github研修用アカウントリスト
  40. 40. GitHubのリポジトリその1 まずはみんなでいじるリポジトリを手元に cloneして下さい。 https://github.com/VG-Tech- Dojo/git_command_sheet
  41. 41. リポジトリのClone$ git clone git@github.com:VG-Tech-Dojo/git_command_sheet.gitCloning into sample...remote: Counting objects: 3, done.remote: Total 3 (delta 0), reused 3 (delta 0)Receiving objects: 100% (3/3), 226 bytes, done.$ cd git_command_sheet$ git status# On branch masternothing to commit (working directory clean)
  42. 42. リモートの情報$ git config --listuser.name=MisaKondouser.email=Misa_Kondo@voyagegroup.comremote.origin.fetch=+refs/heads/*:refs/remotes/origin/*remote.origin.url=git@github.com:VG-Tech-Dojo/git_command_sheet.gitbranch.master.remote=originbranch.master.merge=refs/heads/master
  43. 43. Member.mdを編集、コミット変更をリモートに反映$ git push -u origin masterCounting objects: 5, done.Delta compression using up to 8 threads.Compressing objects: 100% (2/2), done.Writing objects: 100% (3/3), 663 bytes, done.Total 3 (delta 0), reused 0 (delta 0)To git@github.comVG-Tech-Dojo/git_command_sheet.git4a679c0..430a223 master -> master...以下略
  44. 44. このメッセージが出た人To prevent you from losing history,non-fast-forward updates wererejectedMerge the remote changes (e.g. gitpull) before pushing again. See theNote about fast-forwards section ofgit push --help for details.
  45. 45. 訳すと履歴を失わない為non-fast-forwardの更新が拒否されました。pushする前に、リモートの変更をgit pullで取り込みましょう。詳しくは、git push --helpで表示されるNote about fast-forwardsの節を読み
  46. 46. gitの更新はfast-forwardが基本・fast-forwardが基本↓・non-fast-forwardが忌避されている↓・何故なのか?↓・履歴が失われるから
  47. 47. fast-forward(高速前進) ’git push’ OK!リモート A B Cローカル A B C D
  48. 48. non-fast-forward(非高速前進) ’git push’ NG!リモート A B C Dローカル A B C D
  49. 49. 履歴を失うとはどういうことか
  50. 50. 家系図を見てみるhttps://github.com/VG-Tech-Dojo/git_command_sheet/network
  51. 51. このメッセージが出た人To prevent you from losing history,non-fast-forward updates wererejectedMerge the remote changes (e.g. gitpull) before pushing again. See theNote about fast-forwards section ofgit push --help for details.
  52. 52. $ git push -uf origin master
  53. 53. 再度家系図を別タブで開いてみるhttps://github.com/VG-Tech-Dojo/git_command_sheet/network
  54. 54. non-fast-forward(非高速前進)リモート ’git push -f’ すると A B C D A B C Dローカル A B C D
  55. 55. 履歴が失われてしまう履歴を失う=作業内容の紛失$ git push -f remote_name branch_name↑の-fはforceオプションの略で、強制的にpushするという意味です。
  56. 56. gitの更新はfast-forwardが基本git pullでremoteの変更をとりこむ↓(コンフリクトが発生したら、解消する)↓git pushでremoteを更新
  57. 57. non-fast-forwardとなったら # リモートブランチの変更を取り込む $ git pull origin master # リモートに反映 $ git push -u origin master
  58. 58. 自分のコミットが消えた人今回は下記の手順でやりなおす。$ cd ..$ rm -rf git_command_sheet$ git clone git@github.com:VG-Tech-Dojo/git_command_sheet.git$ cd git_command_sheet
  59. 59. このメッセージが出た人Auto-merging Members.mdCONFLICT (content): Merge conflictin Members.mdAutomatic merge failed; fix conflictsand then commit the result.
  60. 60. 訳すと自動マージに失敗しました。競合を解決してから、コミットして下さい。
  61. 61. コンフリクト対応方法$ git status# コンフリクトファイルを編集$ emacs Members.md# 編集が終わったら、再度commit$ git add Members.md$ git commit -m commit_message$ git push -u origin master
  62. 62. コンフリクトファイルの中身# 中略M.K<<<<<<< HEAD ローカルの変更内容Y.K======= リモートから取得した変更内容T.K>>>>>>>1994380b1e2eac0b8a8256135d57259d8f84954e
  63. 63. コンフリクトファイルを編集M.KT.K リモートから取得した変更内容Y.K ローカルの変更内容
  64. 64. Member.mdに全員のイニシャルが記入されたら終了
  65. 65. 休憩15分
  66. 66. 複数人での並行開発 ブランチでの作業
  67. 67. 複数人での並行開発作業・masterブランチはリリースされたものを管理する・開発段階のソースを管理するブランチが必要・開発といっても、一つではなくバグ修正・機能追加など、いくつもの作業が並行して走る
  68. 68. そこで、ブランチを活用下記の線1本=1ブランチ並行して複数の開発が進む
  69. 69. ブランチの作成と確認# 今いるブランチの確認$ git branch* master# 自分用の開発ブランチを作成する。$ git branch mk_develop# mk_developブランチの作成$ git branch* master
  70. 70. 今のブランチの状態
  71. 71. ブランチの切り替えとpush# ブランチの切り替え$ git checkout mk_developSwitched to branch mk_develop# 今いるブランチを確認$ git branch master* mk_develop# remoteへのブランチ反映$ git push origin mk_develop
  72. 72. 今のブランチの状態
  73. 73. 自分用の開発ブランチを作成$ git branch your_branchブランチの確認$ git branchブランチをpush$ git push origin your_branch
  74. 74. 全員が終了したら、家系図を見てみるhttps://github.com/VG-Tech-Dojo/git_command_sheet/network
  75. 75. 開発用ブランチに切り替え$ git checkout your_branchファイルを追加、編集$ git add your_file$ git commit -m messageリモートへの反映$ git push origin your_branch
  76. 76. 今のブランチの状態
  77. 77. 全員が終了したら、家系図を見てみるhttps://github.com/VG-Tech-Dojo/git_command_sheet/network
  78. 78. masterへのmerge ・開発ブランチでの作業が終了 ↓ ・masterブランチに変更を取り込む ↓ ・リモートへの反映
  79. 79. masterブランチに切り替え$ git checkout master変更を取り込む$ git merge your_branchリモートへの反映$ git push origin master
  80. 80. 全員が終了したら、家系図を見てみるhttps://github.com/VG-Tech-Dojo/git_command_sheet/network
  81. 81. 休憩15分
  82. 82. 課題その1
  83. 83. 最初にみんなで編集した リポジトリを見てみよう https://github.com/VG-Tech-Dojo/git_command_sheet/network
  84. 84. masterがなんか汚いね
  85. 85. 綺麗な一直線の線の方がいい
  86. 86. 課題その1(ノーマル)・4〜5人でグループを作る・テーブルにチーム番号をふる・チーム番号xのリポジトリをcloneする$ git clone git@github.com:VG-Tech-Dojo/teamX.git
  87. 87. networkが綺麗に一直線になれば終了
  88. 88. 課題その2
  89. 89. 課題その2(ハード)下記のリポジトリをcloneする$ git clone git@github.com:VG-Tech-Dojo/git_manual.git
  90. 90. 課題その2(ハード)masterブランチの2番目のコミットとして、developのコミットを取り込む。masterは変わらず一直線。developのブランチもそのまま存在する。
  91. 91. 下記のネットワーク図ができれば終了

×