Categoria
Status checks são notificações automáticas que provedores de CI (Integração Contínua) enviam para plataformas Git como GitHub, GitLab e Bitbucket, informando o estado de execução de jobs específicos. Cada check pode ter status como pending, success, failure, error ou cancelled. Quando configurados como gate de merge, esses checks determinam se um pull request (PR) pode ser mesclado ao branch de destino.
O Semantic Versioning (SemVer) é um padrão de versionamento que comunica o impacto de mudanças em software através de uma estrutura numérica de três partes: MAJOR.MINOR.PATCH. Cada componente segue regras rígidas de incremento:
O comando git rebase -i (ou git rebase --interactive) é uma das ferramentas mais poderosas do Git para reescrever o histórico de commits. Diferente do rebase comum, que simplesmente aplica commits de uma branch sobre outra, o rebase interativo permite que você modifique, reordene, combine ou exclua commits individuais antes de aplicá-los novamente.
O git rebase tradicional, quando encontra um commit de merge durante a reescrita do histórico, simplesmente o ignora e lineariza os commits que o compõem. Considere o seguinte cenário:
O git rebase é uma ferramenta poderosa que permite reescrever o histórico de commits de um repositório Git. Diferentemente do merge, que cria um commit de fusão explícito, o rebase reaplica commits de uma branch sobre outra base, resultando em um histórico linear e mais limpo.
O Git mantém dois tipos de histórico: o histórico de commits, que é compartilhado com outros desenvolvedores via push e pull, e o reflog (reference log), que registra todas as ações locais que movem os ponteiros de referência do seu repositório. Enquanto o histórico de commits mostra apenas o estado dos commits em si, o reflog documenta cada operação que alterou onde HEAD ou um branch apontava.
Release branches são ramificações temporárias no Git criadas especificamente para preparar uma nova versão do software para produção. Seu propósito principal é isolar o processo de estabilização — correções de bugs, ajustes de documentação e configurações finais — sem interromper o desenvolvimento de novas funcionalidades na branch principal.
O Git oferece um mecanismo poderoso e pouco conhecido chamado replace objects. Diferente de operações destrutivas como git rebase ou git filter-branch, que reescrevem o histórico e exigem força para atualizar branches remotos, o git replace permite substituir objetos localmente sem alterar o SHA dos commits originais.
A Repo tool nasceu de uma necessidade concreta no desenvolvimento do Android. Quando o Google começou a gerenciar o código-fonte do Android, enfrentou um desafio monumental: centenas de repositórios Git independentes que precisavam ser coordenados como um único projeto. O Git, por si só, não foi projetado para gerenciar múltiplos repositórios de forma coesa.
No Git, um repositório remoto é uma versão do seu projeto hospedada em outro local — geralmente em um servidor como GitHub, GitLab ou Bitbucket. Ele funciona como um ponto central de sincronização entre desenvolvedores, permitindo que todos compartilhem alterações sem depender de cópias locais espalhadas.