これで複数人での作業も安心!? 運用で困らないGitの導入について

これで複数人での作業も安心!? 運用で困らないGitの導入について

こんにちは。Webデザイナーのtamaです。

弊社では、大規模な組織になるにつれて個人単位でのソースコード管理が煩雑になっていたので、それを解決するためにGitを導入いたしました。

今回は「Git導入前の作業環境や問題点、チームで決めたルール」について解説いたします。

 

 

Git導入前の作業環境について

弊社のGit導入前の作業環境はというと、社内にいくつものプロジェクトがありプロジェクトごとに担当が決まっているわけではなくさまざまなプロジェクトに携わる環境で、デザイナーもサポートしてもらいながらコーディングしたりとプロジェクトに同時に複数人振り分けられるケースもあるので、大規模な組織になってきて個人単位でのソースコード管理が煩雑になっていました。

また、問題が発生した場合はバックアップファイルで後追いができるものの誰が修正したかなど細かく管理されておらず、ソースコードに関するマネジメントがしにくい状態でした。

 

Git導入前の問題点

問題1:ファイルをローカル環境で編集している間に他の人が本ファイルを編集しており、知らずに本ファイルを上書きしてしまい他の作業者のソースコードを消してしまう

問題2:バックアップファイルをとっておくのを忘れ、データを戻したいときに前バージョンのデータに戻せない

問題3:サーバーアップの際に、アップしないといけないファイルが漏れることがある

問題4:1つのプロジェクトで複数案件が同時に動いていて1つの案件のみを先にリリースする場合、ファイルを別立てして作業しておき、サーバーアップ後は本データが最新になるようにソースコードを統合する必要があり余計な手間がかかる

問題5:誰がどのファイルをどのように編集したか、履歴が追えない

 

 

上記、5つの問題点を解決するために弊社ではGitを導入いたしました。その際、現場が混乱しないようにチームで決めたルールを紹介したいと思います。

 

 

Git導入にあたりチームで決めたルール

 

ルール1:案件ごとにブランチをきる

→ リリース日が異なる案件をリリースしやすくするため

 

ルール2:ブランチを作成する前に、どのブランチから派生させるか確認する

→ 弊社では基本的にはmasterブランチから新しいブランチを作成しているのですが、リリース前案件のソースコードも含めたブランチから新しいブランチを作成する可能性もあるため

 

ルール3:ブランチ名は「(案件ID)_(案件名)」にする

→ 案件名のみの場合、案件が増えていった場合にかぶる可能性があるので案件IDも含めました。また、案件IDのみの場合は数字列だけで見づらく、どういう内容の修正なのかざっと見て判断できないため

 

ルール4:作業前に必ず最新のファイルになっているか確認する

→ 古いファイルをもとに修正した状態で、コミットを打たないようにするため

 

ルール5:コミット名は、どの端末のどのページのどの部分を編集したのかわかるようにつける

→ どういう修正をしたのか誰が見ても確認できるようにするため

 

ルール6:デザイナーがコーディングする際は、サポートする人をスケジューリングする

→ 必要最低限のGUIツールでの操作方法とコマンドをおしえているものの、何か問題に衝突したときはいつでも相談できるようにするため

 

また、上記ルールとは別の取り組みとしてコーディングチェックシートを作成しており、コーディング前半とコーディング後半に「不要になったソースコードやファイルは削除する」「マージに衝突した場合は、双方に話合い、必要なソースコードを残す」「コミットに関係ないファイルはコミットに含めない」などを含むチェック項目を設けております。

 

 

まとめ

社内にいくつものプロジェクトがあり複数人が作業する大規模組織になると、ソースコードの管理が煩雑になりますが、Gitを導入することで、案件ごとの履歴を追いやすくし、ソースコードに関するマネジメントがしやすくなります。

また、その際に発生する問題点を解決するために弊社では運用ルールを作成することで、いくつものプロジェクトを複数人で問題なく運用できるように環境を整備いたしました。

 


Previous: 購買意欲を刺激させる!上手な料金の見せ方いろいろ Next: 【初心者向け】PHPでできる配列の判定いろいろ

© 2017 ALL CONNECT Inc. All Rights Reserved.