TL;DR: adicionei ao GitByBit uma nova prática temática que ensina a mergear, fazer rebase e resolver conflitos. Ela está disponível na versão mais recente do GitByBit para VS Code.
Você já mergeou uma branch e deu de cara com um paredão de marcadores de conflito? Ou puxou alterações de um repositório remoto só para descobrir que suas alterações locais batem de frente com as que chegaram? Esse é um dos aspectos mais frustrantes do Git, principalmente para quem está começando.
Conflitos de merge: o pesadelo de todo usuário de Git.
Por isso, adicionei ao GitByBit uma nova prática temática chamada "Merge, rebase e resolução de conflitos". Nesta prática, você vai:
- Entender por que tanto alvoroço em torno de merge versus rebase, e quando usar cada um.
- Explorar quando o Git faz um merge fast-forward e quando cria um commit de merge — e por que essa diferença importa.
- Ensaiar rebases e merges em branches do mundo real sem tocar em repositórios de produção.
- Aprender a escolher a estratégia de integração certa para o seu projeto e as convenções da sua equipe.
Conflitos fazem parte do trabalho em equipe, então a prática não foge deles. Você vai ver como os conflitos surgem, aprender a identificar o que importa nos marcadores de conflito e resolver os conflitos usando tanto o terminal quanto uma interface gráfica.
Por fim, a prática guia você por um cenário comum de push rejeitado. Você se coloca no papel de quem já tem experiência com Git e ajuda um colega de equipe a subir as alterações dele para um repositório remoto, enquanto navega por erros crípticos e conflitos de merge.
A nova prática de merge e rebase já está disponível na versão mais recente do GitByBit para VS Code.
TL;DR: perdi várias semanas de novos usuários por causa de um bug aleatório na nova versão do VS Code. Lição: se puder, implemente monitoramento de erros em tempo real desde cedo.
Desenvolver um projeto solo é difícil. Você precisa se desdobrar em vários papéis: dev, designer, marketing, suporte e mais um monte. É preciso equilibrar várias tarefas e prioridades ao mesmo tempo, e às vezes alguma coisa passa batido.
Na primeira semana de julho, uma atualização aleatória do VS Code mudou o sistema interno de autenticação, fazendo as versões existentes do GitByBit entrarem em um loop infinito logo na inicialização. Na prática, ninguém conseguia usar o curso até esse problema ser resolvido. Sem desconfiar de nada, eu estava trabalhando na futura prática de pull request (que, aliás, é superlegal e saiu semana passada).
Em algum momento, alguém finalmente reportou o problema no GitHub, e aí consegui corrigir e lançar uma versão nova. Mas basicamente perdi várias semanas de novos usuários, porque eles não conseguiam usar o curso.
Quando você percebe que o seu projeto passou as últimas semanas sem funcionar.
A maioria dos meus outros projetos são web apps normais, servidos do meu próprio servidor. Como são construídos com frameworks populares, como Laravel ou React, é fácil integrar o app com algum sistema de monitoramento de erros em tempo real, como Sentry ou Rollbar. Assim, quando um erro acontece, sou notificado na hora, subo a correção para o servidor e todos os usuários a recebem imediatamente. Depurar o problema também é mais fácil, porque tenho acesso aos logs do servidor e consigo ver exatamente o que deu errado.
Só que o GitByBit não é um web app comum. Existe a extensão para VS Code e a versão web, cada uma com front-end e back-end separados. Tudo isso é construído com tecnologias diferentes, então monitorar erros não é tão simples quanto colocar uma chave de API do Rollbar em algum lugar da configuração. Até então, todos esses lugares enviavam telemetria de volta para o meu servidor principal, onde ela fica armazenada em um log centralizado.
Mas, infelizmente, não havia nenhum sistema de monitoramento para me alertar sobre erros em tempo real. Então, para descobrir os erros, eu tinha que abrir e ler isto aqui:
Não muito legível, a menos que você fale klingon.
Dá para monitorar logs assim de vez em quando, mas, a menos que seja logo depois de um lançamento, não é muito prático. Na maior parte do tempo, nada de ruim acontece, então você para de verificar os logs com frequência. Você até olha uma vez por semana, mais ou menos, mas aí outras coisas tomam o seu tempo e você esquece.
Na verdade, eu coleto... Mas também é preciso monitorar os logs, não só coletá-los.
Você parte do princípio de que, se algo der errado, vai ficar sabendo pelos usuários ou vai acabar vendo nos logs. Tem um fundo de verdade nisso, mas pode demorar até você notar o problema — e, a essa altura, talvez já tenha perdido um monte de usuários que não conseguiram usar o curso por causa do bug. Foi exatamente o que aconteceu com o projeto em julho.
Ei, Alex, você não era um desenvolvedor experiente? Por que não implementou um monitoramento de erros decente desde o início? Por que esperou até agora?
Ótima pergunta! Esse é o desafio de ser dev solo: é coisa demais para fazer, e você só tem duas mãos (espero). É preciso PRIORIZAR! Além disso:
- Eu já tinha logs básicos configurados, então dava para ver o que estava dando errado quando eu olhava.
- Eu estava atolado com todo o trabalho de conteúdo, então gastar semanas implementando infraestrutura de back-end não parecia uma prioridade tão grande.
- Isto aqui é acesso antecipado, então as pessoas meio que esperam encontrar problemas e bugs. Minha esperança era que, se algo desse errado, os usuários avisariam e eu corrigiria rápido.
Mas agora que o curso está ficando mais popular, acho que chegou a hora de ter um jeito melhor de monitorar erros e problemas em tempo real.
PostHog ao resgate
Faz alguns anos que tento me desgooglizar, mas ainda uso principalmente o Google Analytics nos meus projetos para acompanhar as interações dos usuários. Recentemente, descobri o PostHog e resolvi dar uma chance. Ele combina vários recursos de que preciso: rastreamento de eventos, gravação de sessões e monitoramento de erros. Também tem um plano gratuito generoso, então posso usá-lo no meu projeto em acesso antecipado sem me preocupar com custos por enquanto. E eles têm um mascote fofo, um ouriço chamado Max, que eu simplesmente adoro.
Se você não gosta do Max, você é uma pessoa ruim.
As diretrizes para desenvolvedores do VS Code proíbem usar scripts próprios de analytics dentro da extensão, principalmente por questões de desempenho e segurança. Porém, a telemetria coletada pela API do VS Code é permitida, então você pode recebê-la no seu servidor e reenviá-la para o PostHog ou qualquer outro serviço de analytics. Assim, ainda dá para acompanhar interações dos usuários e erros na sua extensão do VS Code sem violar as diretrizes.
Agora os erros são coletados em um formato legível, então consigo ver o que deu errado e onde. Erros duplicados são agrupados, então dá para ver quantos usuários foram afetados.
Cada erro traz uma boa quantidade de detalhes que podem ajudar a depurar o problema por trás dele. Depois que um erro é corrigido, você pode marcá-lo como resolvido, para que ele não fique bagunçando a lista.
Isso resolveu o problema de legibilidade e rastreamento, mas eu ainda precisava de um jeito de ser notificado sobre novos erros em tempo real. O PostHog tem um sistema de alertas embutido que envia notificações via Discord, Slack ou outros canais quando um erro novo acontece. Assim, fico sabendo de qualquer problema imediatamente e posso resolver rapidinho.
Agora, se eu ouço um fluxo constante de BOOP!!! vindo do Discord, sei que o curso quebrou. Aí posso conferir rapidinho o dashboard do PostHog e ver o que está errado.
TL;DR: agora você pode praticar a criação de pull requests no GitByBit!
Você já encontrou um bug no código de outra pessoa e pensou: "por que ainda não corrigiram isso?" Você abre uma issue, espera... e nada acontece.
Acontece o seguinte: você não precisa mais esperar.
Você pode arregaçar as mangas e enviar a correção por conta própria. É só abrir um pull request e conseguir o merge: de repente, todo mundo que usa aquela biblioteca se beneficia do seu trabalho.
Nunca dá para saber o que você vai puxar de um pull request.
Um bug de verdade, uma correção de verdade
A prática começa com um cenário bem plausível: seu app de atividades físicas buga quando alguém tenta registrar uma atividade em um campo de golfe usando distâncias em jardas. O app não sabe converter jardas em metros e trava. A correção é direta: adicionar a conversão que falta (1 jarda = 0,9144 metros). Você aplica o patch na biblioteca e segue com o seu dia.
Mas, depois de um tempo, chega uma atualização que quebra a sua correção. Você precisa reaplicar o patch. Aí acontece de novo. E de novo. Você percebe que está perdendo tempo com remendos inúteis, quando a correção deveria estar na própria biblioteca. Como fazer a correção chegar lá?
O poderoso pull request
A maioria dos projetos open source fica hospedada no GitHub ou em plataformas parecidas, e todas elas têm suporte a pull requests. Um pull request é uma forma de propor alterações em um projeto. Você forka o repositório, faz suas alterações e depois envia um pull request para o repositório original, sugerindo que suas alterações sejam mergeadas na base de código principal.
Além da parte técnica de forkar, criar branches e mergear, o processo de pull request também envolve comunicação. Você precisa explicar o que fez, por que é necessário e como isso melhora o projeto. É aqui que você pode mostrar que entende a base de código e que sabe contribuir direito. Não vai ajudar em nada se você estragar o pull request com mensagens de commit toscas, subir um monte de alterações sem relação entre si ou ignorar as diretrizes de contribuição do projeto.
Esse tipo de atitude nos comentários de um pull request não leva você a lugar nenhum.
Além disso, o vaivém de um pull request pode exigir que você atualize seu fork, faça rebase e resolva conflitos. Há todo um arsenal de habilidades de Git envolvido no processo, e agora você pode praticar todas elas no GitByBit, em um cenário realista com repositórios reais do GitHub.
Mandar bem em um pull request exige muita paciência e atenção aos detalhes.
Além da prática de pull request, adicionei várias entradas novas à Gitopedia, incluindo e . Também tem duas boas práticas novas: e .