-
- 2023/7/18
- WEB制作
チームにGit運用を導入してみた（初心者・webデザイナー向け）
- さしみ
こんにちは、さしみです。
2022年あたりから、クリエイティブチームではGit運用を本格的に導入しました。
以前からもGit自体は使っていたのですが、基本的に開発部署への納品のために使用するシーンが多く、案件単位・スタッフ単位で使用状況がばらついているという現状がありました。
が、チームの人数も増えてきて同じ案件に複数人関わることも増えてきたという状況もあり、案件単位ではなくチームとして取り組もう！となった次第です。
これでもう「案件名_完成」「案件名_最終版(２)」「案件名_ファイナル」のようなカオスな状況とはさよならです。
Gitについて
チームへの導入にあたって、まずはGitとはなんぞや？を共有し、知識のばらつきを減らしてみました。
そもそもGitとは誰が・いつ・どこを修正したのか、履歴がわかるようにバージョン管理するための仕組みのことを言います。
同じタイミングで複数人が同じファイルを修正していても、Gitを使っていれば修正した箇所を把握することができます。
そのため「共有フォルダにうっかり内容を上書きしてしまった」という事故を防ぎやすくなります。
Git導入前：うっかり上書きしがち…
Git導入後：競合が発生するとわかるようになるので、事故を防げる
導入のメリットとデメリット
よっしゃ、事故を防ぐぞ！ということで導入に至ったわけですが、メリットもあればもちろんデメリットもあります。
あくまでさしみ視点ですが、導入にあたってのメリットとデメリットをまとめてみました。
- メリット
-
- ・修正の差分がわかる
- ・過去のバージョンを復元できる
- ・誰が修正したか把握できる
- ・コードレビューがしやすい
- ・どれが最新版かわかりやすい
- ・修正を指摘する際に、該当箇所にコメントが残せる
- デメリット
-
- ・学習コストがかかる
- ・ルールを決めないとカオスになる
- ・プルリクエスト（確認依頼作成）を挟む分時間がかかる
学習コストとルール決めをしなければいけないといったデメリットはあるものの、ヒューマンエラーを防ぐのにはやっぱり「気をつける」では限界がありますよね…。
事故を防げるのはもちろんのこと、個人的にメリットだなと感じたのは「誰が更新したかわかる」かなと思います。
競合が起きたときに誰に確認を取ればいいのかがわかるというのは、ありがたいですよね。
Git用語（よく使うやつ）について
webデザイナーから見たときにGit用語の独自さも導入のハードルを高めているように感じましたので、なんとか自分たちに親しみのある言い回しに置き換えてみました。
- リポジトリ
- 制作ファイルを管理する場所
webでいうとディレクトリのようなイメージで、ファイル履歴の管理が行われる場所です。
オンライン上のものは「リモートリポジトリ」、自分のPC内にあるものは「ローカルリポジトリ」といいます。
- クローン
- 制作ファイル一式を複製
リモートリポジトリから、制作ファイル一式を持ってくることです。基本的に初回のみクローンを作成します。
クローン技術的な単語の使われ方が多いので、イメージがつきやすいですね。
- ブランチ
- 制作用の分岐を作成
ブランチとは「枝」という意味です。メインから枝分かれを作って、自分が作業する場所を作るイメージです。ブランチを作っておくと、プッシュのたびに競合が発生する、ということも避けやすく作業がはかどります。
- プル
- ダウンロード
プルとは「引く」という意味です。リモートから修正の差分情報を引っ張ってくる、というイメージです。誰かが更新したものをプルする、という形で使います。
クローンがすべて持ってくるのに対して、プルは部分的に引っ張ってくるという認識です。
- プッシュ
- アップロード
プッシュとは「押す」という意味です。プルとは反対に、リモートへ情報を上げるというイメージです。自分が更新したものをプッシュする、という形で使います。
- コミット
- 修正内容を履歴に反映することです。ブランチ（作業スペース）を作って修正した内容をコミット（反映）というように使います。
- プルリクエスト
- レビューしてもらうことです。
作成したブランチをプルリクエストを送り、確認者にレビューしてもらいます。プルリクエストにOKが出ると、晴れてブランチをメインに合流することができます。
- マージ
- 分岐（ブランチ）の差分を合流することです。
主にブランチを作成→作業をコミット→プルリクエストを出す→OKが出たらマージ、という流れで作業が進みます。
- コンフリクト
- マージ（合流）のタイミングなどで競合が発生することです。同一ファイルに違う変更が発生したときにコンフリクトが起きます。
どちらを最新版として活かすかは、作業者同士の話し合いで決定します。
他にもステージ（コミット前にファイルを一時的に置く場所）、フェッチ（リモートリポジトリの変更をローカルに反映させる）、リセット（修正をなかったことにする）など今回書ききれていないたくさんのGitキーワードがあります。初学者には頭が痛くなりますね。
Gitの機能を使いながら作業に応じて徐々に覚えていくと良さそうです。
クリエイティブチームで使っているGUIクライアント（Sourcetree）
エンジニアの皆様におかれましてはほぼ通称「黒い画面」でGitを操作されているかと存じますが、我々デザイナーはGUI大好き。視覚操作大好き。
ということで、ほぼ100%クリエイティブチームではGitの操作にはGUIクライアントの「Sourcetree」を使用しております。
困った時に検索するとSource Treeでの解決方法も見つかることが多いツールです。
WindowsとMacの両方に対応しているのもありがたいところ。
公式サイト
https://www.atlassian.com/ja/software/sourcetree
なんといっても視覚的にGitの状態が見られるのが魅力ですよね。
各操作もGit用語さえわかっていれば、シンプルで見やすいインターフェイスで操作ができます。
Git運用ルールを作ってみた
Gitを管理するオンラインの場所（リモートリポジトリ）もできた、Gitを操作するGUIクライアントも入れた！ということで運用を開始したのですが、いくつか改善点が出てきました。
デメリットの項目にも書いたのですが「ルールを決めないとカオスになる」ということで、いくつかルールを決めてみました。
共通のコード整形を行う
元々開発納品時にエンジニアさんからのご要望で頂いたことから開始しましたが、コーディング時のインデントやスペースを入れるルールが人によって違うと、予期せぬところで差分が発生してしまうため、コード整形用のフォーマッターを使い、自動で同じ状態にコード整形されるようにしました。
ブランチ名やコミットの命名規則を決める
ルールを決める前は、Sourcetreeで一覧を見たときにブランチ名やコミットの命名規則がバラバラでした。
「テキスト修正しました」など、一覧を見たときにどこのコンテンツを変えたのかわからない…！などの事例もしばしば。
スタッフからの提案で、ブランチ名にはどの案件のなんの作業なのか、コミット名には何をやったか（修正・追加・変更など）がわかるようにルール決めを行いました。
作業の流れとブランチ・コミット・マージタイミングを決める
これも人によってマージタイミングやコミットをどのタイミングでしたら良いかなどある程度決まりがあったほうがやりやすかったためルールとして決めました。
ブランチのマージタイミングはまだ検討中の部分もありますが、基本的に「リリースしたら」にしています。
また、細かいですが「OKの場合、確認者は必ずプルリク上でコメント」などもルールとして設定しています。（GIT上で一連の流れを追えるように）
こんな感じで、状況に応じて随時更新しながら運用ルールを決めています。
すでにがっつり運用されている方々から見ると独特な部分もあるかもしれませんが、手探りで運用中です。
まとめ
GITの運用に関しては引き続き模索中ではありますが、「最新版を共有に置き忘れて差分が発生した」「うっかり人の更新分を上書きした」などのエラーは絶賛阻止できているかなと思います。
非エンジニアにはなかなかとっつきにくいGITではありますが、特にチームで制作を行う際に威力を発揮するので、おすすめです！
参考リンク
※当サイトのリンクに関しては、アフィリエイトリンクは含まれておりません
