Unity Version Control ou Git? Versionar Projeto Unity

Unity Version Control vs Git: para a maioria dos projetos indie pequenos com time de programadores, Git com Git LFS no GitHub resolve e é o que mais aparece em vaga e em portfólio. Unity Version Control faz mais sentido quando o time tem artistas que trabalham com arquivos binários grandes e precisam de travamento de arquivo e de uma interface simples. Abaixo você tem os limites gratuitos conferidos em outubro de 2026, o setup de cada um, uma tabela de decisão e as configurações do Editor que valem para os dois.

Por que projeto Unity exige cuidado no versionamento

Um projeto Unity tem três particularidades que pegam quem já usa Git em web ou backend:

1. Arquivos .meta. Cada arquivo dentro de Assets tem um .meta ao lado com o GUID que a Unity usa para ligar referências. Perdeu o .meta, a Unity gera outro GUID e todas as referências para aquele asset quebram (o famoso "Missing" no Inspector).
2. Cenas e prefabs são YAML grandes. Duas pessoas mexendo na mesma cena geram conflito em arquivos de milhares de linhas que ninguém lê à mão.
3. Binários pesados. Texturas, áudio, modelos 3D e vídeos ocupam gigabytes e mudam a cada exportação do artista.

E uma pasta que nunca deve ir para o repositório: Library. Ela é cache gerado pela Unity, pode passar de vários gigabytes e é recriada sozinha ao abrir o projeto. O mesmo vale para Temp, Logs, obj, UserSettings e builds.

Qualquer sistema que você escolher precisa resolver esses três pontos. Os dois resolvem, de jeitos diferentes.

Unity Version Control: o que é e o plano gratuito

Unity Version Control (UVCS) é o antigo Plastic SCM, comprado pela Unity e integrado ao Unity DevOps. Ele foi pensado para jogo desde o começo: lida bem com binários grandes sem extensão extra, tem travamento de arquivo (lock) para quem mexe em arte e oferece dois jeitos de trabalhar, um completo com branches para programadores e um mais simples (Gluon) para artistas que só querem pegar e devolver arquivos.

Você usa pelo cliente desktop ou pela integração no Editor, criando o repositório no painel do Unity Cloud vinculado à sua organização.

Plano gratuito na nuvem pública da Unity, conferido em 19/10/2026 na página de preços e no artigo de suporte da Unity sobre cobranças do DevOps (valores válidos desde 1º de março de 2026):

• Usuários: sem cobrança por assento e sem limite de usuários na nuvem pública, inclusive no Unity Personal.
• Armazenamento: 25 GB por organização por mês sem custo, compartilhado com artefatos do Build Automation. Acima disso, a cobrança é por GB armazenado (confira o valor na página de preços).
• Download (egress): 100 GB por mês sem custo. Acima disso, US$ 0,10 por GB.

Para um projeto 2D pequeno, 25 GB sobra. Para um 3D com muita textura em 4K, o armazenamento cresce rápido porque cada versão de binário fica no histórico.

Git + Git LFS: setup para Unity

Git é o padrão do mercado de software, roda em qualquer host (GitHub, GitLab, Bitbucket, Azure DevOps ou servidor próprio) e tem ferramenta para tudo. O ponto fraco é binário grande, resolvido com Git LFS, que guarda os arquivos pesados fora do histórico e deixa ponteiros leves no lugar. A base de Git está explicada no post de Git para projeto de jogo; aqui vai o que é específico de Unity.

Limites gratuitos do Git LFS no GitHub, conferidos na documentação de cobrança do GitHub em 19/10/2026: contas GitHub Free, Pro e organizações Free têm 10 GiB de armazenamento e 10 GiB de banda por mês. Com orçamento em US$ 0, ao estourar a banda o LFS fica bloqueado até o mês seguinte. Num time de quatro pessoas clonando um projeto com 2 GiB de arte, a banda acaba rápido.

Setup na raiz do projeto (a pasta que contém Assets):

git init
git lfs install

# Binários pesados vão para o LFS
git lfs track "*.png" "*.psd" "*.tga" "*.exr"
git lfs track "*.wav" "*.mp3" "*.ogg"
git lfs track "*.fbx" "*.blend" "*.obj"
git lfs track "*.mp4" "*.ttf" "*.otf"

git add .gitattributes

O .gitignore mínimo para Unity:

/[Ll]ibrary/
/[Tt]emp/
/[Oo]bj/
/[Bb]uild/
/[Bb]uilds/
/[Ll]ogs/
/[Uu]ser[Ss]ettings/
*.csproj
*.sln
.vs/
.idea/

O post de .gitignore para Godot e Unity explica cada linha e cobre os casos de IDE e sistema operacional. O detalhe que mais falha: o .gitignore tem que estar na mesma pasta que Assets. Se o repositório começa uma pasta acima, os caminhos com / no início não casam e a Library sobe inteira.

Para arquivos binários que duas pessoas não podem editar ao mesmo tempo, o Git LFS tem travamento: marque o padrão como lockable (git lfs track "*.psd" --lockable) e use git lfs lock Assets/Art/hero.psd antes de editar. Funciona no GitHub, mas depende de o time lembrar de travar.

Unity Version Control vs Git: tabela de decisão

Resumo prático: solo ou time só de programadores, Git. Time com artistas mexendo em PSD e FBX todo dia, Unity Version Control merece um teste. Projeto que você quer mostrar no portfólio, Git no GitHub, porque é onde o recrutador vai olhar.

Escolher a ferramenta é a parte fácil. O que trava projeto de verdade é organizar o jogo para que versionar seja tranquilo: cenas divididas, prefabs pequenos, pastas que fazem sentido. Isso só aparece quando você junta movimento, UI, áudio e arte num jogo inteiro e começa a ter conflito. No curso de Unity os projetos são montados com Git desde o primeiro commit e com a estrutura de cena e prefab pensada para não brigar com o versionamento.

Merge de cenas e prefabs com UnityYAMLMerge

A Unity instala junto com o Editor uma ferramenta chamada UnityYAMLMerge (o recurso na doc se chama Smart Merge), que entende a estrutura de cenas e prefabs e resolve conflitos que um merge de texto comum estragaria.

Onde ela fica: dentro da pasta de instalação do Editor, em Editor\Data\Tools\UnityYAMLMerge.exe no Windows. Com o Unity Hub, o caminho completo fica parecido com C:\Program Files\Unity\Hub\Editor\<versão>\Editor\Data\Tools\UnityYAMLMerge.exe. No macOS, em Unity.app/Contents/Helpers/UnityYAMLMerge.

Configure no .git/config do projeto ou no seu .gitconfig:

[merge]
    tool = unityyamlmerge

[mergetool "unityyamlmerge"]
    trustExitCode = false
    cmd = 'C:/Program Files/Unity/Hub/Editor/<versão>/Editor/Data/Tools/UnityYAMLMerge.exe' merge -p "$BASE" "$REMOTE" "$LOCAL" "$MERGED"

Quando aparecer conflito numa cena, rode git mergetool. A ferramenta junta o que der e só pede ajuda no que realmente colidiu (as duas pessoas mudaram a mesma propriedade do mesmo objeto).

No Unity Version Control, a configuração de Smart Merge fica em Edit > Project Settings > Version Control.

Merge automático ajuda, mas a prevenção vale mais: cada pessoa trabalha em prefabs ou em cenas aditivas separadas, e a cena principal só junta as peças.

Configurações obrigatórias: Visible Meta Files e Force Text

Duas configurações do Editor fazem o versionamento funcionar. No Unity 6.3 as duas já vêm no padrão certo, mas confira em projeto antigo ou importado:

• Edit > Project Settings > Version Control > Mode: Visible Meta Files. Deixa os .meta visíveis no disco para o Git enxergar. É o padrão.
• Edit > Project Settings > Editor > Asset Serialization > Mode: Force Text. Salva cenas, prefabs e materiais como YAML de texto, o que permite diff e merge. É o padrão. Em modo binário, todo conflito vira "escolha a minha versão ou a sua".

Na mesma seção Asset Serialization existe a opção Reduce version control noise, que escreve referências em uma linha só e deixa os diffs mais limpos.

Erros comuns: .meta perdido, Library no repositório

.meta esquecido no commit. Alguém adiciona hero.png e não adiciona hero.png.meta. No computador do colega, a Unity cria um GUID novo e o prefab perde a referência. Regra: arquivo e .meta sempre juntos. Não coloque *.meta no .gitignore em hipótese alguma.

Mover arquivo pelo Explorer. Mover ou renomear fora do Editor separa o arquivo do .meta. Mova sempre pela janela Project.

Library no repositório. O primeiro push leva uma eternidade, o repositório incha e cada pessoa gera conflitos em arquivos de cache. Se já subiu, adicione ao .gitignore e rode git rm -r --cached Library.

LFS configurado depois. Se os PNGs já foram commitados sem LFS, eles continuam no histórico normal. Para migrar, existe git lfs migrate, que reescreve o histórico e exige cuidado em time.

Banda do LFS estourada no GitHub. O CI clona o projeto inteiro a cada execução e consome os 10 GiB em poucos dias. Use cache de LFS no CI ou limite quando ele roda.

Próximo passo

Pegue o projeto Unity em que você está trabalhando, confira Visible Meta Files e Force Text, crie o .gitignore, configure o LFS e faça o primeiro commit no GitHub. Depois configure o UnityYAMLMerge antes de precisar dele. Para entender melhor como o LFS funciona por baixo, leia o guia de controle de versão para jogos com Git LFS.