Resolvendo conflitos
- Conhecimentos básicos em Git.
- Visual Studio Code/VSCode ou VSCodium (recomendado).
- Extensão GitLens para VSCode/VSCodium.
Nota: Você não precisa usar VSCode/VSCodium necessariamente, mas atualmente é a forma como nós ensinamos e realizamos as modificações.
Resolvendo conflitos e traduções (passo 3 do ciclo básico de desenvolvimento
- Após os passos 1-2 do ciclo, a branch
conflitos-pendentespoderá conter conflitos e textos em Inglês. - Caso não tenha acesso de escrita ao repositório, faça um fork do repo antes de prosseguir, e siga o guia fazendo as modificações no fork.
- Você deve visitar os arquivos um por um para verificar se existe textos em Inglês, erros, e conflitos.
- Caso você mesmo tenha realizado os passos 1-2, talvez você saiba exatamente quais arquivos você deve modificar e não precisará visitá-los um por um.
- O conflito estará visualmente representado no VSCode/VSCodium: a parte verde é o código que já estava no Privacidade.Digital e a parte azul é o código do PrivacyTools.io que entrou em conflito com o nosso.
- Accept Current Change: Desconsidera a parte azul (PrivacyTools.io) e mantém a parte verde (nosso código atual).
- Accept Incoming Change: Desconsidera a parte verde (nosso código atual) e aceita a azul (PrivacyTools.io). Repare que nesse caso só fazer isso não é o bastante, visto que você provavelmente terá que traduzir/localizar alguns trechos que estarão em Inglês.
- Accept Both Changes: aceitar ambas as partes (não recomendado). Você provavelmente sempre terá que fazer adaptações e traduções no código caso escolha essa opção.
- Compare Changes: compara ambas as partes, para sua referência. É útil para ver quais linhas de código mudaram, evitando que você se deixe algo passar batido.
- Você não poderá rodar o site localmente enquanto modifica a branch
conflitos-pendentes, a menos que você tenha terminado de resolver todos os conflitos. No entanto, tentar rodar o site combundle exec jekyll servepode ser útil, pois você receberá erros no terminal que podem te indicar onde estão certos conflitos, caso esteja difícil localizá-los. - Mantenha aberto em seu navegador o site Privacidade.Digital e o site PrivacyTools.io para que você possa comparar a versão atual de ambos.
- Mantenha uma cópia local do repositório e o abra em outra janela em outro editor de textos, mas na branch
main. Dessa forma você poderá rodar o site localmente e abri-lo em seu navegador. Poderá então fazer modificações rápidas e ver seus resultados no navegador, para testar antes de modificar de verdade na branchconflitos-pendentes.
Você deve fazer commits conforme avança seu progresso nesse passo. Uma sugestão é fazer 1 commit por arquivo traduzido/consertado, mas isso vai de cada um. O importante é separar os commits por ações não tão grandes, e seguir a convenção de que a mensagem do commit deve estar em Português e no tempo verbal presente do indicativo, omitindo o sujeito. Dessa forma a mensagem do commit indica o que o commit faz. Exemplos de mensagens de commit: "Resolve conflitos na página Sobre Nós"; "Traduz seção sobre gerenciadores de senha"; "Apaga imagens desnecessárias".
Após fazer o commit, você pode atualizar o repositório remoto com git push origin conflitos-pendentes. Deve fazer isso até todos os conflitos do projeto serem resolvidos e você poder rodar o site localmente na branch conflitos-pendentes.
Se você estiver trabalhando pelo seu fork, após uma quantidade significativa de trabalho, talvez você decida levar as suas contribuições para nosso repositório de fato. Para isso, crie um Pull Request sempre após alguns commits. Trate o Pull Request como se fosse um conjunto de commits que alcancem um objetivo maior. Exemplo: uma série de commits resolve conflitos e traduções nos arquivos da página principal do site.
Não espere para fazer o Pull Request quando terminar todos os conflitos da branch, isso pode gerar mais conflitos, especialmente se forem muitos commits!
Linhas 32-36 do código na imagem abaixo.
A parte verde do conflito representa o código atual do Privacidade.Digital, e a parte azul representa o código vindo do repositório PrivacyTools que gerou o conflito. Precisamos decidir se o código novo trás novidades úteis e caso traga, deveremos modificar a parte verde e adotá-la.
Nesse caso, nós não iremos modificar nenhum conteúdo, porque a parte azul não trás nada de novo ou importante. Então iremos clicar em Accept Current Change sem fazer nenhuma outra modificação.
Conflito resolvido! Mas repare que nesse mesmo arquivo, há mais conflitos. Idealmente, iremos resolver todos os conflitos num arquivo antes de fazer um commit e partir para o próximo arquivo. Mas para razões de tempo e para esta guia, irei fazer o commit desse conflito resolvido para que você dê uma olhada: commit 129a5501b42d8e3f7d4dc2d1c0ea3c9a8453e259. Tentarei fazer o mesmo nos próximos exemplos.
Revisão geral do projeto (passo 4 do ciclo básico de desenvolvimento)
Quando você resolver todos os conflitos e conseguir rodar o site localmente, os colaboradores frequentes devem mesclar essas modificações na branch revisando. E então todos os colaboradores frequentes ativos devem revisar todos os arquivos e seções do site, verificando se tudo parece bom pelo navegador também. Não sinta que esse passo é desnecessário, pois é o que vai fazer com que nosso site permaneça detalhadamente bem feito. Peça ajuda de outros membros e colaboradores, ou até mesmo de pessoas que você conheça e seriam boas de revisar textos e/ou código web.
Caso você não tenha acesso de escrita no repo, você provavelmente não poderá participar dessa revisão, a não ser que esteja se comunicando com nossos colaboradores frequentes através de um método de contato para que possamos coordenar a sua revisão.
Após a revisão e melhorias no código, você deve se certificar de que ele está apresentável para ser colocado no ar (dê uma última olhada rápida), e então terminar de fazer os commits (e pull requests caso aplicável). Por fim, passe para o próximo passo do ciclo de desenvolvimento.