diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index c237b4ba..2af5d9e6 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -7,11 +7,11 @@ Já que Git é muito flexível, as pessoas podem e trabalham juntas de muitas ma Algumas das variáveis envolvidas são a quantidade de colaboradores ativos, o fluxo de trabalho escolhido, sua permissão para fazer commit, e possivelmente o método de contribuição externa. A primeira variável é a quantidade de colaboradores ativos -- quantos usuários estão ativamente contribuindo para o código deste projeto, e em que frequência? -Em muitas circunstâncias você terá dois ou três desenvolvedores com alguns commites por dia, ou possivelmente menos em projetos meio dormentes. -Para grandes companhias ou projetos, o número de desenvolvedores pode estar nas centenas, com centenas ou milhares de commites chegando todos os dias. +Em muitas circunstâncias você terá dois ou três desenvolvedores com alguns commits por dia, ou possivelmente menos em projetos meio dormentes. +Para grandes companhias ou projetos, o número de desenvolvedores pode estar nas centenas, com centenas ou milhares de commits chegando todos os dias. Isto é importante porque com mais e mais desenvolvedores, você se depara com mais problemas para certificar-se que seu código é aplicado diretamente ou pode ser facilmente integrado. -Alterações que você entrega podem se tornar obsoletas ou severamente quebrar pelo trabalho que é mesclado enquanto você trabalha ou enquanto suas mudanças estão esperando para serem aprovadas e aplicadas. -Como você pode manter seu código consistentemente atualizado e seus commites válidos? +Alterações que você entrega podem se tornar obsoletas ou severamente quebradas pelo trabalho que foi mesclado enquanto você trabalhava ou enquanto suas mudanças estavam esperando para serem aprovadas ou aplicadas. +Como você pode manter seu código consistentemente atualizado e seus commits válidos? A próxima variável é o fluxo de trabalho em uso no projeto. Ele é centralizado, com cada desenvolvedor tendo permissões de escrita iguais para o código principal? @@ -31,11 +31,11 @@ Todas estas questões podem afetar como você contribui efetivamente para o proj Iremos abordar aspectos de cada uma delas em uma série de estudos de caso, indo do simples ao mais complexo; você deve ser capaz de construir fluxos de trabalho específicos para suas necessidades com estes exemplos. [[r_commit_guidelines]] -==== Diretrizes para Fazer Commites +==== Diretrizes para Fazer Commits Antes de vermos estudos de casos específicos, uma observação rápida sobre mensagens de commit. -Ter uma boa diretriz para criar commites e a seguir facilita muito trabalhar com Git e colaborar com outros. -O projeto Git fornece um documento que dá várias dicas boas para criar commites ao enviar patches -- você pode lê-lo no código fonte do Git no arquivo `Documentation/SubmittingPatches`. +Ter uma boa diretriz para criar commits e segui-la torna o trabalho com Git e a colaboração com outros muito mais fácil. +O projeto Git fornece um documento que dá várias dicas boas para criar commits ao enviar patches -- você pode lê-lo no código fonte do Git no arquivo `Documentation/SubmittingPatches`. (((git commands, diff, check))) Primeiro, seus envios não devem conter nenhum espaço em branco não proposital. @@ -47,7 +47,7 @@ image::images/git-diff-check.png[Output of `git diff --check`] Se você executar este comando antes do commit, você perceberá se está prestes a enviar espaços em branco problemáticos que podem irritar os outros desenvolvedores. Depois tente fazer cada commit como um conjunto lógico de mudanças. -Se possível, tente digerir suas modificações -- não programe o final de semana inteiro em cinco diferentes problemas e então publique tudo em um commit massivo na segunda-feira. +Se possível, tente tornar suas mudanças de fácil compreensão -- não programe o final de semana inteiro em cinco diferentes problemas e então publique tudo em um commit massivo na segunda-feira. Mesmo que você não publique durante o fim de semana, use a área de stage na segunda-feira para dividir seu trabalho em ao menos um commit por assunto, com uma mensagem útil em cada commit. Se algumas alterações modificarem o mesmo arquivo, tente executar `git add --patch` para colocar na área de stage os arquivos parcialmente (explicado em detalhes em <>). O retrato do projeto no final do branch é idêntico você fazendo um commit ou cinco, desde que todas as mudanças forem eventualmente adicionadas, então tente fazer as coisas mais fáceis para seus colegas desenvolvedores quando eles tiverem que revisar suas mudanças. @@ -77,7 +77,7 @@ Escreva sua mensagem de commit no imperativo: "Consertar o bug" e não "Bug cons ou "Conserta bug". Esta convenção combina com as mensagens de commit geradas por comandos como `git merge` e `git revert`. -Parágrafos seguintes veem depois de linhas em branco. +Parágrafos subsequentes vêm após linhas em branco. - Marcadores são ok, também @@ -103,11 +103,11 @@ Resumindo, faça o que digo, não faça o que faço. (((contributing, private small team))) A configuração mais simples que você deve encontrar é um projeto privado com um ou dois outros desenvolvedores. -``Privado,`` neste contexto, significa código fechado -- não acessível ao mundo exterior. +"Privado", neste contexto, significa código fechado -- não acessível ao mundo exterior. Você e os outros desenvolvedores têm permissão para publicar no repositório. Neste ambiente, você pode seguir um fluxo de trabalho similar ao que faria usando Subversion ou outro sistema centralizado. -Você ainda tem vantagens como fazer commites offline e fazer branches e mesclagens infinitamente mais simples, mas o fluxo de trabalho pode ser bastante semelhante; a principal diferença é que mesclar acontece no lado do cliente ao invés do servidor na hora do commit. +Você ainda tem vantagens como fazer commits offline e fazer branches e mesclagens infinitamente mais simples, mas o fluxo de trabalho pode ser bastante semelhante; a principal diferença é que mesclar acontece no lado do cliente ao invés do servidor na hora do commit. Veremos o que pode acontecer quando dois desenvolvedores começam a trabalhar juntos em um repositório compartilhado. O primeiro desenvolvedor, John, clona o repositório, faz uma alteração e um commit localmente. O protocolo de mensagens foi substituído por `...` nestes exemplos por simplificação. @@ -153,7 +153,7 @@ To jessica@githost:simplegit.git A última linha do resultado acima mostra uma mensagem de retorno útil da operação push. O formato básico é `.. daref -> pararef`, onde `velharef` significa velha referência, `novaref` significa a nova referência, `daref` é o nome da referência local que está sendo publicada, e `pararef` é o nome da referência remota sendo atualizada. -Você verá resultados semelhantes como este nas discussões seguintes, então ter uma ideia básica do significado irá ajudá-lo entender os vários estados dos repositórios. +Você verá resultados semelhantes a este nas discussões seguintes, então ter uma ideia básica do significado irá ajudá-lo a entender os vários estados dos repositórios. Mais detalhes estão disponíveis na documentação aqui https://git-scm.com/docs/git-push[git-push]. Continuando com este exemplo, pouco depois, John faz algumas modificações, um commit no seu repositório local, e tenta dar um push no mesmo servidor: @@ -169,7 +169,7 @@ error: failed to push some refs to 'john@githost:simplegit.git' Neste caso, o push do John falhou por causa das alterações do push _que a Jessica fez_ antes. Isto é especialmente importante de entender se você está acostumado ao Subversion, pois notará que os dois desenvolvedores não editaram o mesmo arquivo. -Embora Subversion automaticamente faz uma mesclagem no servidor se arquivos diferentes foram editados, com Git, você deve _primeiro_ mesclar os commites localmente. +Embora Subversion automaticamente faz uma mesclagem no servidor se arquivos diferentes foram editados, com Git, você deve _primeiro_ mesclar os commits localmente. Em outras palavras, John deve primeiro buscar (_fetch_) as modificações anteriores feitas pela Jessica e mesclá-las no seu repositório local antes que ele possa fazer o seu push. Como um passo inicial, John busca o trabalho de Jessica (apenas buscar o trabalho da Jessica, ainda não mescla no trabalho do John): @@ -217,8 +217,8 @@ No fim, o histórico de commit do John ficará assim: .Histórico do John depois de publicar no servidor `origin` image::images/small-team-3.png[John's history after pushing to the `origin` server] -Enquanto isso, Jessica criou um novo branch chamado `issue54`, e fez três commites naquele branch. -Ela ainda não buscou as alterações do John, então o histórico de commites dela se parece com isso: +Enquanto isso, Jessica criou um novo branch chamado `issue54`, e fez três commits naquele branch. +Ela ainda não buscou as alterações do John, então o histórico de commits dela se parece com isso: .Branch atual da Jessica image::images/small-team-4.png[Jessica's topic branch] @@ -234,7 +234,7 @@ From jessica@githost:simplegit fbff5bc..72bbc59 master -> origin/master ---- -Isto baixa o trabalho que John publicou enquanto isso. +Isso baixa o trabalho que John publicou enquanto isso. O histórico da Jessica agora fica assim: .Histórico da Jessica depois de buscar as mudanças do John @@ -253,7 +253,7 @@ Date: Fri May 29 16:01:27 2009 -0700 Remover valor padrão inválido ---- -A sintaxe `issue54..origin/master` é um filtro de log que pede ao Git mostrar apenas estes commites que estão no branch seguinte (neste caso `origin/master`) e não estão no primeiro branch (neste caso `issue54`). +A sintaxe `issue54..origin/master` é um filtro de log que pede ao Git mostrar apenas estes commits que estão no branch seguinte (neste caso `origin/master`) e não estão no primeiro branch (neste caso `issue54`). Iremos cobrir esta sintaxe em detalhes em <>. Do resultado acima, podemos ver que há um único commit que John fez e Jessica não mesclou no trabalho local dela. @@ -267,7 +267,7 @@ Primeiro (tendo feito commit de todo o trabalho no branch atual dela `issue54`), ---- $ git checkout master Switched to branch 'master' -Your branch is behind 'origin/master' by 2 commites, and can be fast-forwarded. +Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. ---- Jessica pode mesclar tanto `origin/master` ou `issue54` primeiro -- ambos estão adiantados, então a ordem não importa. @@ -311,7 +311,7 @@ To jessica@githost:simplegit.git 72bbc59..8059c15 master -> master ---- -Cada desenvolvedor fez alguns commites e mesclou ao trabalho do outro com sucesso. +Cada desenvolvedor fez alguns commits e mesclou ao trabalho do outro com sucesso. .Histórico de Jessica depois de publicar todas alterações no servidor image::images/small-team-7.png[Jessica's history after pushing all changes back to the server] @@ -349,7 +349,7 @@ $ git commit -am 'Adicionar limite a função log' 1 files changed, 1 insertions(+), 1 deletions(-) ---- -Neste ponto, ela precisa compartilhar seu trabalho com John, então ela publica seus commites no branch `featureA` do servidor. +Neste ponto, ela precisa compartilhar seu trabalho com John, então ela publica seus commits no branch `featureA` do servidor. Jessica não tem permissão de publicar no branch `master` -- apenas os coordenadores tem -- então ela publica em outro branch para trabalhar com John: [source,console] @@ -372,7 +372,7 @@ $ git checkout -b featureB origin/master Switched to a new branch 'featureB' ---- -Agora Jessica faz alguns commites no branch `featureB`: +Agora Jessica faz alguns commits no branch `featureB`: [source,console] ---- @@ -430,7 +430,7 @@ Veja <> para uma discussão mais detalhada sobre o Também perceba a flag `-u`; isto é abreviação de `--set-upstream`, que configura os branches para facilitar publicar e baixar depois. De repente, Jessica recebe um email de John, contando que publicou algumas modificações no branch `featureA` no qual eles estavam colaborando, e ele pede a Jessica para dar uma olhada. -Denovo, Jessica executa um simples `git fetch` para buscar _todo_ novo conteúdo do servidor, incluindo (é claro) o último trabalho de John: +De novo, Jessica executa um simples `git fetch` para buscar _todo_ novo conteúdo do servidor, incluindo (é claro) o último trabalho de John: [source,console] ---- @@ -478,9 +478,9 @@ To jessica@githost:simplegit.git 3300904..774b3ed featureA -> featureA ---- -O histórico de commites da Jessica agora está assim: +O histórico de commits da Jessica agora está assim: -.Histórico da Jessica depois dos commites em um branch de componentes +.Histórico da Jessica depois dos commits em um branch de componentes image::images/managed-team-2.png[Jessica's history after committing on a feature branch] Em algum ponto, Jessica, Josie e John informam os coordenadores que os branches `featureA` e `featureBee` no servidor estão prontos para serem integrados no código principal. @@ -490,7 +490,7 @@ Depois dos coordenadores mesclarem estes branches no código principal, um _fetc image::images/managed-team-3.png[Jessica's history after merging both her topic branches] Muitos grupos migraram para o Git pela possibilidade de ter múltiplos times trabalhando em paralelo, combinando as diferentes frentes de trabalho mais tarde no processo. -A habilidade de pequenos subgrupos da equipe colaborar através de branches remotos sem necessariamente ter que envolver ou atrasar a equipe inteira é um benefício imenso do Git. +A habilidade de pequenos subgrupos da equipe de colaborar através de branches remotos sem necessariamente ter que envolver ou atrasar a equipe inteira é um benefício imenso do Git. A sequência do fluxo de trabalho que você viu aqui é parecida com isto: .Sequencia básica deste fluxo de trabalho coordenado @@ -522,7 +522,7 @@ $ git commit [NOTE] ==== -Você pode querer usar `rebase -i` para resumir seu trabalho a um único commit, ou rearranjar o trabalho em commites que deixarão o trabalho mais fácil para os mantenedores revisarem -- veja <> para mais informações sobre rebase interativo. +Você pode querer usar `rebase -i` para resumir seu trabalho a um único commit, ou rearranjar o trabalho em commits que deixarão o trabalho mais fácil para os mantenedores revisarem -- veja <> para mais informações sobre rebase interativo. ==== Quando seu trabalho no branch é finalizado e você está pronto para mandá-lo para os mantenedores, vá para a página original do projeto e clique no botão ``Fork'', criando seu próprio fork editável do projeto. @@ -550,7 +550,7 @@ Uma vez que seu trabalho tenha sido publicado no repositório do seu fork, você Isto é comumente chamado de _pull request_, e você tipicamente gera esta requisição ou através do website -- GitHub tem seu próprio mecanismo de ``Pull Request'' que iremos abordar em #<># -- ou você pode executar o comando `git request-pull` e mandar um email com o resultado para o mantenedor do projeto manualmente. O comando `git request-pull` pega o branch base no qual você quer o seu branch atual publicado e a URL do repositório Git de onde você vai buscar, e produz um resumo de todas as mudanças que você está tentando publicar. -Por exemplo, se Jessica quer mandar a John uma pull request, e ela fez dois commites no branch que ela acabou de publicar, ela pode executar: +Por exemplo, se Jessica quer mandar a John uma pull request, e ela fez dois commits no branch que ela acabou de publicar, ela pode executar: [source,console] ---- @@ -571,10 +571,10 @@ Jessica Smith (2): 1 files changed, 9 insertions(+), 1 deletions(-) ---- -Este resultado pode ser mandado para os mantenedores -- ele diz de qual branch o trabalho vem, resume os commites, e identifica onde o novo trabalho será publicado. +Este resultado pode ser mandado para os mantenedores -- ele diz de qual branch o trabalho vem, resume os commits, e identifica onde o novo trabalho será publicado. Em um projeto em que você não é um mantenedor, é geralmente mais fácil ter um branch principal `master` sempre rastreando `origin/master` e fazer seu trabalho em branches separados que você pode facilmente descartar se eles forem rejeitados. -Tendo temas de trabalho isolados em branches próprios também facilita para você realocar seu trabalho se a ponta do repositório principal se mover enquanto trabalha e seus commites não mais puderem ser aplicados diretamente. +Tendo temas de trabalho isolados em branches próprios também facilita para você realocar seu trabalho se a ponta do repositório principal se mover enquanto trabalha e seus commits não mais puderem ser aplicados diretamente. Por exemplo, se você quer publicar um segundo trabalho numa outra área do projeto, não continue trabalhando no branch que você acabou de publicar -- comece um novo branch apartir do branch no repositório principal `master`: [source,console] @@ -590,7 +590,7 @@ $ git fetch origin Agora, cada um dos seus assuntos está contido em um casulo -- igual a um patch na fila -- que você pode reescrever, realocar, e modificar sem que os outros assuntos interfiram com ele, deste jeito: -.Histórico de commites inicial com o trabalho `featureB` +.Histórico de commits inicial com o trabalho `featureB` image::images/public-small-1.png[Initial commit history with `featureB` work] Digamos que o mantenedor do projeto tenha integrado vários outros patches e, quando tentou seu primeiro branch, seu trabalho não mais combina facilmente. @@ -606,13 +606,13 @@ $ git push -f meufork featureA Isto reescreve seu histórico que agora fica assim <>. [[psp_b]] -.Histórico de commites depois do trabalho em `featureA` +.Histórico de commits depois do trabalho em `featureA` image::images/public-small-2.png[Commit history after `featureA` work] Como você realocou seu branch, você deve especificar `-f` para seu comando push substituir o branch `featureA` no servidor com um commit que não é um descendente dele. Uma alternativa seria publicar seu novo trabalho em um branch diferente no servidor (talvez chamado `featureAv2`). -Vamos olhar um outro cenário possível: o mantenedor viu seu trabalho no seu branch secundário e gosta do conceito mas gostaria que você mudasse um detalhe de implementação. +Vamos olhar um outro cenário possível: o mantenedor viu seu trabalho no seu branch secundário e gosta do conceito, mas gostaria que você mudasse um detalhe de implementação. Você aproveita esta oportunidade para basear seu trabalho no branch `master` do projeto atual. Você inicia um novo branch baseado no branch `origin/master` atual, compacta (_squash_) as mudanças do `featureB` ali, resolve qualquer conflito, faz a mudança de implementação, e então publica isto como um novo branch: @@ -626,7 +626,7 @@ $ git commit $ git push meufork featureBv2 ---- -A opção `--squash` pega todo o trabalho no branch mesclado e comprime em um novo conjunto gerando um novo estado de repositório como se uma mescla real tivesse acontecido, sem realmente mesclar os commites. +A opção `--squash` pega todo o trabalho no branch mesclado e comprime em um novo conjunto gerando um novo estado de repositório como se uma mescla real tivesse acontecido, sem realmente mesclar os commits. Isto significa que seu commit futuro terá um pai apenas e te permite introduzir todas as mudanças de um outro branch e então aplicar mais alterações antes de gravar seu novo commit. A opção `--no-commit` também pode ser útil para atrasar a integração do commit no caso do processo de mesclagem padrão. @@ -644,7 +644,7 @@ Já que existem vários projetos mais antigos, maiores, que aceitam patches atra O fluxo de trabalho é parecido ao caso anterior -- você cria branches separados para cada série de patches em que trabalhar. A diferença é como enviá-los ao projeto. -Ao invés de fazer um fork do projeto e publicar sua própria versão editável, você gera versões de email de cada série de commites e as envia para a lista de email dos desenvolvedores: +Ao invés de fazer um fork do projeto e publicar sua própria versão editável, você gera versões de email de cada série de commits e as envia para a lista de email dos desenvolvedores: [source,console] ---- @@ -656,7 +656,7 @@ $ git commit ---- (((git commands, format-patch))) -Agora você tem dois commites que gostaria de enviar para a lista de email. +Agora você tem dois commits que gostaria de enviar para a lista de email. Você pode usar `git format-patch` para gerar os arquivos formatados em mbox e enviar para a lista de email -- isto transforma cada commit em uma mensagem de email, com a primeira linha da mensagem do commit como o assunto, e o resto da mensagem mais o patch que o commit traz como o corpo do email. O legal disto é que aplicar um patch de email gerado com `format-patch` preserva todas as informações de commit corretamente. @@ -706,7 +706,7 @@ Você também pode editar estes arquivos de patch para adicionar mais informaç Se você adicionar texto entre a linha `---` e o começo do patch (a linha `diff --git), os desenvolvedores podem ler, mas o conteúdo é ignorado pelo processo de patch. Para enviar este email para uma lista de emails, você pode tanto colar o arquivo no seu programa de email quanto enviar via um programa de linha de comando. -Colar o texto geralmente causa problemas de formatação, especialmente com programas ``inteligentes`` que não preservam novas linhas e espaços em branco corretamente. +Colar o texto geralmente causa problemas de formatação, especialmente com programas "inteligentes" que não preservam novas linhas e espaços em branco corretamente. Felizmente, o Git fornece uma ferramenta para ajudar você enviar patches formatados adequadamente através de IMAP, o que pode ser mais fácil para você. Iremos demonstrar como enviar um patch via Gmail, no caso o veículo que conhecemos melhor; você pode ler instruções detalhadas de vários programas de email no final do acima mencionado arquivo `Documentation/SubmittingPatches` no código fonte do Git. diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index 634d5d07..c78f576d 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -58,7 +58,7 @@ image::images/integration-manager.png[Integration-manager workflow] (((forking))) Este é um fluxo de trabalho bastante comum em ferramentas baseadas em um hub como GitHub ou GitLab, onde é fácil bifurcar (_fork_) um projeto e publicar suas modificações no seu próprio fork para todos verem. Uma das principais vantagens desta abordagem é que você pode continuar a trabalhar, e os coordenadores do repositório principal podem incluir as suas modificações a qualquer hora. -Colaboradores não tem que esperar pelo projeto para incorporar suas mudanças -– cada grupo pode trabalhar na sua própria velocidade. +Colaboradores não tem que esperar pelo projeto para incorporar suas mudanças -- cada grupo pode trabalhar na sua própria velocidade. ==== Fluxo de Trabalho Ditador e Tenentes @@ -67,7 +67,7 @@ Esta é uma variante de um fluxo de trabalho com múltiplos repositórios. É geralmente usada por projetos gigantescos com centenas de colaboradores; um exemplo famoso é o kernel Linux. Vários coordenadores são responsáveis por partes específicas do repositório, eles são chamados _tenentes_. Todos os tenentes têm um coordenador conhecido como o ditador benevolente. -O ditador benevolente publica (_push_) do diretório deles para um repositório de referência do qual todos os colaboradores precisam buscar (_pull_). +O ditador benevolente publica (_push_) do diretório dele para um repositório de referência do qual todos os colaboradores precisam buscar (_pull_). Este processo funciona assim (ver <>): 1. Desenvolvedores comuns trabalham no seu próprio branch, baseando seu trabalho no `master`. diff --git a/ch05-distributed-git.asc b/ch05-distributed-git.asc index 8142a324..3f27d69b 100644 --- a/ch05-distributed-git.asc +++ b/ch05-distributed-git.asc @@ -3,10 +3,10 @@ == Distributed Git (((distributed git))) -Now that you have a remote Git repository set up as a point for all the developers to share their code, and you're familiar with basic Git commands in a local workflow, you'll look at how to utilize some of the distributed workflows that Git affords you. +Agora que você configurou um repositório remoto Git como um local para todos os desenvolvedores compartilharem seu código e já está familiarizado com os comandos básicos do Git em um fluxo de trabalho local, você verá como utilizar alguns dos fluxos de trabalho distribuídos que o Git oferece. -In this chapter, you'll see how to work with Git in a distributed environment as a contributor and an integrator. -That is, you'll learn how to contribute code successfully to a project and make it as easy on you and the project maintainer as possible, and also how to maintain a project successfully with a number of developers contributing. +Neste capítulo, você aprenderá a trabalhar com o Git em um ambiente distribuído, tanto como colaborador quanto como integrador. +Ou seja, você aprenderá a contribuir corretamente com um projeto e a facilitar tanto para você quanto para o mantenedor do projeto, além de como manter um projeto de maneira eficiente quando há vários desenvolvedores contribuindo. include::book/05-distributed-git/sections/distributed-workflows.asc[] @@ -16,6 +16,4 @@ include::book/05-distributed-git/sections/maintaining.asc[] === Summary -You should feel fairly comfortable contributing to a project in Git as well as maintaining your own project or integrating other users' contributions. -Congratulations on being an effective Git developer! -In the next chapter, you'll learn about how to use the largest and most popular Git hosting service, GitHub. +Você deve se sentir suficientemente confortável contribuindo com um projeto Git, assim como em manter seu próprio projeto ou integrar as contribuições de outros usuários. Parabéns por se tornar um desenvolvedor eficaz no Git! No próximo capítulo, você aprenderá a usar o maior e mais popular serviço de hospedagem Git, o GitHub.