Build insider offline session チームでのgit

1,988 views

Published on

Builde Insider OFFLINEでのセッションスライド

Published in: Technology, Sports
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,988
On SlideShare
0
From Embeds
0
Number of Embeds
805
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Build insider offline session チームでのgit

  1. 1. チームでのGit~ リポジトリ、ブランチの戦略~静岡ITPro勉強会/静岡Developers勉強会Code 2013スタッフ石坂 忠広http://opcdiary.net
  2. 2. 2Agenda• Gitとは• リポジトリの戦略• リポジトリの配置• Push, Pull, Rebase• ブランチの戦略• 標準ブランチ戦略• Checkout, Branch, Merge
  3. 3. 3自己紹介石坂忠広(いしさかただひろ)静岡ITPro勉強会スタッフ静岡Developers勉強会スタッフJAZUG 静岡支部長Code 2013スタッフ(しおり係)8/3(土)~8/4(日)北海道定山渓温泉(札幌)にて合宿
  4. 4. 4Gitとは
  5. 5. 5歴史2005年Linuxカーネル開発のためにLinusにより開発が始まる。その後様々なイケテル企業で採用。
  6. 6. 6歴史そして2008年GitHub登場ソーシャルコーディングGitHubを使いたいからGitを使う
  7. 7. 7Gitとは
  8. 8. 8ぎっととは分散バージョンコントロールシステム
  9. 9. 9 9もしくは
  10. 10. 10ぎっととはディレクトリコテントマネージメントシステム
  11. 11. 11ぎっととはツリー方式履歴管理システム
  12. 12. 12分散とはみんが完全な履歴を持っている
  13. 13. 13分散とはみんが完全なリポジトリを持っている全てがオフライン... push/pull
  14. 14. 14分散とはみんが完全な履歴を持っている全てがオフライン中心はない... conversion
  15. 15. 15分散とはみんが完全な履歴を持っている全てがオフライン中心はないサーバー無き変更の共有
  16. 16. 16集中VS分散clone, pulldiffpushcheckout diff committcheckoutcommittadd
  17. 17. 18リポジトリ
  18. 18. 19そもそも共有リポジトリは必要か• 製品のソースコード一式はどこにあるのか?• 誰もがコードを持つが、逆に誰が持っているコードが正しいのか?• ツール連携• チケット(インシデント)管理ツールと連携するときに見に行くべきリポジトリは?• CIツールが自動ビルドでPull(Fetch)すべきコードは• クラウドにデプロイするときに使うリポジトリは• Heroku, AppHarbor, Azure, AWS Elastic Beans....
  19. 19. 20基本的な例あるいはSVN/TFS的な発想clone, fetchdiffpushmergecommitt
  20. 20. 21DVCS的な改良をしてみる1(P2P)clone, fetchdiffpushmergecommitpushclone, pullclone, mergeclone, pullpushpush
  21. 21. 22DVCS的な改良をしてみる2(P2P改良)diffmergecommittpush, pullpullpush pushpush,fetchpull
  22. 22. 23DVCS的な改良をしてみる3(階層型)diffmergecommittpushpush clone, pullpush, pullpushclone,fetchclone, pullpush, pull操作push, pull
  23. 23. 24DVCS的な改良をしてみる4(Social)diffmergecommittpushclone,pull/fetchForkPullRequestpull,fetchrebasedeployプルリクエストに対する操作コミッタ
  24. 24. 25Demo(pull, push, rebase)
  25. 25. 26ブランチ
  26. 26. 27ブランチ(Branching)中央集権型VCのそれはまず忘れましょう!(...VSS, TFS, SVN, そのほか)
  27. 27. 28ブランチ(Branching)中央集権型VCのそれはまず忘れましょう!Gitのブランチはグラフ(ツリー)のノードに付けられた「付せん」です
  28. 28. 29ブランチ(Branching)中央集権型VCのそれはまず忘れましょう!Gitのブランチはグラフ(ツリー)のノードに付けられた「付せん」です全てのブランチは全て同じディレクトリの中で動作します
  29. 29. 30ブランチ(Branching)中央集権型VCのそれはまず忘れましょう!Gitのブランチはグラフ(ツリー)のノードに付けられた「付せん」です全てのブランチは全て同じディレクトリの中で動作しますブランチをスイッチすることは単純に「付せん」をつける場所変えるだけのこと
  30. 30. 31ブランチ(Branching)世の中、「ブランチ申請書」なる書類がある職場もあるようですが...
  31. 31. 32ブランチ(Branching)お気軽に!Gitのブランチは
  32. 32. 33ブランチ(Branching)• お気軽に!とはいえ、チームで作業する以上一定の秩序は必要• 秩序の維持にはルール(規範)がいりますよね• でも規範とか一から作るのはメンドイいいものが有ります
  33. 33. 34A successful Git braching model
  34. 34. 35A successful Git braching model• Vincent Driessen 著• http://nvie.com/posts/a-successful-git-branching-model/• 日本語訳見えないチカラ: A successful Git branching model を翻訳しました• ブランチを大きく二つに分ける• メインブランチ• サポートブランチ• git-flow• サポートツール(今日のデモでは使いません)
  35. 35. 36A successful Git braching model• ブランチを大きく二つに分ける• メインブランチ• 共有リポジトリに永久に存在する• master• develop• サポートブランチ• 使い終わったら削除する• Feature braches• Release braches• Hotfix branchesmasterdevelopfeaturehotfixrelease
  36. 36. 37master brach• 全てのブランチの幹• 製品として出荷可能な状態を常に反映する• ソースコードの”HEAD”のありかであるメインブランチ
  37. 37. 38develop brach• 次のリリースのために、最新の開発作業の変更を常に反映されたHEADが存在するブランチ• 「統合ブランチ」とも呼ばれる• 自動ナイトリービルドのビルド元になるブランチ• ローカルのフィーチャーブランチで行われた変更をこのブランチにマージして、共有リポジトリにpushする• 新しい製品リリースの時にdevelopのHEADをmasterへ変更をマージする
  38. 38. 39サポートブランチ• メインブランチのとなりでチームメンバーの並行開発を助けるためのブランチ• 機能の追加、リリースの準備、問題の修正などを用意するために設ける• メインブランチと異なり、サポートブランチは使い終わったら最終的に削除する。
  39. 39. 40feature brache• 分岐元:develop, マージ先:develop• ブランチ名の慣習:master, develop, release-*, hotfix-* 以外なら全て• トピックブランチとも• 次回リリースに入るような新しい機能開発に使われる• 1機能1ブランチ• その機能開発期間が寿命• 最終的にはdevelopにマージするdevelopfeature
  40. 40. 41feature brach• ブランチの作成$ git checkout -b myfeature develop• ブランチをdevelopにマージして、共有リポジトリにpush$ git checkout developSwitched to branch develop$ git merge --no-ff myfeature ← --no-ffオプションでfeatureの存在を残すUpdating ea1b82a..05e9557(Summary of changes)$ git branch -d myfeature ← featureを削除するDeleted branch myfeature (was 05e9557).$ git push origin develop ← 共有リポジトリにpush
  41. 41. 42feature branchのDemo
  42. 42. 43release branch• 分岐元:develop, マージ先:developとmaster• ブランチ名の慣習: release-*• 新しい製品のリリースをサポートする• マイナーなバグフィックス→大きな変更をここでしてはならない• リリースのためのメタデータの準備• 埋め込むリリース番号、ビルド番号の調整• ビルド日時の調整• 次のようなタイミングでdevelopから分岐• developが次リリースに必要な機能がおおむねマージされている• 次リリースに正式なバージョン番号が与えられたmasterdeveloprelease
  43. 43. 44release branch• release branchの作成$ git checkout -b release-1.2 developSwitched to a new branch "release-1.2"$ ./bump-version.sh 1.2 ← リリースのためのメタデータ処理Files modified successfully, version bumped to 1.2.$ git commit -a -m "Bumped version number to 1.2"[release-1.2 74d9424] Bumped version number to 1.21 files changed, 1 insertions(+), 1 deletions(-)
  44. 44. 45release branch• release branchの終了$ git checkout masterSwitched to branch master$ git merge --no-ff release-1.2← --no-ffオプションでreleaseの存在を残すMerge made by recursive.(Summary of changes)$ git tag -a 1.2$ git checkout develop ← 必要に応じdevelopにmerge$ git merge --no-ff release-1.2$ git branch -d release-1.2 ← 最終的に削除• 本当にリリースされても良い状態になったら終了する• masterにマージ後tagを付ける
  45. 45. 46hotfix branch• 分岐元:master, マージ先:developとmaster• ブランチ名の習慣: hotfix-*• バグフィックス用のブランチ• 特定の製品バージョンに対するブランチ• バージョンでタグづけされた位置からのブランチ• このブランチにより機能開発のメンバー(develop)とは別のメンバーが並行してバグ修正の作業をする事が出来る• それにdevelopが安定しているとは言いがたいmaster hotfix
  46. 46. 47hotfix branch• hotfix branchの作成$ git checkout -b hotfix-1.2.1 master$ <バージョン番号などの修正>$ git commit -a -m "Bumped version number to 1.2.1"[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.11 files changed, 1 insertions(+), 1 deletions(-)$ <バグの修正>$ git commit -m "Fixed severe production problem“修正のコミット
  47. 47. 48hotfix branch• hotfix branchの終了$ git checkout masterSwitched to branch master$ git merge --no-ff hotfix-1.2.1Merge made by recursive.(Summary of changes)$ git tag -a 1.2.1 ←修正後のタグを付ける$ git checkout develop ← ↓修正をdevelopにも反映する$ git merge --no-ff hotfix-1.2.1※このときリリースブランチがあれば、そちらに反映する$ git branch -d hotfix-1.2.1
  48. 48. 49hotfix branchのDemo
  49. 49. 50A successful Git branching modelは絶対か?• いいえ• プロジェクトに適切なブランチ戦略を• Fork, PullRequest前提(GitHub)とした場合のブランチ戦略• masterはdevelopなのか• Deployはどこから?• deployブランチを追加するか、masterをdeployするのか• CIツール連携、ビルドツール• バイナリの取り扱い• ライブラリはリポジトリに含めるのか、NuGetは?(今ならいいのか)• TFS• Gitで何をしたいのか?
  50. 50. 51まとめ• チームでのGitの鍵はリポジトリとブランチの戦略• リポジトリ• 共有リポジトリはチーム作業では必要• 組織が大きく複雑化した場合はリポジトリを多層化する• GitHub的なSocialな運用• ブランチ• VSS/SVNのような大げさなものでは無い。お気軽に!• A successful Git branching model• でも、絶対じゃ無い
  51. 51. 52参考文献• Gitポケットリファレンス• 岡本隆史 武田健太郎 相良幸範 著• 技術評論社• ISBN 978-4-7741-5184-7• 入門Git• 濱野純 著• 秀和システム• ISBN 978-4-7980-2380-9
  52. 52. 53参考文献• Gitによるバージョン管理• 岩松 信洋 上川 純一 まえだこうへい 小川 伸一郎著• オーム社• ISBN 978-4-2740-6864-5• Pro Git(翻訳 Web版)• Scott Chacon 著• http://git-scm.com/book/ja
  53. 53. 54参考文献• 開発ツール徹底攻略• 江口和宏 大塚弘記 他著• 技術評論社• ISBN 978-4-7741-5616-3• A successful Git branching model• Vincent Driessen 著• http://nvie.com/posts/a-successful-git-branching-model/• http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html(翻訳)
  54. 54. 56Gitを始めたい人に1. Gitポケットリファレンスを手に入れます。2. Gitポケットリファレンスの第1章を手を動かしながら読み進めましょう。3. 失敗してもいいプロジェクトを作って、実際の状態を想定しながらコマンドのオプションをおぼえていきましょう。4. エラーが出るのでポケットリファレンスで類似エラーが乗っていないか確認して、何がだめだったのか確かめます。5. WebのPro Gitか入門Gitを読んでGitの仕組みと思想を理解します。
  55. 55. 57Windows 95以降のWindowsしか使ったことがないあなたへ• まず「黒い画面」というのは止める• 普段からコンソールを使うことになれましょう• GitはUnixのツールです。Windowsのツールじゃありません• Guiでなんでも出来ると思ったらだめです• Unix Wayを理解しましょう• 入出力とは標準入力、標準出力のことです• 出来るだけ単機能のツールをパイプで組み合わせて目的を達成します• 組み合わせるときのデータはテキストです• コンピュータの使い方を決めるのはツールではなくあなたです
  56. 56. 58

×