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

弊社でGit！実案件での運用

株式会社バイタリフィ社内勉強会制作部　千葉礼美

アジェンダ 1.  当勉強会のねらい 2.  バージョン管理システムについて

–  弊社でのSVN活用振り返り –  SVNでのリポジトリ構成図 –  Gitでのリポジトリ構成図 –  No Commit, No Ticketの考え方

3.  SourceTreeを活用してみよう！ 4.  ブランチの操作をしてみよう！

–  5つのブランチモデル

5.  さいごに…

弊社でGit！実案件での運用　／　制作部　千葉礼美 2

1.当勉強会のねらい


1.当勉強会のねらい

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


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


弊社でのSVN活用振り返り

作業するときに触るディレクトリ

Repository

work 1 work 2

作業するときなどに直接触らないリポジトリが存在。

作業するときのディレクトリはローカル（あなたのPCの中デース！）に存在します。Repositoryの複製版、ですね！



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

杉山 GG 石川松岡


Repository


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

杉山 GG


Repository

弊社でのSVN活用振り返りコミットします。これが最新であるとRepositoryに渡します。私たちはこれを「commitする」って呼んでましたね！

Repositoryは、commitされたときに最後のRevisionからの差分を判別します。差分に問題がなければそのままファイルをマージしてくれます。弊社でGit！実案件での運用　／　制作部　千葉礼美 9

Repository

杉山 GG

弊社でのSVN活用振り返りここでGG先輩が、最新のRepositoryの内容をアップデート、マージしていないまま、杉山くんと同じファイルを編集し、commitしました！

ConflictErrorが発生します。同じファイルの編集履歴を照合して、mergeした後にConflictを解消しましょう。

！


Repository

杉山 GG

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


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



命名規則ばらばら！最新ファイルは結局どれだよ！こんな管理方法激おこだよ！！！！ (◞≼◉ื≽◟ ;益;◞≼◉ื≽◟)

20131019_挿入タグ一覧.xls New_20131019_挿入タグ一覧.xls 20131019_挿入タグ一覧_千葉加筆.xls 【最新】20131019_挿入タグ一覧_千葉加筆02.xls 20131020_挿入タグ一覧.xls


20131019_gallery.psd 20131019_gallery_青.psd 20131019_gallery_角丸.psd 20131019/gallery.psd


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


「いつ」「だれが」「どんな目的のために」「なにをした」


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

SVNってなぁに集中型バージョン管理システムです。


Repository

update update

commit merge merge

commit＝Repository反映、update＝ローカルディレクトリ更新

rebase

merge

Gitってなぁに分散型バージョン管理システムです。


Repository

push commit

commit＝LocalRepository反映、push＝Repository反映 fetch=Repositoryから更新を取得、merge/rebase＝ローカルディレクトリ更新

Local Repository

Local Repository

fetch


Gitのワークフローは応用が効きます。「いつやるの？Git入門」P45～50で3種類のワークフローを紹介されています。

h"p://www.slideshare.net/matsukaz/git-‐17499005

Thanks @matsukaz

Gitを活用することの利点


Git操作がローカルで完結する 1. ローカルにリポジトリがあるため、通信環境がなくとも、手元で更新／履歴を残すことが可能。

2. 複数機能を持つアプリケーション開発などで、開発者が分担しておこなえる。


弊社は外注リソースを大いに活用、また、ベトナムとのオフショア開発とも連携しているためにソースコード関連は分散型管理の方が向いていると思うの( ˘ω˘)

ブランチ・マージが便利！ 1. 「別バージョン」として色違いの作成 2. 「機能」を限定してのリリース、納品


Gitには「trunk」がありません！ブランチと仲良くなってもっと効率化できたらいいですね。

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


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


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


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


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


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


5つのブランチモデル


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.  hotfixブランチリリースされたソフトウェアに緊急の修正を行うためのブランチ。このブランチでの修正内容は、すぐにリリースされるので、hotfixブランチはリリースを管理するmasterブランチへマージされる。


5.さいごに…


標準化することの必要性

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


おすすめの参考先


おすすめもっと早く知りたかった！ Gitが鬼のようにわかるスライド厳選7選

h"p://www.find-‐job.net/startup/7-‐git-‐slides


おすすめ

サルでもわかるGit入門

h"p://www.backlog.jp/git-‐guide/


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

Business

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