Build insider offline session チームでのgit
•
6 gefällt mir•2,949 views
Builde Insider OFFLINEでのセッションスライド
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (18)
Ähnlich wie Build insider offline session チームでのgit
Ähnlich wie Build insider offline session チームでのgit (20)
Mehr von Tadahiro Ishisaka
Mehr von Tadahiro Ishisaka (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (10)
Build insider offline session チームでのgit
- 1. チームでのGit ～ リポジトリ、ブランチの戦略～ 静岡ITPro勉強会/静岡Developers勉強会 Code 2013スタッフ 石坂 忠広 http://opcdiary.net
- 2. 2 Agenda • Gitとは • リポジトリの戦略 • リポジトリの配置 • Push, Pull, Rebase • ブランチの戦略 • 標準ブランチ戦略 • Checkout, Branch, Merge
- 4. 4 Gitとは
- 7. 7 Gitとは
- 9. 9 9 もしくは
- 16. 16 集中VS分散 clone, pull diff pushcheckout diff committ checkout committ add
- 17. 18 リポジトリ
- 18. 19 そもそも共有リポジトリは必要か • 製品のソースコード一式はどこにあるのか？ • 誰もがコードを持つが、逆に誰が持っているコードが正しいのか？ • ツール連携 • チケット(インシデント)管理ツールと連携するときに見に行くべき リポジトリは？ • CIツールが自動ビルドでPull(Fetch)すべきコードは • クラウドにデプロイするときに使うリポジトリは • Heroku, AppHarbor, Azure, AWS Elastic Beans....
- 20. 21 DVCS的な改良をしてみる1(P2P) clone, fetch diff push merge commit pushclone, pull clone, merge clone, pull push push
- 22. 23 DVCS的な改良をしてみる３(階層型) diff merge committ push push clone, pull push, pull push clone, fetch clone, pull push, pull 操作 push, pull
- 25. 26 ブランチ
- 32. 33 ブランチ(Branching) • お気軽に！とはいえ、チームで作業する以上一定の秩序は 必要 • 秩序の維持にはルール(規範)がいりますよね • でも規範とか一から作るのはメンドイ いいものが有ります
- 33. 34 A successful Git braching model
- 34. 35 A successful Git braching model • Vincent Driessen 著 • http://nvie.com/posts/a-successful-git-branching-model/ • 日本語訳 見えないチカラ: A successful Git branching model を翻訳しま した • ブランチを大きく二つに分ける • メインブランチ • サポートブランチ • git-flow • サポートツール(今日のデモでは使いません)
- 35. 36 A successful Git braching model • ブランチを大きく二つに分ける • メインブランチ • 共有リポジトリに永久に存在する • master • develop • サポートブランチ • 使い終わったら削除する • Feature braches • Release braches • Hotfix branches masterdevelo p featur e hotfixrelease
- 36. 37 master brach • 全てのブランチの幹 • 製品として出荷可能な状態を常に反映する • ソースコードの”HEAD”のありかであるメインブランチ
- 37. 38 develop brach • 次のリリースのために、最新の開発作業の変更を常に反映さ れたHEADが存在するブランチ • 「統合ブランチ」とも呼ばれる • 自動ナイトリービルドのビルド元になるブランチ • ローカルのフィーチャーブランチで行われた変更をこのブラ ンチにマージして、共有リポジトリにpushする • 新しい製品リリースの時にdevelopのHEADをmasterへ変更を マージする
- 38. 39 サポートブランチ • メインブランチのとなりでチームメンバーの並行開発を助け るためのブランチ • 機能の追加、リリースの準備、問題の修正などを用意するた めに設ける • メインブランチと異なり、サポートブランチは使い終わった ら最終的に削除する。
- 39. 40 feature brache • 分岐元：develop, マージ先:develop • ブランチ名の慣習: master, develop, release-*, hotfix-* 以外なら全て • トピックブランチとも • 次回リリースに入るような新しい機能開発に使われる • 1機能1ブランチ • その機能開発期間が寿命 • 最終的にはdevelopにマージする develo p featur e
- 40. 41 feature brach • ブランチの作成 $ git checkout -b myfeature develop • ブランチをdevelopにマージして、共有リポジトリにpush $ git checkout develop Switched 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
- 42. 43 release branch • 分岐元：develop, マージ先:developとmaster • ブランチ名の慣習: release-* • 新しい製品のリリースをサポートする • マイナーなバグフィックス→大きな変更をここでしてはならない • リリースのためのメタデータの準備 • 埋め込むリリース番号、ビルド番号の調整 • ビルド日時の調整 • 次のようなタイミングでdevelopから分岐 • developが次リリースに必要な機能がおおむねマージされている • 次リリースに正式なバージョン番号が与えられた masterdevelo p release
- 43. 44 release branch • release branchの作成 $ git checkout -b release-1.2 develop Switched 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.2 1 files changed, 1 insertions(+), 1 deletions(-)
- 44. 45 release branch • release branchの終了 $ git checkout master Switched 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. 46 hotfix branch • 分岐元：master, マージ先:developとmaster • ブランチ名の習慣: hotfix-* • バグフィックス用のブランチ • 特定の製品バージョンに対するブランチ • バージョンでタグづけされた位置からのブランチ • このブランチにより機能開発のメンバー (develop)とは別のメンバーが並行してバグ修正 の作業をする事が出来る • それにdevelopが安定しているとは言いがたい master hotfix
- 46. 47 hotfix 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.1 1 files changed, 1 insertions(+), 1 deletions(-) $ <バグの修正> $ git commit -m "Fixed severe production problem“ 修正のコミット
- 47. 48 hotfix branch • hotfix branchの終了 $ git checkout master Switched to branch 'master' $ git merge --no-ff hotfix-1.2.1 Merge 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
- 49. 50 A successful Git branching modelは絶対か？ • いいえ • プロジェクトに適切なブランチ戦略を • Fork, PullRequest前提(GitHub)とした場合のブランチ戦略 • masterはdevelopなのか • Deployはどこから？ • deployブランチを追加するか、masterをdeployするのか • CIツール連携、ビルドツール • バイナリの取り扱い • ライブラリはリポジトリに含めるのか、NuGetは？(今ならいいのか) • TFS • Gitで何をしたいのか？
- 50. 51 まとめ • チームでのGitの鍵はリポジトリとブランチの戦略 • リポジトリ • 共有リポジトリはチーム作業では必要 • 組織が大きく複雑化した場合はリポジトリを多層化する • GitHub的なSocialな運用 • ブランチ • VSS/SVNのような大げさなものでは無い。お気軽に！ • A successful Git branching model • でも、絶対じゃ無い
- 51. 52 参考文献 • Gitポケットリファレンス • 岡本隆史 武田健太郎 相良幸範 著 • 技術評論社 • ISBN 978-4-7741-5184-7 • 入門Git • 濱野純 著 • 秀和システム • ISBN 978-4-7980-2380-9
- 52. 53 参考文献 • Gitによるバージョン管理 • 岩松 信洋 上川 純一 まえだこうへい 小川 伸一郎著 • オーム社 • ISBN 978-4-2740-6864-5 • Pro Git(翻訳 Web版) • Scott Chacon 著 • http://git-scm.com/book/ja
- 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(翻訳)
- 55. 56 Gitを始めたい人に 1. Gitポケットリファレンスを手に入れます。 2. Gitポケットリファレンスの第1章を手を動かしながら読み 進めましょう。 3. 失敗してもいいプロジェクトを作って、実際の状態を想定 しながらコマンドのオプションをおぼえていきましょう。 4. エラーが出るのでポケットリファレンスで類似エラーが 乗っていないか確認して、何がだめだったのか確かめます。 5. WebのPro Gitか入門Gitを読んでGitの仕組みと思想を理解 します。
- 56. 57 Windows 95以降のWindowsしか 使ったことがないあなたへ • まず「黒い画面」というのは止める • 普段からコンソールを使うことになれましょう • GitはUnixのツールです。Windowsのツールじゃありません • Guiでなんでも出来ると思ったらだめです • Unix Wayを理解しましょう • 入出力とは標準入力、標準出力のことです • 出来るだけ単機能のツールをパイプで組み合わせて目的を達成します • 組み合わせるときのデータはテキストです • コンピュータの使い方を決めるのはツールではなくあなたです
- 57. 58