バージョン管理のベストプラクティス

これは、ワークフローを最も簡単に改善できる部分ですが、開発者によっては最も苦労する部分でもあります。他のプロジェクト管理ツールで作業する場合、すでに作業を管理しやすい小さなタスクに分解している可能性が高いです。コミットはまったく同じように扱うべきです。

1 つのコミットは、1 つのタスクまたはチケットにのみ関連する必要があります。ただし、1 行のコードで複数のバグが魔法のように修正される場合を除きます。大きな機能に取り組んでいる場合は、それを小さなタスクに分解し、それぞれに対してコミットします。

小さなコミットを使用する最大の利点は、何か問題が発生した場合に、望ましくない変更をより簡単に検出して元に戻すことができることです。

コミットメッセージは、プロジェクトの履歴を記述します。結局のところ、ゲームにハイスコアテーブルを追加した変更は、コミットメッセージに「この新しいテーブルで私のスコアを超えることはできないでしょう！」ではなく、「メニューにハイスコアテーブルを追加しました！」と表示されていれば、はるかに簡単に見つけることができます。

Jira や GitLab などのタスクチケットシステムを使用する場合は、コミットにチケット番号を含めるとさらに便利です。多くのシステムは、スマートコミットと連携して動作するように設定できるため、コミットメッセージからチケットを参照したり、ステータスを変更したりすることができます。

たとえば、「JRA-123 #close #comment task completed」というコミットを行うと、Jira チケット JRA-123 が閉じられ、チケットに「task completed」というコメントが残ります。

このワークフローの設定の詳細については、JiraのドキュメントまたはGitLabのPivotal Trackerサービスを参照してください

「commit -a」（「すべての変更をコミット」する Git コマンド）またはその対応するコマンドを使用すべきなのは、プロジェクトの最初のコミット時のみです。通常、プロジェクト内のファイルは README.md のみです。

コミットには、リポジトリにコミットする変更に関連するファイルのみを含める必要があります。Unity プロジェクトでは、シーン、プレハブ、スプライトアトラスなどの一部のファイルに変更を加えるつもりはなかったにもかかわらず、変更が加えられたマークが付けられることがあるため、特に注意が必要です。

例えば、他の人が作業中のシーンに誤って変更をコミットしてしまうと、その人が変更をコミットしに行って、最初に変更をマージする必要があることに気付いたときに頭を悩ませることになります。

これはバージョン管理を始めたばかりの人が犯しがちな間違いの 1 つです。重要なのは、プロジェクトにコミットするのは自分の変更のみであることです。詳細については、ワークフローを高速化する方法に関するこちらのブログ記事をご覧ください。

必要に応じて、リポジトリから最新の変更を作業用コピーにプルします。マージ競合の可能性が高まるだけなので、単独で作業するのは得策ではありません。各システムの一般的な日常ワークフローについては、上の表を参照してください。

Plastic SCM のワークフローは少し異なり、集中型、分散型、またはマルチサイト構成で作業できます。

マルチサイト構成は、各ユーザーが集中型ワークフローまたは分散型ワークフローのいずれかで作業するなど、かなりユニークなものになる場合があります。

以下の例を考えてみましょう。

• 2 つのチーム
• 各チームにオンサイトサーバーがある
• チームメンバーは、ローカルまたは各サイトで分散してチェックインしますが、オンサイトに近いサーバーの速度のメリットを享受できます。
• サーバー間でプッシュおよびプルを行い、完全または部分的に同期を維持する

チームが使用する VCS に関係なく、全員が使い慣れ、自由に使えるツールを理解していることを確認してください。

Git を使用している場合、全員が同じ GUI クライアントを使用する必要はありません。ただし、コミット>プル>プッシュのワークフローで全員が快適に作業できることを最優先事項にしてください。つまり、必要なファイルだけをコミットする知識を持っている必要があります。

Plastic SCM を使用している場合は、ワークフローを簡素化する使いやすい GUI である Gluon に慣れるよう、チームのアーティストに働きかけてください。Gluon では作業するファイルを自由に決められるため、プロジェクト全体をダウンロードして管理する必要はありません。また、ファイルをロックして、他の人が作業できないようにすることもできます。完了したら、ファイルをリポジトリに送信し、必要に応じて再度ロックを解除します。

複数のリリースサイクルを持つ長期的なプロジェクトで作業する場合、機能ブランチはワークフローにとって非常に有益です。多くの場合、チームはトランク、マスター、メインと呼ばれるリポジトリの同じブランチで作業します。

これを行うと、プロジェクト全体が同じタイムラインに沿って動きます。しかし、チームとしてより効果的に共同作業を行うには、作業を複数のブランチに分割すると便利です。

Git では、Git Flow と呼ばれる特定のワークフローは、機能、バグ修正、リリースに異なるブランチを使用することに焦点を当てています。

そのため、開発者が孤立したブランチ内で新しい機能の開発を開始した場合、作業が完了するとメインブランチにマージされます。一方、別のチームメイトは、前のリリースでホットフィックスを行ったり、バグを修正したりして、開発中の機能を含めずに新しいバージョンを安全にリリースすることができます。

Plastic SCM にはタスクブランチもあります。このパターンでは、追跡するタスクごとに新しいブランチを作成します。Git Flow では、機能ブランチを使用して完全な（ときには大きな）機能を開発します。Plastic SCM のタスクブランチは短期的なものです。タスクの実装にいくつかのコミットが必要な場合、そのタスクは小さなタスクに分割できる可能性が高いです。

Perforce Helix Core は、Streams と呼ばれるシステムを使用して、このスタイルのワークフローを促進します。作業用のデポを作成する場合は、ストリームデポタイプとして設定する必要があります。その後、ストリームグラフビューを使用して新しいストリームを作成できます。メインラインストリーム以外のすべてのストリームは、変更を上流にコピーできるように、親ストリームを持つ必要があります。

ストリームには目的に応じてさまざまな種類があります。ローカルワークステーションでストリームを切り替えたり、変更をアップストリームにコピーして戻したりすると、変更されたファイルのメタデータのみがマージされるため、コンテキストの変更がより迅速になります。

機能ブランチの作業が完了したら、プルリクエストを使用して変更をリポジトリのメインストリームに戻すことをお勧めします。プルリクエストは機能やタスクの開発者が作成します。通常、変更をメインラインに受け入れる前にレビューするのは、上級開発者または DevOps の責任です。

Plastic SCM と Perforce はどちらも、ブランチをメインラインに戻すマージを管理するのに役立つ自動化ツールを備えています。Plastic SCM は、Mergebot を使用してこれを行います。Mergebot は、レビューと検証に合格すると、リポジトリのブランチを自動的にマージします。Perforce には、コードレビューの管理に使用される追加のプラットフォーム Helix Swarm があります。これは自動テストでも設定できます。

個人でプロジェクトに取り組んでいる場合でも、組織とバージョン管理の原則は非常に有用です。

チームと作業するときは、明確なコミュニケーションを優先させることが重要です。グループとして、プロジェクトをどのように構成するか、どのバージョン管理システムを使用するか、そのシステム内でのワークフローはどのようにあるべきかなどのガイドラインについて合意する必要があります。

こうすることで、Jira、GitLab、ビルドツール、自動テストなど、他のツールの統合を開始したときに、プロジェクトやワークフローの構築にすでに行った作業が、独自のものになります。