【社内勉強会】弊社でGit！実案件での運用

弊社でGit！実案件での運用
株式会社バイタリフィ社内勉強会
制作部千葉礼美

アジェンダ
1.  当勉強会のねらい
2.  バージョン管理システムについて
–  弊社でのSVN活用振り返り
–  SVNでのリポジトリ構成図
–  Gitでのリポジトリ構成図
–  No Commit, No Ticketの考え方
3.  SourceTreeを活用してみよう！
4.  ブランチの操作をしてみよう！
–  5つのブランチモデル
5.  さいごに…
弊社でGit！実案件での運用　／　制作部　千葉礼美
2

1.当勉強会のねらい
3

1.当勉強会のねらい
1.  Gitを活用して実案件に役立てられるようになる。
2.  案件に合わせてSVNとGitの使い分けができるように
なる。
4

2.バージョン管理システムについて
5

弊社でのSVN活用振り返り
作業するときに触るディレクトリ
Repository
work
1
work
2
作業するときなどに直
接触らないリポジトリ
が存在。
作業するときのディレクトリはローカル（あなたのPCの中デー
ス！）に存在します。Repositoryの複製版、ですね！
6

作業するときには、各自、自分のPCにRepository
の複製版を作りますね。これを「チェックアウトす
る」って言って使ってますよね。
杉山
GG
石川
松岡
7
Repository

作業発生！杉山くんがファイルを編集しました。
ローカルディレクトリなので、編集が反映されるのは自分の
手元のファイルのみです。
杉山
GG
8
Repository

コミットします。
これが最新であると
Repositoryに渡しま
す。私たちはこれを
「commitする」って
呼んでましたね！
Repositoryは、commitされたときに最後のRevisionから
の差分を判別します。差分に問題がなければそのままファイ
ルをマージしてくれます。
9
Repository
杉山
GG

ここでGG先輩が、最新
のRepositoryの内容を
アップデート、マージ
していないまま、杉山
くんと同じファイルを
編集し、commitしまし
た！
ConﬂictErrorが発生します。同じファイルの編集履歴を照
合して、mergeした後にConﬂictを解消しましょう。
！
10
Repository
杉山
GG

バージョン管理すると
いいことあるの？
11

「ファイル管理」が標準化できます。
12

命名規則ばらばら！最新ファイルは結局どれだよ！
こんな管理方法激おこだよ！！！！ (◞≼◉ื≽◟ ;益;◞≼◉ื≽◟)
20131019_挿入タグ一覧.xls
New_20131019_挿入タグ一覧.xls
20131019_挿入タグ一覧_千葉加筆.xls
【最新】20131019_挿入タグ一覧_千葉加筆02.xls
20131020_挿入タグ一覧.xls
13

20131019_gallery.psd
20131019_gallery_青.psd
20131019_gallery_角丸.psd
20131019/gallery.psd
変更した分だけファイルが増えてる！
途中で増えすぎてディレクトリ切り出した！最初からやれよ！こんな管
理方法激おこだよ！！！！ (◞≼◉ื≽◟ ;益;◞≼◉ื≽◟)
14

「いつ」
「だれが」
「どんな目的のために」
「なにをした」
15
がシステム的に管理されます。
目的の無いcommitは必要ありません。
差分納品もしやすくなるねっ！

SVNってなぁに
集中型バージョン管理システムです。
16
Repository
update update
commit
merge merge
commit＝Repository反映、update＝ローカルディレクトリ更新

rebase
merge
Gitってなぁに
分散型バージョン管理システムです。
17
Repository
pushcommit
commit＝LocalRepository反映、push＝Repository反映
fetch=Repositoryから更新を取得、merge/rebase＝ローカルディレクトリ更新
Local

Repository
Local

Repository
fetch

18
Gitのワークフローは応用が効きます。
「いつやるの？Git入門」P45∼50で3種類
のワークフローを紹介されています。
h"p://www.slideshare.net/matsukaz/git-‐17499005
Thanks
@matsukaz

Gitを活用することの利点
19

Git操作がローカルで完結する
1.  ローカルにリポジトリがあるため、通信
環境がなくとも、手元で更新／履歴を残
すことが可能。
2.  複数機能を持つアプリケーション開発な
どで、開発者が分担しておこなえる。
20
弊社は外注リソースを大いに活用、また、ベトナムとのオフ
ショア開発とも連携しているためにソースコード関連は分散
型管理の方が向いていると思うの( ˘ω˘)

ブランチ・マージが便利！
1.  「別バージョン」として色違いの作成
2.  「機能」を限定してのリリース、納品
21
Gitには「trunk」がありません！
ブランチと仲良くなってもっと効率化できたらいいですね。

SVNでいいじゃんっていう作業
22

デザインカンプやドキュメント
1.  複数人で同時編集することがほぼ無い。
2.  commitの頻度も多くない。少なめ。
23

そこで弊社では…
•  親プロジェクト
– 設計サブプロジェクト（SVN）
– 開発プロジェクト（Git）
で分けちゃうのはどうかなあ、と。
親プロジェクトで両方のチケットもロード
マップ参照できるし、リソース別でプロ
ジェクト複製してしまうのはありだと思い
ます。
24

3. SourceTreeを活用してみよう！
25

里山さん作成の
Git利用手順書.pptx
を参照して、ひと通りやってみ
てください٩(๑❛ᴗ❛๑)۶
テスト用プロジェクトは、
後ほどチャットワークでお知らせしますっ
26

4.ブランチの操作をしてみよう！
27

5つのブランチモデル
28
h"p://www.atmarkit.co.jp/ait/arCcles/1311/18/news017.html
Thanks
@nvie

5つのブランチモデル
1.  developブランチ
開発を行うためのブランチ。開発者は、主にこのブランチ上で作業を行う。次に紹
介するfeatureブランチなど、他のブランチで行った作業は、ここにマージされる。
2.  featureブランチ
主要な機能を実装するためのブランチ。機能の実装やバグフィックスなど、タスク
ごとにfeatureブランチを作成し、作業を行う。
3.  releaseブランチ
リリースの準備を行うためのブランチ。プロダクトをリリースする前に、このブラ
ンチを作成し、微調整を行う。releaseブランチを作成することで、リリース準備
と次のバージョンに向けた開発のコードを分けることができる。
4.  masterブランチ
リリースしたソースコードを管理するためのブランチ。リリース作業を行うと、
releaseブランチはmasterブランチへマージされて、リリースタグが打たれる。開
発者は、このブランチへのコミットは行わない。
5.  hotﬁxブランチ
リリースされたソフトウェアに緊急の修正を行うためのブランチ。このブランチで
の修正内容は、すぐにリリースされるので、hotﬁxブランチはリリースを管理する
masterブランチへマージされる。
29

5.さいごに…
30

標準化することの必要性
コミットに必ずコメントをつけること、チケット
などのタスクとひもづけることを徹底すると、無
駄な作業がなくなります。
そのため工数が見積もりやすくなるし、開発の
ワークフローが一元化しやすくなります。
31

おすすめの参考先
32

おすすめ
もっと早く知りたかった！
Gitが鬼のようにわかるスライド厳選7選
h"p://www.ﬁnd-‐job.net/startup/7-‐git-‐slides
33

おすすめ
サルでもわかるGit入門
h"p://www.backlog.jp/git-‐guide/
34

【社内勉強会】弊社でGit！実案件での運用

More Related Content

What's hot

Viewers also liked

Similar to 【社内勉強会】弊社でGit！実案件での運用

More from Reimi Kuramochi Chiba

Recently uploaded

【社内勉強会】弊社でGit！実案件での運用