Git workflow para desenvolvedores C#: do caos à ordem

Git workflow para desenvolvedores C#: como parar de temer merges e começar a viver

Você já passou meio dia tentando descobrir quem e quando reescreveu seu amado método CalculateOrderTotal()? Ou talvez você tenha enviado um "fix urgente" direto para o master, e depois a produção caiu com um erro NullReferenceException? Familiar? Bem-vindo ao clube dos desenvolvedores C# que tentam sobreviver ao caos do Git sem um workflow claro.

Se você acha que Git é apenas git add . e git push, está perdendo o essencial. Um Git workflow correto não é uma disputa religiosa, mas uma ferramenta que economiza nervos, tempo e dinheiro. Especialmente no mundo C#, onde temos soluções (.sln), projetos (.csproj) e vários pacotes NuGet que adoram entrar em conflito.

Neste artigo, mostrarei estratégias de branching funcionais, exemplos reais de código para C# e como automatizar a rotina. Vamos lá!

Por que projetos C# exigem uma abordagem especial para Git?

Ao trabalhar com C#, você não lida apenas com arquivos de texto. Você tem:

• Solução (.sln) — um arquivo que referencia todos os projetos. Se dois desenvolvedores adicionam um novo projeto simultaneamente, o merge conflict é garantido.
• Arquivos .csproj — arquivos XML que são atualizados ao adicionar pacotes NuGet ou alterar o Target Framework. Mesclar esses arquivos manualmente é uma dor.
• appsettings.json e web.config — configurações que geralmente contêm strings de conexão. Elas não devem ser commitadas, mas todos esquecem.
• Pastas bin/ e obj/ — se você as commitar uma vez, seus colegas o amaldiçoarão para sempre.

Portanto, seu Git workflow para C# deve ser cuidadosamente planejado. E começa com o .gitignore correto.

Passo 1: Configuração do .gitignore para C#

O .gitignore padrão para C# pode ser baixado do GitHub/gitignore, mas adicionarei algumas linhas importantes que frequentemente são esquecidas:

# Arquivos de configuração com segredos (não commitar!)appsettings.Development.jsonappsettings.Local.jsonsecrets.json

# Arquivos gerados pelo ReSharper ou Rider*.DotSettings.user*.DotSettings

# Pacotes NuGet (cache)packages/*.nupkg

# Resultados de testesTestResults/*.trx

# Pastas do Visual Studio.vs/*.suo*.user*.sln.docstates

Por que isso é importante? Imagine que você commita appsettings.Development.json com uma string de conexão local ao banco de dados. O colega faz pull e a aplicação dele falha porque ele não tem esse banco. Parece um pequeno descuido, mas consome uma hora de trabalho.

Escolhendo uma estratégia de branching para a equipe C#

Existem vários Git workflows populares. Para projetos C#, recomendo duas estratégias principais: Git Flow e Trunk-Based Development. Vamos analisá-las com exemplos.

Opção 1: Git Flow (clássico para projetos grandes)

Git Flow é como o SOLID para o Git. É ideal quando você tem releases claros (por exemplo, versão 2.1.0, 2.2.0). As branches ficam assim:

• main — apenas código estável.
• develop — branch de integração.
• feature/XXX-123-add-new-api — funcionalidades a partir de develop.
• release/2.1.0 — preparação do release.
• hotfix/2.0.1-critical-bug — correções urgentes a partir de main.

Exemplo para C#: você está trabalhando em uma nova funcionalidade "Cálculo de desconto por cupom".

# Criando uma funcionalidade a partir de developgit checkout developgit pullgit checkout -b feature/ABC-42-add-promo-discount

# Escrevendo código em C#// DiscountService.cspublic class DiscountService{    public decima