DEV Community: Pedro Vitorino

GIT - O mínimo que você precisa saber para trabalhar em equipe (Parte 2)

Pedro Vitorino — Sun, 20 Sep 2020 19:49:28 +0000

Esta é uma série de dois artigos que explica o básico sobre Git. No primeiro artigo é apresentado alguns termos e conceitos básicos. No segundo será feito uma apresentação dos principais comandos de Git utilizados no dia a dia de um programador.

Clique aqui para ler a parte 1, explicando os principais conceitos de git.

Git na prática: comandos

Nesta seção vamos para a parte prática de Git. Aqui irei listar alguns dos comandos mais utilizados no dia a dia de um programador.

Git init

Para começar a trabalhar com git você precisa inicializar um diretório git na sua máquina local, para isso é necessário executar o comando

$ git init

. Este comando irá criar a estrutura git dentro do diretório em que foi executado.

Git clone

Na maioria das vezes você irá começar a trabalhar com os arquivos de um repositório já existente. Para copiar os arquivos do servidor remoto para sua máquina local execute o comando

$ git clone https://usuario:senha@enderecoRemoto.com/repositorio.git

Git checkout: navegando entre branches

Git checkout é o comando utilizado para mudar a branch em que você está trabalhando. Uma rotina comum no dia-a-dia de um programador é criar uma nova branch para trabalhar em um determinada funcionalidade, utilizar o comando fetch para busca-lá da origem e então usar o comando

$ git checkout nome-da-branch

para começar a trabalhar na sua nova branch.

Git fetch

Este é um comando muito utilizado mas que por vezes as pessoas não entendem sua função. O comando git fetch traz do repositório remoto todas informações que ainda não estão no seu repositório local. Um detalhe muito importante, o comando git fetch NÃO incorpora essas mudanças ao seu repositório local, ele apenas identifica elas.
Quando você cria branches diretamente no servidor remoto é necessário que você execute o comando git fetch para ter acesso à esses branches localmente.
Normalmente é necessário apenas executá-lo como

$ git fetch

Git pull: buscando alterações remotas

Após o git fetch, caso haja alterações no repositório remoto, você precisa aplica-las ao seu repositório local. O comando utilizado para essa operação é o

$ git pull

.
Quando você realiza um pull, as alterações de código que estão na branch no repositório remoto serão baixadas. Caso o git não consiga fazer a junção automática dessas alteraçãos com o seu códiogo, as seções do código onde existem conflitos serão destacadas e você precisará juntar os código manualmente, indicando se vai utilizar as alterações que vieram da origem, as suas alterações locais ou as duas.
Muitos desenvolvedores acham o processo de merge traumático, então muita calma na hora de realizar um pull. Se houver conflitos, não se desespere, faça o merge e lembre-se, os pulls são reversíveis. Caso algo aconteça algum problema seu código não está perdido, é sempre possível voltar no commit anterior ao pull.

Git add

Para fazer um commit e salvar aquele snapshot do seu trabalho é necessário antes adicionar suas alterações na staging area. Este é um local de trabalho onde você pode colocar os arquivos que realmente deseja adicionar ao seu commit, assim você pode particionar melhor seu trabalho e organizar melhor seus commits. Para adicionar todos os arquivos alterados e novos arquivos na staging area use o comando

$ git add .

, caso queira adicionar arquivos específicos utilize o comando

$ git add nome-do-arquivo.txt nome-do-arquivo2.txt

.
Um detalhe muito importante, caso você deseja adicionar na staging area as alterações e novos arquivos, e as deleções que realizou você deve utilizar o comando

$ git add -A

.

Git commit: salvando um snapshot

Falamos dos commits mais cedo no nosso artigo. Na prática para se realizar um commit é necessário que você tenha arquivos na sua staging area. Uma vez que os arquivos estão lá basta você utilizar o comando

$ git commit

para registrar uma “foto” do seu código. Uma vez que você executa este comando é gerado um commit com um código identificador único, você pode utilizar o comando git checkout com o código gerado para voltar naquele snapshot do seu programa.

Git push: fazendo o upload

Uma vez que você fez alterações no seu código e criou seus commits você precisa que os outros desenvolvedores tenham acesso a essas alterações. Lembre que até o momento tudo o que você desenvolveu está na cópia do repositório na sua máquina local.
Para que você envie suas alterações para a origem você precisa antes o git pull que mencionamos anteriormente.

Você realizou seu pull, agora sua branch está alinhada com a branch na origem e você finalmente pode fazer upload das suas alterações. Para fazer esse upload use o comando

$ git push origin nome-da-branch

.

Git merge: finalizando seu trabalho

Uma vez que você finalizou seu trabalho você precisa fazer a junção de sua branch com a branch de origem para que suas alterações sejam incluídas no projeto. Um dos possíveis comandos para realizar essa junção é o git merge. Para utiliza-lo digite

$ git merge origin/branch-de-origem

. Este como irá buscar as alterações da branch principal do seu projeto e aplica-las a sua branch. Após resolver os conflitos, faça o commit e depois push para a origem.
Finalizado esse processo, você agora pode abrir uma Pull Request para juntar todo seu trabalho à branch principal.

Git stash

Um grande diferencial do git como tecnologia de versionamento é a existência da área de stash. Essa é uma ferramenta muito poderosa mas que poucos desenvolvedores fazem uso.
Por vezes é possível que você comece a desenvolver uma nova atividade em uma branch e depois de algumas dezenas de linhas de código você percebe que está trabalhando na branch errada.
Para contornar esse tipo de situação você pode fazer uso da stash, que é uma área lógica do git na qual é possível salvar alterações que você ainda não deseja commitar.
Utilize o comando

$ git stash

para adicionar as alterações que você fez na área de stash. A partir de então você pode aplicar aquelas alterações em qualquer branch que você quiser fazendo um checkout para a branch na qual você deseja trabalhar e utilizando o comando

$ git stash pop

.

Conclusões

Enfim, estes são os conceitos e comandos básicos para que você comece a trabalhar em uma equipe de desenvolvedores. Utilize essa tecnologia e treine bastante os comandos que aprendeu aqui. Acima de tudo, não se esqueça de fazer commits frequentes para ter seu trabalho salvo sempre.

Referências

GIT - O mínimo que você precisa saber para trabalhar em equipe (Parte 1)

Pedro Vitorino — Sun, 20 Sep 2020 19:44:34 +0000

Clique aqui para ler a parte 2, explicando os principais comandos do git.

Introdução

Está cada vez mais difícil de se falar em projetos de TI sem se falar em versionamento, e sem dúvidas está cada vez mais difícil ingressar no mercado sem conhecer tecnologias de versionamento. Dentre as várias tecnologias que um desenvolvedor precisa conhecer, o Git se tornou a tecnologia de versionamento essencial para os programadores de hoje em dia.
Se você está ingressando no mercado de TI agora, ou já trabalha há algum tempo e ainda não compreendeu como usar essa ferramenta, este artigo é para você.
Aqui vamos trabalhar os conceitos essenciais para que você consiga entender e utilizar o git minimamente bem para trabalhar num projeto de desenvolvimento.

O que é git?

Git é um sistema de controle de versão. Com ele é possível que vários desenvolvedores contribuam no desenvolvimento de um mesmo sistema sem o risco de perder arquivos ou linhas de código. Com Git é possível manter um histórico de alterações do projeto e descentralizar o processo de desenvolvimento.

Por quê git?

Git não é o único sistema de controle de versão existente, então porque ele é tão falado e no universo de desenvolvimento de sistemas? Git possui uma arquitetura distribuída, isso significa que todo desenvolvedor tem uma cópia local do projeto em que está trabalhando, e que ele não precisa de acesso a internet para criar seu histórico de alterações. Além disso, sua estrutura garante que se minimize os conflitos de código quando mais de um desenvolvedor trabalha em um mesmo código.
Existem várias outros motivos para o sucesso do Git, mas como esse artigo é sobre o mínimo, vamos encerrar essa sessão por aqui.

Os termos

Repositório

Um repositório é onde está armazenado o seu projeto, com as suas branches (calma, logo chegamos lá) e arquivos. O repositório fica armazenado em um servidor Git, geralmente este servidor fica na nuvem, em serviços como Bitbucket e Github. Quando um desenvolvedor que vá trabalhar no seu projeto, ele faz uma cópia local do repositório em sua máquina.

A árvore

Quando criamos um repositório git, criamos também uma árvore (tree). O código do projeto inicial é um branch (galho/ramo), e a partir dele é possível criar novos branches, cada branch criado é uma cópia exata do seu branch pai no momento da criação. A criação de novos branches normalmente ocorre quando uma nova alteração no código precisa ser realizada. De modo que as alterações que o desenvolvedor realizar em uma branch serão salvas apenas neste branch.

Commits

Commit é outra palavra bastante utilizada no universo Git. Quando estamos trabalhando em um branch é possível realizar commits (confirmações alterações). Quando estes commits são realizados, é como se tirássemos uma foto daquele branch naquele exato momento, a partir de então é possível voltar naquela foto e fazer alterações a partir dela sempre que necessário.

A Origem

Como mencionado anteriormente, o Git é um sistema distribuído, ou seja o desenvolvedor possuirá uma cópia local do repositório em sua máquina. Quando ele fazer alterações e commits no seu repositório essas alterações serão salvas localmente. Para que outros desenvolvedores tenham acesso às essas alterações é necessário enviá-las para a origem, que nada mais é que a cópia original armazenada no seu repositório Git.

Merges ou junções

Quando um desenvolvedor quer reproduzir as alterações de sua branch para outras branches é necessário que ele faça a junção das branches, processo também conhecido como merge.

Workflow

Algo que confunde muitos iniciantes em Git é o conceito de workflow, ou fluxo de trabalho. Não existe regra universal para quando um novo branch deve ser criado, quando o desenvolvedor deve realizar commits ou até mesmo realizar um merge, tudo isso é definido em conjunto pela equipe de desenvolvimento, esse conjunto de regras é chamado de workflow. Então é muito importante procurar entender o workflow da equipe em que você trabalha, só assim o desenvolvedor saberá em qual branch ele deve trabalhar, em qual branch ele vai fazer merge de suas alterações e quando ele deve fazer commits e merges.