11 minutos de leitura
Autor(a)
Alex é instrutor e desenvolvedor e possui experiência em Java, Kotlin, Android. Atualmente cria conteúdo no canal https://www.youtube.com/@AlexFelipeDev.
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Veja como usar o git e aplicar versionamento em seus projetos.
Estou em um projeto para um mercadinho e agora estou desenvolvendo uma página web em HTML com o intuito de listar todos os produtos do mercado. A princípio cheguei no seguinte resultado:
Mostrando para o cliente essa primeira versão, ele falou o seguinte:
"Está bem legal, porém, ficaria melhor se, no momento que clicar em algum produto, aparecer uma descrição e quantidade do mesmo."
Partindo da necessidade do cliente, fiz alguns ajustes na página que lista todos os produtos, veja como ficou:
Apresentando essa segunda versão da lista de produtos para o cliente, ele falou o seguinte:
"Está atendendo muito bem o que eu preciso! Porém, ainda fica difícil saber qual é o produto apenas lendo… Em outras palavras, quero que também adicione uma imagem do produto dentro dessa caixa da descrição e quantidade
Considerando essa nova necessidade do cliente, fiz os ajustes e cheguei a esse resultado:
Mostrei novamente para o cliente, e ele respondeu o seguinte:
"Ficou muito legal a lista de produtos com a descrição, imagem e quantidade. Mas eu comecei a perceber que tende a ficar poluído, ou seja, é melhor deixar a lista como estava desde a primeira vez que você me mostrou, então você cria uma nova página que contenha as informações do produto: imagem, descrição e quantidade…"
Observe que desde o começo do projeto, estamos sujeitos a mudanças constantes. Portanto, mesmo que entreguemos a feature para o nosso cliente da maneira como ele pede, ainda sim existe o risco dele querer mais alguma coisa.
Além disso, perceba que também corremos o risco do nosso cliente simplesmente chegar e falar que queria o projeto do jeito como era antes, algo que fizemos há muito tempo atrás e que, dependendo da quantidade de mudanças, fica bem difícil de reverter…
Pensando em todos esses detalhes, o que podemos fazer para evitar esse tipo de situação?
Basicamente, precisamos, de alguma forma, salvar os estados do nosso projeto, ou seja, fazer com que cada alteração que entregarmos seja uma versão, por exemplo, dividindo em pastas diferentes. Então teríamos:
01-lista-simples: primeira entrega com uma lista simples.
02-lista-com-descricao-e-quantidade: segunda entrega com uma lista contendo a descrição e quantidade de cada produto
03-lista-com-imagem-descricao-e-quantidade: terceira entrega com uma lista contendo a imagem, descrição e quantidade de cada produto
De fato esse tipo de abordagem funciona, porém, note que para cada uma das versões que forem surgindo teremos que realizar esse processo manual diversas vezes. Se observarmos bem, essa abordagem tende a ser muito trabalhosa e cheia de riscos, tais, como:
Controle: para cada mera mudança no projeto teremos que lembrar de criar uma pasta do projeto atual.
Histórico: fica muito difícil de ter uma visão ampla e objetiva do que foi feito e quando foi feito, como também o que mudou de uma versão para outra.
Reversão: se precisarmos voltar apenas uma parte do que já foi feito há muito tempo, mantendo as outras coisas novas que foram implementadas, provavelmente teremos um trabalho tremendo.
Será que existe alguma maneira mais fácil e objetiva de lidarmos com esse tipo de situação?
Para lidarmos com tais situações de uma maneira mais eficiente, podemos usar sistemas de controle da versão, também conhecidos como VCS do inglês Version Control System, ou na tradução, Sistema de Controle de Versão.
Um VCS muito utilizado é o Git. Uma ferramenta muito comum na comunidade para versionar projetos que mantenham arquivos fontes como o nosso:
"Legal, mas como eu posso utilizar o Git?"
O primeiro passo de todos é instalá-lo no seu computador, você pode fazer nesta página de downloads.
É possível realizar a instalação via gerenciador de pacotes, como o Apt, Brew, Scoop e etc…
Após a instalação já somos capazes de versionar o nosso projeto! Para isso, via terminal ou prompt, vamos até o diretório no qual está o projeto, no meu caso está em /home/alex/meus-projetos/mercadinho.
Em seguida, falamos para o Git iniciar (init) o gerenciamento do projeto:
git init
Observe que é apresentada uma mensagem indicando que foi inicializado um repositório vazio do Git.
Em outras palavras, nesse momento criamos um repositório local do Git dentro do nosso projeto, portanto, ele começou a gerenciá-lo.
"Legal, mas o que vamos fazer agora?"
Primeiro voltaremos o nosso projeto para a primeira versão que foi entregue para o cliente, então, vamos começar a criar as versões que foram surgindo conforme a necessidade dele. Aí usaremos o Git para que ele gerencie isso pra gente!
Voltamos para o que tínhamos desde o começo, sendo assim, precisamos primeiro pedir para o Git marcar todos os arquivos que queremos salvar nessa primeira versão.
Seguindo os arquivos que temos no projeto:
Portanto, podemos pedir para o Git adicionar (add) o nosso arquivo produtos.html para ser salvo:
git add produtos.html
Pronto! Com isso nosso arquivo foi marcado pelo Git, porém, ainda precisamos marcar os arquivos que estão no diretório css e js. Mas para isso eu preciso adicionar todos os arquivos contidos neles um por um?
Não necessariamente, você pode adicionar um arquivo por vez passando o caminho até ele, mas se você quiser adicionar todos os arquivos de um diretório, basta dizer isso para o Git:
git add css/
Dessa forma, todos os arquivos dentro da pasta css/ foram adicionados ao Git. Mas se no meu projeto eu tiver muitos arquivos e diretórios, preciso adicionar um de cada vez?
Considerando que precisamos fazer isso para todos, podemos dizer para o Git adicionar (add) todos os arquivos modificados (.):
git add .
Agora que adicionamos todos os arquivos que queremos salvar, precisamos pedir para o Git salvar o estado atual do nosso projeto, ou seja, a nossa primeira versão!
Em outras palavras, indicaremos para o Git que tudo que pedimos para ele salvar representa a nossa primeira versão! Para isso, usamos o comando git commit.
Entretanto, esse comando exige que enviemos uma mensagem (-m) indicando o que esse estado significa.
git commit -m "primeira entrega com uma lista simples"
Se não usamos esse parâmetro junto de uma mensagem em específico, o Git pede para o sistema abrir um um editor de texto padrão para que a mensagem seja associada da mesma maneira.
Note que o Git mostrou todos os arquivos que foram adicionados nesta versão que salvamos!
Agora que temos a nossa primeira versão, vamos ajustar o projeto e colocar as outras versões que o cliente pediu e fazer o mesmo procedimento, isto é, marcar os arquivos para salvar com o add, e então, salvar a versão com o commit.
Na segunda versão eu tinha modificado o HTML para conter as listas com descrição, portanto temos o seguinte resultado ao commitar (não estranhe, é comum da galera falar desse jeito):
Veja que agora ele apenas notificou que houve mudança em 2 arquivos, também, dessa vez ele não mostrou que o arquivo foi adicionado, apenas gravou o que mudou dele! Isto é,63 linhas inseridas e 14 removidas.
Mais ainda, observe que mesmo tendo 9 arquivos dentro do projeto como vimos inicialmente,o Git já é inteligente o suficiente em saber que no momento que fizemos git add . ele precisava adicionar apenas os arquivos que foram modificados :)
Por fim, vou adicionar a imagem no produto e realizar o mesmo procedimento:
Veja que agora, além de editarmos os arquivos que já tinham sido adicionados uma vez, também adicionamos a imagem que não existia até o momento e o Git nos indicou que ela foi inserida nessa versão especificamente. Nesse momento você deve estar se perguntando:
Legal, mas como vejo se os meus estados, ou melhor, meus commits, foram realmente registrados?
Para visualizarmos todos os commits que realizamos até o momento no repositório Git, basta apenas utilizar o comando git log:
Note que o Git apresenta tanto o autor como a data de criação da versão, dessa forma, temos a capacidade de visualizar o histórico das modificações que foram feitas no projeto, como por exemplo, quem fez e quando foi feito.
Além disso, observe que cada commit tem um hash para identificá-lo, em outras palavras, é por meio desses hashs que temos a capacidade de saber o que um determinado commit fez ou até mesmo navegar entre os commits!
Por exemplo, para voltar agora na primeira versão usamos o comando git checkout 631123e4d6276b49059a7ae96b1de86c928f71c2, veja só:
Usamos esse hash pois ele refere-se justamente ao primeiro commit que salvamos, isto é, a nossa primeira versão.
Se conferirmos o nosso diretório:
Veja só, já não temos mais a imagem que havia sido adicionada com o diretório img. Nesse momento você deve estar pensando:
"Mas como eu faço para voltar para o commit que tinha a imagem com as descrições?"
Simples! Basta apenas executar o comando git checkout master:
Repara que agora a imagem voltou! Em outras palavras, voltamos para o último estado que foi salvo, isto é, o último commit.
É válido notar que fizemos uso desse tal de master, que a princípio não tem muito significado pra gente. Porém, é um assunto que vai um pouco além desse nosso primeiro contato com o Git, talvez em um próximo post :)
Além de um VCS, o Git também é conhecido como um SCM do inglês Source Code Management ou gerenciamento de código fonte. Além dele, também existem algumas alternativas com o mesmo objetivo:
Basicamente, essas ferramentas são capazes de aplicar todos os conceitos que vimos durante o texto, porém, uma acaba tendo alguma vantagem em relação a outra, como também, a adoção da comunidade de desenvolvedores.
Legal, mas qual dessas ferramentas vale a pena eu aprender?
Uma das maneiras que podemos verificar, é justamente o quão usada é uma ferramenta em relação a outra. Para isso, temos a possibilidade de visualizar a popularidade de cada uma delas nessa pesquisa feita pela RhodeCode em 2016.
Além dos tópicos que vimos anteriormente, um uso bem comum em ferramentas como o Git é justamente manter a disponibilidade do nosso projeto de forma remota para qualquer desenvolvedor que for participar do projeto.
Em outras palavras, deixar o nosso projeto em um repositório online como é o caso do GitHub, GitLab ou BitBucket. Então, se precisar baixar o projeto ou pegar as últimas atualizações que foram feitas, basta apenas consultar esses repositórios remotos!
A mudança é uma característica comum durante o desenvolvimento de um projeto e, para lidarmos melhor com esse tipo de situação temos os VCS como é o caso do Git.
Esse é uma pequena parte do mundo de versionamento, ainda existem técnicas e conhecimentos essenciais para usarmos essas ferramentas de maneira eficiente.
Se quiser aprender mais sobre versionamento, aqui na Alura temos um curso de Git e na Casa do Código também temos um livro sobre Git e Github.
Lá você verá tanto essa parte de versionamento do projeto como também técnicas mais avançadas que podemos aplicar durante o desenvolvimento em time que é algo muito comum no dia a dia.
Se você quer dominar Git e GitHub e tem pouco tempo confira o Flash Skill da Alura Dominando Git e Github em 2h. Nesse curso rápido você aprenderá de forma prática, a configurar repositórios, comandar o fluxo de versionamento com Git, criar branches, fazer merges e publicar no GitHub com segurança.
Ao final, terá um projeto real disponível online, pronto para incluir no seu portifólio e demonstrar suas habilidades. Além disso, você garante um certificado oficial Alura para impulsionar sua visibilidade no mercado!
Acesse agora a página do flash skills e matricule-se!
Avalie este artigo
