Build insider offline session チームでのgit
•
6 likes•2,951 views
Builde Insider OFFLINEでのセッションスライド
![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(-)](https://image.slidesharecdn.com/buildinsiderofflinesessiongit-130608014238-phpapp01/85/Build-insider-offline-session-git-43-320.jpg)
![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“
修正のコミット](https://image.slidesharecdn.com/buildinsiderofflinesessiongit-130608014238-phpapp01/85/Build-insider-offline-session-git-46-320.jpg)
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