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が解決してくれるもの
なぜGitとGitHubを
選んだのかの話です
Git、GitHubの
詳しい機能は後ほど
Git講習、GitHub Flow講習にて
ケース1
会議にGoogleDriveを使用
理由
• 無料
• リアルタイムで共有ができる
• みんなで書き込めるのですぐ修正できる
• 複数ファイルをおける
問題点
• ファイル編集合戦になる
• 変更点がぱっと見で分からない
• ネットに常時繋がってないといけない
• 1ファイル単位でしか共有できない
プラクティス
リアルタイム編集共有である必要はない
• ファイルを編集しながら議論をするやつはいない
• 反映が遅れてコンフリクトが起きると厄介なことに
• 議事録を書く人は一人でいい
• アイデアを全て一つのところにまとめて一緒に議論する
の...
Gitが解決する点
• GitHubやGitLabでイシュー、プルリクエストにて
アイデア単位で議論ができる
• アイデアが取り込まれたか瞬時に判定できるし細か
い情報も確認できる
• フックを使ってメールを飛ばしたりもできる
結論
GoogleDriveはクソ
ケース2
Dropboxでチームコードを共有
理由
• 無料
• フォルダ単位の共有
• 自分たちは何もする必要がない
• 変更されたファイルが分かる
• 復旧もできる
問題点
• 細かい変更点がわからない
• よくコンフリクトが起きる
• スワップファイルが共有される
• なんしろ共有が重い
• 2GBの容量制限
• 古いバージョンの保持ができない
• れるファイルの履歴に制限
プラクティス
Dropbox上での開発のノウハウを
貯めるぐらいならファイル共有システム使え
• Dropbox便利だが微妙なところでクールじゃない
• Dropboxに金貢がなくてももっと安くもっとクー
ルなサービスがあるよ
• ぶっちゃけ固...
Gitが解決する点
• ブランチ機能によってバージョンごとに開発できる
• リポジトリ容量は、通常無制限
• 共有のスピードも速い
• 履歴を るのは簡単だし、復旧も簡単
• コンフリクトも解決しやすいし、共有するファイル
の指定も楽にできる
結論
Dropboxは
個人利用に限りましょう
ケース3
Subversionを使用
理由
• いろんなところが使ってた
• なんか便利らしい
• 変更にメッセージつけたりできるらしい
• ブランチなどの機能があるよ
問題点
• 諸々の細かい箇所でクールじゃない
• 共有場所に常時つながってないといけない
• フォークするのが簡単じゃない
• ダウンロード速度の問題は少しは解決したが完全で
はない
プラクティス
集中型は分散型にいろんな点で劣る
• 分散型でも集中型の代用ができる
• 集中型の問題解決版が分散型なので分散型の方が新
しい恩恵が受けられる
• もうSubversionの時代ではない
Gitが解決する点
• 高性能のマージ、高性能のブランチ
• プルリクエストとフォークによる分散した開発
• 細かい履歴制御
• クールな気持ちよさ
結論
集中型の時代は終わった
ケース4
Mercurialだけでのチーム開発
• MercurialはGitと同じくクールな分散型バージョン
管理システム
• リモートリポジトリが公開されていてそっからクロー
ンしてプルプッシュ
• まあ、それでもいいんだけども
問題点
• どのブランチがどういう作業なのかぱっと見分からん
• エクステンションが分散しすぎて死んじゃう∼∼∼
• リモートリポジトリのコードだけ見るってことがしにくい
• 新たにプロジェクトに加わった人が取り残される
• 事故が絶えない
プラクティス
分散型バージョン管理システムはクールだが
それだけでは全ての問題を解決できない
• 今有名なのがチケット駆動開発(git flow)
• GitHub、BitBucket、Jira、etc.
• GitLab、Redmine、etc.
ケース5
RedmineでのGit Flowを使った開発
理由
• チケット駆動開発により管理がしやすい
• 大規模なプロジェクト用の様々な機能がそろってる
• GUIで見やすい
• 環境構築が簡単
問題点
理由
• 取り決めが多く導入コストがとても高い
• サーバーのメンテナンスコストが高い
• 微妙にRedmineの機能が優秀じゃない
• 他の人の作業内容を追いにくい
プラクティス
厳密すぎるのは良くない
• Git flowは非常に多くの取り決めがある
• それを実現するためには、多くの知識とノウハウが
必要
• 大規模なプロジェクトには向いているが、小規模に
はちょっとビミョい
• 過去の資源がないと難しい
プラクティス
良い感じの機能がまとめられても
一つ一つがクソだと役に立たない
• GitHubと連携するぐらいならGitHubオンリー
• プラグイン書かなくても代用品あるよ
• 高品質でなければまとめられると逆にメンテが大変
• 一つで済むよ...
GitHub flowが解決する点
• GitHubはクール
• GitHubはシンプル(すぎる?)
• GitHub flowは、お互いの作業の共有を目指してる
• GitHub flowは、簡単で覚えることが少ない
結論
Redmineはないわー
Git flowは経験ある人向け
Git
• オープンソース
• 分散型バージョン管理システム
• 今デファクトに
• クールで良い
GitHub
• パブリックリポジトリは無料
• プライベートリポジトリは学生プランだと20個まで無料、通
常は有料
• なんか割と かってるらしい
• いっぱい機能がある
• 最近社内用のエディタAtomが で流行ってる
• GitLabはG...
GitとGitHubが
どういう機能で
今までの問題を解決するのか
ここからは
お勉強の時間だよっ!よっ!
Upcoming SlideShare
Loading in …5
×

Gitpractice01

297 views

Published on

プロジェクトでのGit講習資料です

Published in: Engineering
  • Login to see the comments

Gitpractice01

  1. 1. チーム開発の プラクティス Gitが解決してくれるもの
  2. 2. なぜGitとGitHubを 選んだのかの話です
  3. 3. Git、GitHubの 詳しい機能は後ほど Git講習、GitHub Flow講習にて
  4. 4. ケース1 会議にGoogleDriveを使用 理由 • 無料 • リアルタイムで共有ができる • みんなで書き込めるのですぐ修正できる • 複数ファイルをおける
  5. 5. 問題点 • ファイル編集合戦になる • 変更点がぱっと見で分からない • ネットに常時繋がってないといけない • 1ファイル単位でしか共有できない
  6. 6. プラクティス リアルタイム編集共有である必要はない • ファイルを編集しながら議論をするやつはいない • 反映が遅れてコンフリクトが起きると厄介なことに • 議事録を書く人は一人でいい • アイデアを全て一つのところにまとめて一緒に議論する のはまちがっている • 瞬時に反映する必要はなく、チェックの際確認できたら それでいい
  7. 7. Gitが解決する点 • GitHubやGitLabでイシュー、プルリクエストにて アイデア単位で議論ができる • アイデアが取り込まれたか瞬時に判定できるし細か い情報も確認できる • フックを使ってメールを飛ばしたりもできる
  8. 8. 結論 GoogleDriveはクソ
  9. 9. ケース2 Dropboxでチームコードを共有 理由 • 無料 • フォルダ単位の共有 • 自分たちは何もする必要がない • 変更されたファイルが分かる • 復旧もできる
  10. 10. 問題点 • 細かい変更点がわからない • よくコンフリクトが起きる • スワップファイルが共有される • なんしろ共有が重い • 2GBの容量制限 • 古いバージョンの保持ができない • れるファイルの履歴に制限
  11. 11. プラクティス Dropbox上での開発のノウハウを 貯めるぐらいならファイル共有システム使え • Dropbox便利だが微妙なところでクールじゃない • Dropboxに金貢がなくてももっと安くもっとクー ルなサービスがあるよ • ぶっちゃけ固定ファイル共有したいならストレージ サービス使えばいいじゃない • 個人ファイルを共有するには便利
  12. 12. Gitが解決する点 • ブランチ機能によってバージョンごとに開発できる • リポジトリ容量は、通常無制限 • 共有のスピードも速い • 履歴を るのは簡単だし、復旧も簡単 • コンフリクトも解決しやすいし、共有するファイル の指定も楽にできる
  13. 13. 結論 Dropboxは 個人利用に限りましょう
  14. 14. ケース3 Subversionを使用 理由 • いろんなところが使ってた • なんか便利らしい • 変更にメッセージつけたりできるらしい • ブランチなどの機能があるよ
  15. 15. 問題点 • 諸々の細かい箇所でクールじゃない • 共有場所に常時つながってないといけない • フォークするのが簡単じゃない • ダウンロード速度の問題は少しは解決したが完全で はない
  16. 16. プラクティス 集中型は分散型にいろんな点で劣る • 分散型でも集中型の代用ができる • 集中型の問題解決版が分散型なので分散型の方が新 しい恩恵が受けられる • もうSubversionの時代ではない
  17. 17. Gitが解決する点 • 高性能のマージ、高性能のブランチ • プルリクエストとフォークによる分散した開発 • 細かい履歴制御 • クールな気持ちよさ
  18. 18. 結論 集中型の時代は終わった
  19. 19. ケース4 Mercurialだけでのチーム開発 • MercurialはGitと同じくクールな分散型バージョン 管理システム • リモートリポジトリが公開されていてそっからクロー ンしてプルプッシュ • まあ、それでもいいんだけども
  20. 20. 問題点 • どのブランチがどういう作業なのかぱっと見分からん • エクステンションが分散しすぎて死んじゃう∼∼∼ • リモートリポジトリのコードだけ見るってことがしにくい • 新たにプロジェクトに加わった人が取り残される • 事故が絶えない
  21. 21. プラクティス 分散型バージョン管理システムはクールだが それだけでは全ての問題を解決できない • 今有名なのがチケット駆動開発(git flow) • GitHub、BitBucket、Jira、etc. • GitLab、Redmine、etc.
  22. 22. ケース5 RedmineでのGit Flowを使った開発 理由 • チケット駆動開発により管理がしやすい • 大規模なプロジェクト用の様々な機能がそろってる • GUIで見やすい • 環境構築が簡単
  23. 23. 問題点 理由 • 取り決めが多く導入コストがとても高い • サーバーのメンテナンスコストが高い • 微妙にRedmineの機能が優秀じゃない • 他の人の作業内容を追いにくい
  24. 24. プラクティス 厳密すぎるのは良くない • Git flowは非常に多くの取り決めがある • それを実現するためには、多くの知識とノウハウが 必要 • 大規模なプロジェクトには向いているが、小規模に はちょっとビミョい • 過去の資源がないと難しい
  25. 25. プラクティス 良い感じの機能がまとめられても 一つ一つがクソだと役に立たない • GitHubと連携するぐらいならGitHubオンリー • プラグイン書かなくても代用品あるよ • 高品質でなければまとめられると逆にメンテが大変 • 一つで済むようにまとめたのに、API叩いて別のと ころで操作とか頭おかしいんじゃないの
  26. 26. GitHub flowが解決する点 • GitHubはクール • GitHubはシンプル(すぎる?) • GitHub flowは、お互いの作業の共有を目指してる • GitHub flowは、簡単で覚えることが少ない
  27. 27. 結論 Redmineはないわー Git flowは経験ある人向け
  28. 28. Git • オープンソース • 分散型バージョン管理システム • 今デファクトに • クールで良い
  29. 29. GitHub • パブリックリポジトリは無料 • プライベートリポジトリは学生プランだと20個まで無料、通 常は有料 • なんか割と かってるらしい • いっぱい機能がある • 最近社内用のエディタAtomが で流行ってる • GitLabはGitHubのOSS化フォークを目指している
  30. 30. GitとGitHubが どういう機能で 今までの問題を解決するのか
  31. 31. ここからは お勉強の時間だよっ!よっ!

×