Git worktree para múltiplas features simultâneas
Todo desenvolvedor que trabalha com Git conhece o ritual: você está implementando a feature A, quando chega uma urgência para corrigir um bug na branch main. O ciclo se repete:
Categoria
Todo desenvolvedor que trabalha com Git conhece o ritual: você está implementando a feature A, quando chega uma urgência para corrigir um bug na branch main. O ciclo se repete:
O arquivo .gitignore é um recurso fundamental do Git que permite especificar quais arquivos e diretórios devem ser intencionalmente ignorados pelo sistema de controle de versão. Quando você adiciona um padrão ao .gitignore, o Git automaticamente exclui esses arquivos de operações como git add, git status e git commit.
O merge (fusão) é uma operação fundamental no Git que permite integrar alterações de diferentes branches em um único branch unificado. Ele existe porque o desenvolvimento paralelo é uma realidade em projetos de software: diferentes pessoas ou equipes trabalham em funcionalidades distintas, correções de bugs ou experimentos ao mesmo tempo. Sem o merge, seria impossível consolidar essas contribuições de forma organizada.
Em times que não utilizam feature flags, cada deploy é também uma release. Isso significa que, ao fazer o merge de uma branch com código novo para main, a funcionalidade vai automaticamente para produção. Se algo der errado, o rollback exige reverter commits inteiros, o que pode causar downtime prolongado.
No contexto do Git e de plataformas como GitHub e GitLab, um fork é uma cópia completa de um repositório que fica sob sua conta pessoal. Diferente de um clone, que cria uma cópia local no seu computador, o fork é um repositório remoto independente que você controla totalmente.
No desenvolvimento de software moderno, a transparência sobre o estado do trabalho é essencial para equipes colaborativas. Work in Progress (WIP) refere-se a código que está sendo desenvolvido, mas ainda não está pronto para ser integrado ao branch principal. Sinalizar WIP corretamente evita confusões, merges acidentais e retrabalho.
O armazenamento de senhas em texto puro dentro do arquivo .gitconfig é uma prática extremamente insegura e desencorajada. Qualquer processo ou usuário com acesso ao sistema poderia ler essas credenciais comprometendo contas e repositórios inteiros. Além disso, a digitação repetida de credenciais a cada operação remota (git push, git pull, git fetch) torna o fluxo de trabalho tedioso e propenso a erros.
No Git, uma branch é essencialmente um ponteiro móvel para um commit específico dentro do histórico do repositório. Imagine uma linha do tempo do seu projeto: cada commit representa um ponto nessa linha, e uma branch é como um marcador que aponta para um desses pontos. Quando você faz um novo commit, a branch automaticamente avança para apontar para o novo commit.
O Git utiliza uma estratégia textual para resolução de conflitos: ele compara arquivos linha por linha, aplicando algoritmos como o "three-way merge" baseado no ancestral comum. Essa abordagem funciona bem para código-fonte, mas falha em cenários onde o conteúdo não é texto puro ou onde a estrutura do arquivo exige tratamento semântico.
O Git organiza suas configurações em uma hierarquia de escopos que permitem controle granular sobre o comportamento da ferramenta. A precedência segue esta ordem: --system (todo o sistema), --global (usuário), --local (repositório atual) e --worktree (árvore de trabalho específica).