setup-macos-developer

A pergunta que me fez criar este repositório não foi "como instalo minhas ferramentas?", foi "quanto tempo eu perco, e o que eu esqueço, toda vez que troco de Mac?".

Configurar uma máquina de desenvolvimento à mão parece barato porque acontece raramente. O custo aparece depois: o git sem a configuração de assinatura, o shell sem o alias que você usa vinte vezes por dia, a versão de runtime diferente da que o CI usa. Cada diferença dessas vira uma tarde de investigação de "na minha máquina funciona".

O custo que importa aqui não é o de instalar uma vez, é o de manter dois ou três ambientes coerentes ao longo de anos. Um script versionado resolve isso de um jeito simples: o estado desejado da máquina vira código, com histórico no Git, revisão por PR e a mesma régua de qualidade de qualquer outro repositório meu.

O escopo é deliberadamente estreito: macOS, Homebrew como gerenciador de pacotes e Bash como linguagem. Não é um framework de dotfiles genérico nem uma ferramenta de gestão de frota. É o setup da minha estação, publicado porque o padrão é reaproveitável.

O mecanismo é o mais simples possível, de propósito: um script Bash lê o estado desejado e o aplica na máquina, usando o Homebrew para pacotes e copiando ou ligando os dotfiles para o lugar certo. Não há agente, daemon nem servidor; o repositório não sabe quantas máquinas o usam.

O que torna isso sustentável não é o script, é a disciplina em volta dele. O repositório segue as convenções do fernandofatech/platform:

• Branch: <tipo>/<escopo>, com feat/, fix/, chore/ e docs/.
• Commit e título de PR: Conventional Commits.
• Versão: sai dos commits. Ninguém escreve número de versão à mão.

A pipeline (pr-lint, CI, segurança e release) vem dos workflows reutilizáveis do platform. A consequência prática: corrigir a régua de qualidade é mudar um arquivo lá, não em cada repositório. Num portfólio com dezenas de repositórios, essa é a diferença entre manter uma pipeline e manter vinte cópias dela que divergem em silêncio.

Para um repositório de setup, a release versionada também tem uso concreto: dá para dizer em que versão do setup uma máquina foi configurada e o que mudou desde então.

Shell imperativo resolve bem o primeiro setup e razoavelmente bem as reexecuções, desde que cada passo confira antes de agir (pacote já instalado, arquivo já no lugar). Ele não oferece o que uma ferramenta declarativa oferece: não há plano mostrando o que vai mudar antes de mudar, e remover um pacote da lista não o desinstala da máquina.

Também não há gestão de segredo aqui, e não deve haver. Chave SSH, token de API e credencial de nuvem ficam fora do repositório, em cofre ou gerados na máquina. Um repositório público de dotfiles com segredo dentro não é um descuido pequeno, é um incidente.

Por fim, o repositório é pequeno: 4 estrelas, nenhum fork, um mantenedor. Ele é um exemplo funcional e um ponto de partida para o seu fork, não um projeto com roadmap ou suporte.