【社内勉強会】弊社でGit!実案件での運用

9,074 views

Published on

SVN運用をしていた社内で、Gitの標準化も進めるべく社内勉強会資料を作成しました。

資料作成に当たり、@matsukaz さん@nvie さんの資料を参考にさせていただきました。
ありがとうございました!

Published in: Business

【社内勉強会】弊社でGit!実案件での運用

  1. 1. 弊社でGit!実案件での運用 株式会社バイタリフィ社内勉強会 制作部 千葉礼美
  2. 2. アジェンダ 1.  当勉強会のねらい 2.  バージョン管理システムについて –  弊社でのSVN活用振り返り –  SVNでのリポジトリ構成図 –  Gitでのリポジトリ構成図 –  No Commit, No Ticketの考え方 3.  SourceTreeを活用してみよう! 4.  ブランチの操作をしてみよう! –  5つのブランチモデル 5.  さいごに… 弊社でGit!実案件での運用 / 制作部 千葉礼美 2
  3. 3. 1.当勉強会のねらい 弊社でGit!実案件での運用 / 制作部 千葉礼美 3
  4. 4. 1.当勉強会のねらい 1.  Gitを活用して実案件に役立てられるようになる。 2.  案件に合わせてSVNとGitの使い分けができるように なる。 弊社でGit!実案件での運用 / 制作部 千葉礼美 4
  5. 5. 2.バージョン管理システムについて 弊社でGit!実案件での運用 / 制作部 千葉礼美 5
  6. 6. 弊社でのSVN活用振り返り 作業するときに触るディレクトリ Repository work  1 work  2 作業するときなどに直 接触らないリポジトリ が存在。 作業するときのディレクトリはローカル(あなたのPCの中デー ス!)に存在します。Repositoryの複製版、ですね! 弊社でGit!実案件での運用 / 制作部 千葉礼美 6
  7. 7. 弊社でのSVN活用振り返り 作業するときには、各自、自分のPCにRepository の複製版を作りますね。これを「チェックアウトす る」って言って使ってますよね。 杉山 GG 石川 松岡 弊社でGit!実案件での運用 / 制作部 千葉礼美 7 Repository
  8. 8. 弊社でのSVN活用振り返り 作業発生!杉山くんがファイルを編集しました。 ローカルディレクトリなので、編集が反映されるのは自分の 手元のファイルのみです。 杉山 GG 弊社でGit!実案件での運用 / 制作部 千葉礼美 8 Repository
  9. 9. 弊社でのSVN活用振り返り コミットします。 これが最新であると Repositoryに渡しま す。私たちはこれを 「commitする」って 呼んでましたね! Repositoryは、commitされたときに最後のRevisionから の差分を判別します。差分に問題がなければそのままファイ ルをマージしてくれます。 弊社でGit!実案件での運用 / 制作部 千葉礼美 9 Repository 杉山 GG
  10. 10. 弊社でのSVN活用振り返り ここでGG先輩が、最新 のRepositoryの内容を アップデート、マージ していないまま、杉山 くんと同じファイルを 編集し、commitしまし た! ConflictErrorが発生します。同じファイルの編集履歴を照 合して、mergeした後にConflictを解消しましょう。 ! 弊社でGit!実案件での運用 / 制作部 千葉礼美 10 Repository 杉山 GG
  11. 11. バージョン管理すると いいことあるの? 弊社でGit!実案件での運用 / 制作部 千葉礼美 11
  12. 12. 「ファイル管理」が標準化できます。 弊社でGit!実案件での運用 / 制作部 千葉礼美 12
  13. 13. 「ファイル管理」が標準化できます。 命名規則ばらばら!最新ファイルは結局どれだよ! こんな管理方法激おこだよ!!!! (◞≼◉ื≽◟ ;益;◞≼◉ื≽◟) 20131019_挿入タグ一覧.xls New_20131019_挿入タグ一覧.xls 20131019_挿入タグ一覧_千葉加筆.xls 【最新】20131019_挿入タグ一覧_千葉加筆02.xls 20131020_挿入タグ一覧.xls 弊社でGit!実案件での運用 / 制作部 千葉礼美 13
  14. 14. 20131019_gallery.psd 20131019_gallery_青.psd 20131019_gallery_角丸.psd 20131019/gallery.psd 「ファイル管理」が標準化できます。 変更した分だけファイルが増えてる! 途中で増えすぎてディレクトリ切り出した!最初からやれよ!こんな管 理方法激おこだよ!!!! (◞≼◉ื≽◟ ;益;◞≼◉ื≽◟) 弊社でGit!実案件での運用 / 制作部 千葉礼美 14
  15. 15. 「いつ」 「だれが」 「どんな目的のために」 「なにをした」 弊社でGit!実案件での運用 / 制作部 千葉礼美 15 がシステム的に管理されます。 目的の無いcommitは必要ありません。 差分納品もしやすくなるねっ!
  16. 16. SVNってなぁに 集中型バージョン管理システムです。 弊社でGit!実案件での運用 / 制作部 千葉礼美 16 Repository update update commit merge merge commit=Repository反映、update=ローカルディレクトリ更新
  17. 17. rebase merge Gitってなぁに 分散型バージョン管理システムです。 弊社でGit!実案件での運用 / 制作部 千葉礼美 17 Repository pushcommit commit=LocalRepository反映、push=Repository反映 fetch=Repositoryから更新を取得、merge/rebase=ローカルディレクトリ更新 Local   Repository Local   Repository fetch
  18. 18. 弊社でGit!実案件での運用 / 制作部 千葉礼美 18 Gitのワークフローは応用が効きます。 「いつやるの?Git入門」P45∼50で3種類 のワークフローを紹介されています。 h"p://www.slideshare.net/matsukaz/git-­‐17499005 Thanks  @matsukaz
  19. 19. Gitを活用することの利点 弊社でGit!実案件での運用 / 制作部 千葉礼美 19
  20. 20. Git操作がローカルで完結する 1.  ローカルにリポジトリがあるため、通信 環境がなくとも、手元で更新/履歴を残 すことが可能。 2.  複数機能を持つアプリケーション開発な どで、開発者が分担しておこなえる。 弊社でGit!実案件での運用 / 制作部 千葉礼美 20 弊社は外注リソースを大いに活用、また、ベトナムとのオフ ショア開発とも連携しているためにソースコード関連は分散 型管理の方が向いていると思うの( ˘ω˘)
  21. 21. ブランチ・マージが便利! 1.  「別バージョン」として色違いの作成 2.  「機能」を限定してのリリース、納品 弊社でGit!実案件での運用 / 制作部 千葉礼美 21 Gitには「trunk」がありません! ブランチと仲良くなってもっと効率化できたらいいですね。
  22. 22. SVNでいいじゃんっていう作業 弊社でGit!実案件での運用 / 制作部 千葉礼美 22
  23. 23. デザインカンプやドキュメント 1.  複数人で同時編集することがほぼ無い。 2.  commitの頻度も多くない。少なめ。 弊社でGit!実案件での運用 / 制作部 千葉礼美 23
  24. 24. そこで弊社では… •  親プロジェクト – 設計サブプロジェクト(SVN) – 開発プロジェクト(Git) で分けちゃうのはどうかなあ、と。 親プロジェクトで両方のチケットもロード マップ参照できるし、リソース別でプロ ジェクト複製してしまうのはありだと思い ます。 弊社でGit!実案件での運用 / 制作部 千葉礼美 24
  25. 25. 3. SourceTreeを活用してみよう! 弊社でGit!実案件での運用 / 制作部 千葉礼美 25
  26. 26. 里山さん作成の Git利用手順書.pptx を参照して、ひと通りやってみ てください٩(๑❛ᴗ❛๑)۶ テスト用プロジェクトは、 後ほどチャットワークでお知らせしますっ 弊社でGit!実案件での運用 / 制作部 千葉礼美 26
  27. 27. 4.ブランチの操作をしてみよう! 弊社でGit!実案件での運用 / 制作部 千葉礼美 27
  28. 28. 5つのブランチモデル 弊社でGit!実案件での運用 / 制作部 千葉礼美 28 h"p://www.atmarkit.co.jp/ait/arCcles/1311/18/news017.html Thanks  @nvie
  29. 29. 5つのブランチモデル 1.  developブランチ 開発を行うためのブランチ。開発者は、主にこのブランチ上で作業を行う。次に紹 介するfeatureブランチなど、他のブランチで行った作業は、ここにマージされる。 2.  featureブランチ 主要な機能を実装するためのブランチ。機能の実装やバグフィックスなど、タスク ごとにfeatureブランチを作成し、作業を行う。 3.  releaseブランチ リリースの準備を行うためのブランチ。プロダクトをリリースする前に、このブラ ンチを作成し、微調整を行う。releaseブランチを作成することで、リリース準備 と次のバージョンに向けた開発のコードを分けることができる。 4.  masterブランチ リリースしたソースコードを管理するためのブランチ。リリース作業を行うと、 releaseブランチはmasterブランチへマージされて、リリースタグが打たれる。開 発者は、このブランチへのコミットは行わない。 5.  hotfixブランチ リリースされたソフトウェアに緊急の修正を行うためのブランチ。このブランチで の修正内容は、すぐにリリースされるので、hotfixブランチはリリースを管理する masterブランチへマージされる。 弊社でGit!実案件での運用 / 制作部 千葉礼美 29
  30. 30. 5.さいごに… 弊社でGit!実案件での運用 / 制作部 千葉礼美 30
  31. 31. 標準化することの必要性 コミットに必ずコメントをつけること、チケット などのタスクとひもづけることを徹底すると、無 駄な作業がなくなります。 そのため工数が見積もりやすくなるし、開発の ワークフローが一元化しやすくなります。 弊社でGit!実案件での運用 / 制作部 千葉礼美 31
  32. 32. おすすめの参考先 弊社でGit!実案件での運用 / 制作部 千葉礼美 32
  33. 33. おすすめ もっと早く知りたかった! Gitが鬼のようにわかるスライド厳選7選 h"p://www.find-­‐job.net/startup/7-­‐git-­‐slides 弊社でGit!実案件での運用 / 制作部 千葉礼美 33
  34. 34. おすすめ サルでもわかるGit入門 h"p://www.backlog.jp/git-­‐guide/ 弊社でGit!実案件での運用 / 制作部 千葉礼美 34

×