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

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

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

コミット メッセージにはプロジェクトの履歴が記述されます。結局のところ、コミット メッセージに「これらの新しいテーブルで私のスコアを上回ることはできないでしょう!」と書かれるよりも、「メニューにハイスコア テーブルを追加しました」と書かれる方が、ゲームにハイスコア テーブルを追加した変更を見つけるのがはるかに簡単になります。

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

たとえば、「JRA-123 #close #comment task completes」というコミットでは、Jira チケット JRA-123 がクローズに設定され、チケットに「task completes」というコメントが残ります。

このワークフローの設定の詳細については、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、ビルド ツール、自動テストなどの他のツールを統合し始めるときに、プロジェクトとワークフローの構造化ですでに行った作業が活かされるようになります。