Git

Comandos do Git que você precisa conhecer – Parte 2 – Repositórios Remotos

Olá Web Developers! Hoje trago aqui os comandos que você precisa conhecer ao se trabalhar com Git. A primeira parte deste post abordou os comandos do Git para repositórios locais. Agora veremos os comandos para repositórios remotos e também como criar um repositório na nossa rede local.

1 – Clonando um Repositório Remoto

Para fazer download de um projeto basta executar o comando $ git clone, passando o endereço do repositório. Pode ser Github, Gitlab, Bitbucket, etc.

Esse comando é bem conhecido, mas ele está aqui por um detalhe que muitas pessoas não sabem: por padrão será criada uma pasta com o nome do projeto, mas você também pode no final do comando indicar qual o nome da pasta que você quer que seja criada.

$ git clone https://meu-endereco.com/meu-projeto.git minha-pasta

2 – Repositórios Remotos

Repositórios Remotos são repositórios presentes em outra máquina para a qual nós podemos pegar ou enviar código. Todos esses comandos começam com $ git remote. Veja os principais comandos para gerenciá-los:

2.1 – Adicionar Repositórios Remotos

Para ligar o seu repositório local com um repositório remoto, utilize o comando remote add. Precisamos passar dois parâmetros para esse comando:

  1. nome: nome que daremos ao nosso repositório remoto, como se fosse um atalho para não precisarmos ficar escrevendo a URL toda hora. O padrão é usar o nome origin
  2. url: endereço do repositório remoto ao qual o nome passado anteriormente vai se referir
$ git remote add origin https://meu-endereco.com/meu-projeto.git

Caso você queira colocar outro nome ao invés de origin não tem problema. Isso pode ser muito útil caso você precise se conectar a mais de um repositório remoto. Mas se tiver apenas um, o recomendado é seguir o padrão e usar o nome origin.

Ao adicionar mais de um repositório remoto, as alterações serão enviadas para todos. Isso pode ser útil caso você queira armazenar seu código em mais de um lugar ao mesmo tempo.

2.2 – Visualizar Repositórios Remotos

Esse comando nos mostra o endereço do repositório remoto para o qual estamos enviando nossos códigos.

$ git remote -v

Teremos um retorno como:

> origin https://meu-endereco/meu-projeto.git (fetch)
> origin https://meu-endereco/meu-projeto.git (push)

2.3 – Remover Repositórios Remotos

Pode ser que você não queira mais o seu local repositório conectado a um repositório remoto. Esse comando não apaga o repositório, apenas desfaz a conexão criada com o comando $ git remote add

$ git remote rm origin

Nesse exemplo usamos o nome origin, mas lembre-se que ali pode ser o nome que você deu ao seu repositório remoto. Se você deu um nome diferente de origin, lembre-se de usar o comando anterior para listar os repositórios remotos.

2.4 – Renomear Repositórios Remotos

Pode ser que você não queira mais o nome que você deu ao seu repositório remoto com o comando $ git remote add. Há um comando bem simples para renomear.

$ git remote rename nome-atual novo-nome

2.5 – Alterar Endereço de Repositórios Remotos

Já escreveu o endereço de um repositório remoto errado ou migrou ele para outro serviço? Com o comando set-url você será capaz de apenas alterar o endereço sem precisar mexer em mais nada. Precisamos passar dois parâmetros para esse comando:

  1. nome: nome que demos ao nosso repositório remoto, como se fosse um atalho para não precisarmos ficar escrevendo a URL toda hora. O padrão é usar o nome origin
  2. url: novo endereço do repositório remoto
$ git remote set-url origin http://meu-novo-endereco/meu-projeto.git

3 – Branches Remotas

3.1 – Listando Branches

Esse comando lista todas as branches presentes no repositório do seu computador.

$ git branch

Caso você queira que ele liste também as branches que estão no repositório remoto, adicione -a:

$ git branch -a

3.2 – Criando Branches Remotas

Ao enviar o seu código para uma branch remota que ainda não existe, basta executar o push com a opção -u junto com o nome do repositório remoto e o nome da nova branch.

$ git push -u origin minha-branch

Após a branch remota estar criada, você poderá executar simplesmente $ git push.

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

3.3 – Apagando Branches Remotas

Para apagar uma branch remota nós fazemos um push e adicionamos o --delete. Entre o --delete indicamos o repositório remoto e o nome da branch a ser apagada.

$ git push origin -d minha-branch

Também podemos escrever assim:

$ git push origin :minha-branch

3.4 – Renomeando Branches Remotas

Vimos no post anterior que para renomear uma branch local executamos:

$ git branch -m nome-atual novo-nome

Após renomear a sua branch local, basta apagar a branch remota com o nome antigo e fazer um push com a branch com o novo nome:

$ git push origin :nome-atual novo-nome

Para terminar de ligar a branch local com a remota, entre na branch com o novo nome e execute:

$ git push origin -u novo-nome

4 – Achando o culpado

Deu problema e estão dizendo que foi você? Não mais! Com o comando blame você pode ver quem alterou cada linha de um arquivo. (a menos que realmente tenha sido você 😂)

git blame nome-do-arquivo

Para não ficar muito grande, podemos usar -w para ignorar espaços em branco e usar -L para indicar um intervalo de linhas a serem exibidas.

git blame -w -L 1,12 nome-do-arquivo

E ainda podemos usar -e para que seja exibido o email ao invés do nome do usuário.

5 – Compartilhamento Offline

Podemos ter repositórios remotos que não estão na nuvem, como Github, Gitlab, ou Bitbucket. Podemos fazer com que um computador em nossa rede seja o responsável por armazenar o código e receber o push de todos os usuários. Isso é útil principalmente em empresas que possuem uma política mais rígida com a segurança de suas informações e não permitem que seus códigos sejam armazenados fora de seus próprios servidores.

Outro uso para isso é quando adicionamos mais de um repositório remoto. Você pode continuar fazendo commits para o Github e ao mesmo tempo ir armazenando uma cópia em um pendrive.

Primeiro, no local onde teremos o nosso repositório “servidor” (que receberá os pushes), iniciamos um repositório junto com --bare. Neste repositório você não poderá editar arquivos ou fazer commits, ele só permite receber pushes.

$ git init --bare

Se você iniciou, por exemplo, um repositório em uma pasta dentro de um pendrive com o caminho E:\meu-projeto, basta clonar com o comando:

$ git clone E:\meu-projeto

Ou então, como já vimos, podemos adicionar esse repositório na nossa lista de repositórios remotos, permitindo que nossos commits sejam enviados para algum lugar como o Github e para o pendrive ao mesmo tempo:

$ git remote add usb E:\meu-projeto

Nesse exemplo demos o nome usb ao invés de origin. Lembre-se que você pode dar qualquer nome.

Do mesmo jeito que fizemos um repositório em um pendrive, você pode fazer o mesmo em um outro computador na sua rede. Assim todos os usuários em sua rede poderão usar este computador como repositório remoto.

Comandos do Git que você precisa conhecer – Parte 1

Olá Web Developers! Hoje trago aqui comandos muito úteis ao se trabalhar com Git que todo mundo precisa saber para facilitar o trabalho.
Nesse primeiro post veremos os comandos para repositórios locais. Na Parte 2 desse post veremos os comandos para você dominar Repositórios Remotos.

Se você ainda não trabalha com Git, veja nosso post sobre Primeiros passos com o Git.

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

1 – Iniciando um Repositório

Todo repositørio Git armazena as informações dentro de uma pasta oculta chamada “/.git”. Para que os arquivos de uma pasta possam ser versionados pelo Git, é preciso iniciar o repositório. Basta executar o comando abaixo:

$ git init

2 – Apagando um repositório

Há momentos em que não queremos apagar nossos arquivos, mas queremos remover as informações sobre aquele repositório criado com o $ git init (talvez criar um repositório novo com os mesmos arquivos).
Para isso não usamos o Git. Lembre-se que um repositório Git armazena as informações dentro de uma pasta oculta chamada /.git. Então basta apagar esta pasta oculta que o seu atual diretório deixará de ser um repositório.

$ rm -rf .git

3 -Listando Arquivos Modificados

Esse comando indica o estado do seu repositório. Em outras palavras, ele vai listar todos os arquivos que foram modificados desde o seu último commit.

$ git status

4 – Desfazendo Alterações

Poderíamos ter um post inteiro apenas falando sobre como desfazer alterações no Git, já que há vários cenários possíveis. Mas vamos resumir os principais:

4.1 – Arquivos não monitorados

Se o arquivo foi modificado mas você ainda não executou git add, um simples git checkout removerá as alterações, deixando o arquivo como ele estava no último commit. Passe o nome do arquivo a ter as alterações desfeitas ou . para desfazer as alterações em todos os arquivos modificados. Muito útil se você está apenas experimentando um código mas não quer que ele seja salvo.

git checkout .

Esse comando não apaga novos arquivos. Para apagar novos arquivos que ainda não foram adicionados ao Stage, execute:

git clean -df

4.2 – Removendo arquivos do Stage

Se você executou git add e quer desfazer, use o reset.

git reset

Para desfazer as modificações, após o reset use o checkout ou clean mostrados anteriormente.

4.3 – Desfazendo o último commit

Caso você tenha feito alterações e já tenha chegado a realizar um commit, para desfazer é necessário usar o revert.

git revert HEAD

Será criado um novo commit indicando que o último commit foi desfeito.

Esse comando apaga novos arquivos.

5 – Renomear Commit

Escreveu algo errado no último commit? Esse comando te permite renomear a mensagem do último commit feito:

$ git commit --amend

6 – Branches

Sempre é bom não trabalhar apenas na master para evitar problemas e ter um projeto mais flexível.

6.1 – Listando Branches

Esse comando lista todas as branches presentes no repositório do seu computador.

$ git branch

Caso você queira que ele liste também as branches que estão no repositório remoto, adicione -a:

$ git branch -a

6.2 – Indo para outra branch

Para mudar para uma outra branch basta usar o comando checkout, passando o nome da branch.

$ git checkout minha-branch

Se você adicionar -b, uma nova branch será criada.

$ git checkout -b minha-nova-branch

6.3 – Excluindo branches

Para excluir uma branch local basta executar o comando branch com -d ou -D, passando o nome da branch que você quer apagar.

git branch -d nome-da-branch
git branch -D nome-da-branch

A opção -d é mais segura, pois ela só apaga a branch se você já tiver feito merge ou enviado as alterações para seu repositório remoto, evitando perda de código.

A opção -D ignora o estado da sua branch, forçando a sua remoção.

Esse comando apaga apenas a branch local, não removendo branches remotas.

6.4 – Renomeando branches

Para renomear a sua atual branch local, execute o comando branch com a opção -m, passando o novo nome.

git branch -m novo-nome-da-branch

Se você estiver em uma branch e quiser renomear outra, você deve passar primeiro o nome atual da branch que quer renomear:

git branch -m nome-atual novo-nome

6.5 – Branch Órfã

Uma branch órfã tem esse nome porque ela não está ligada à branch principal, então seus históricos não são compartilhados.

          i---j---k     <== branch 'minha branch'
         /
a---b---c---d---h---l   <== branch 'master'
     \         /
      e---f---g         <== branch 'minha outra branch'

1---2---3---4           <== branch `órfã`

Isso pode ser útil quando você quer colocar mais de um projeto em um mesmo repositório. Um bom exemplo é quando você tem um projeto no Github e quer criar um site para divulgar o seu projeto. A aplicação e o site são coisas diferentes, portanto os códigos deles devem ser versionados separadamente. Ter ambos em um mesmo repositório simplifica o gerenciamento.

Nós já ensinamos aqui no blog da TreinaWeb como criar páginas para repositórios no Github.

Para criar uma branch órfã basta usar o comando:

git checkout --orphan minha-branch-orfa

7 – Visualizando o Histórico de Commits

Para visualizar o histórico de commits basta usar o seguinte comando:

$ git log

Você ainda pode adicionar mais parâmetros a esse comando, como:

7.1 – Histórico de um ou mais arquivos

$ git log -p meus-arquivos

Você pode indicar nomes de arquivo ou de um diretório para ver o histórico apenas de um grupo de arquivos ao invés do projeto inteiro

7.2 – Histórico de um autor

Mostra o histórico de commits feitos por uma única pessoa

$ git log --autor=nome-autor

7.3 – Histórico por Data

Mostra o histórico de commits feitos antes ou após uma data:

$ git log --after="MMM DD YYYY"
$ git log --before="MMM DD YYYY"

Exemplo do formato usado nas datas: “Jul 07 2019”

7.4 – Histórico Baseado em uma Mensagem

Mostra o histórico de commits filtrado por uma mensagem

$ git log --grep produtos

Com esse comando teremos o histórico de commits em que a mensagem do commit possua a palavra “produtos”. O que passamos pode ser uma expressão regular, e podemos passar mais de uma:

// procurar por "produtos" OU "usuarios"
$ git log --grep produtos --grep usuarios

// procurar por "produtos" E "usuarios"
$ git log --grep produtos --and --grep usuarios

8 – Exibir branches em um modo mais legível

É possível mandar imprimir o histórico exibindo as branches do repositório com algo mais legível e com cores com um comando. Teremos um resultado parecido com esse:

* a102055 (HEAD -> master) commit 8
| * 196d28e (branch-2) commit 7
| * 07e073c commit 3
| * 2b077ca new fie
| | * c1369d8 (branch-3) commit 6
| | * d11bdcd commit 5
| |/
|/|
* | 2b22b75 commit 2
|/
* d5a12b0 .gitignore
* 9535426 -- commit 1

O comando é um pouco comprido:

git log --all --decorate --oneline --graph

Para decorar tudo o que devemos escrever depois de log, lembre-se de A DOG
– —all
– —decorate
– —oneline
– —graph

9 – Atalhos Personalizados

Podemos criar atalhos para não ficar escrevendo comandos grandes como o do exempo anterior.

9.1 – Criando atalhos personalizados

Para criar atalhos personalizados, basta adicionar uma configuração, passando o nome que você quiser para o alias.

Por exemplo, se eu quiser que o comando ensinado anteriormente fosse chamado a partir do atalho dog:

//deixar o comando disponível apenas no repositório atual
git config alias.dog "log --all --decorate --oneline --graph"
//deixar o comando global em sua máquina, ficando disponível para qualquer repositório
git config --global alias.dog "log --all --decorate --oneline --graph"

Como os comandos serão do Git, não precisamos ficar chamando-o. Note que o comando passado para o atalho não inicia com git.

Para remover os atalhos basta executar:

//atalhos locais
git config --unset alias.dog
//atalhos globais
git config --global --unset alias.dog

Agora podemos ter o comando do exemplo anterior apenas executando $ git dog.

9.2 – Listando atalhos personalizados

Para exibir uma lista de atalhos personalizados, podemos executar o comando git config -l, que lista todas as configurações do seu Git. O problema é que esse simples comando vai listar todas as configurações. Podemos fazer um comando mais sofisticado para ele listar apenas os nossos atalhos personalizados e ainda organizá-los em ordem alfabética:

git config -l | grep ^alias\. | cut -c 7- | sort

O comando é grande, mas tudo bem, pois agora você sabe criar atalhos, não é mesmo? Podemos, por exemplo, criar um atalho com o nome alias:

git config alias.alias "! git config -l | grep ^alias\. | cut -c 7- | sort"

Por comandos como grep e sort não serem do Git, tivemos que iniciar a linha de comando com !. Perceba que por causa disso, nossa primeira instrução teve que chamar o Git.

O $ git config -l lista as configurações do Git. Pegamos o retorno e passamos ao comando $ grep, que serve para fazer busca de textos. Como queremos os atalhos, que vimos que começa com “alias”, mandamos o grep buscar por tudo que começa com alias.. Para termos uma lista mais limpa, usamos o comando cut para remover a parte “alias.” do nome dos atalhos. Por fim, usamos o comando sort para ordenar nossos atalhos em ordem alfabética.

10 – Trabalhando em mais de uma coisa sem fazer commit

Pode haver momentos em que você precisa parar o que está fazendo e começar a trabalhar em outra tarefa. Porém, pode não ser bom fazer o commit de algo que ainda não foi finalizado para depois voltar nele, resultando em um commit que ficará no histórico mas que possui um código que não funciona. Nós podemos salvar essas alterações feitas mesmo sem precisar realizar um commit para depois voltar a trabalhar nela, o que é chamado de Stash (algo como “esconder” ou “acumular”).

Ao fazer isso, seu repositório voltará ao estado do último commit, e as alterações feitas anteriormente estarão “escondidas”.

10.1 – Salvando modificações em um Stash

Simplesmente execute o comando stash

$ git stash

Você ainda pode colocar um nome nesse stash:

$ git stash push -m meu-novo-stash

10.2 – Listando Stashes

Você pode fazer vários stashes. Para listá-los, execute o comando:

$ git stash list

10.3 – Recuperando modificações

Se algo foi salvo no stash, basta executar o seguinte comando para recuperar as alterações que foram jogadas lá:

$ git stash apply

Isso vai recuperar o código do stash mais recente. Se quiser recuperar um stash mais antigo, basta ver o número do stash que aparece quando o listamos e passar para o seguinte comando:

$ git stash apply stash@{2}

10.4 – Removendo Stashes

Quando nós recuperamos alterações de um stash, ele continua guardado. Para apagá-lo da pilha, execute o comando drop junto ao nome do stash que você quer remover:

$ git stash drop stash@{5}

Se você quiser recuperar o código de um stash e já apagá-lo, pode usar o comando pop no lugar do apply.

11 – Juntando alguns pedaços do trabalho

Pode ser que você esteja trabalhando em uma branch e queira fazer o merge do código dela com outra branch, mas não quer juntar o trabalho inteiro, apenas um commit específico. Isso é possível com o Cherry Pick.

git cherry-pick id-do-commit
Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

Primeiros passos com o Git

O que é o Git?

O Git é um sistema de controle de versão distribuído, utilizado principalmente no desenvolvimento de software e, assim como diz em sua página inicial, tanto em projetos pequenos ou de grande porte. Gratuito e open source, foi desenvolvido por Linus Torvalds para o desenvolvimento do Kernel Linux (Código aberto para sistemas operacionais tipo Unix). Seu lançamento foi em 2005 e atualmente se encontra na versão 2.21.0 (24/02/2019).

Mas Git e GitHub são as mesmas coisas?

Antes de prosseguirmos para instalação, caso tenha essa curiosidade, já temos um artigo aqui no blog sobre este assunto: Git e GitHub: quais as diferenças?

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

Como instalar

O primeiro passo para instalação do Git em sua máquina, é acessar o seu site para realizar o download.

O link é: https://git-scm.com/

Em seu site você encontra toda documentação, comunidade, download (para diferentes sistemas operacionais – Windows, Mac e Linux), empresas e projetos que utilizam o Git (Google, Facebook, Twitter, Netflix, entre outras) e muito mais.

Principais comandos

  • Inicializar um diretório

Para inicializar um diretório utilizaremos o comando git init. Com ele é possível a criação de um diretório vazio (basicamente um diretório .git) ou a reinicialização de um diretório já existente.

Este comando é utilizado sempre que queremos determinar que um diretório será utilizado para armazenar código-fonte de um projeto versionado pelo git.

  • Clonar um repositório

Para copiar um diretório já existente, por exemplo, de um projeto que você queira contribuir, utilizaremos o comando git clone. Este comando irá criar uma cópia idêntica do projeto no seu computador para que seja feita alguma alteração em seus arquivos.

  • Adicionar arquivos

Para adicionar arquivos que serão, posteriormente, versionados pelo git, utilizamos o comando git add. Este comando irá adicionar um ou mais arquivos ao controle de versionamento do git, fazendo com que todas as alterações deste arquivo sejam monitoradas posteriormente.
Todos os arquivos adicionados pelo git add são armazenados no INDEX, uma área onde todo o controle de versionamento acontece. Vale lembrar que o comando git add não está adicionando um novo arquivo ao repositório, ele só indica quais arquivos serão utilizados na nova versão do projeto.

  • Commitar mudanças

Após determinar quais arquivos farão parte da nova versão de um projeto, utilizamos o comando git commit para criar um comentário que identifica essas novas alterações. Vale lembrar que o comando git commit também gera um número automático para identificar, de forma única, cada alteração no projeto.

  • Enviar mudanças para o servidor

Depois de gerar um identificador para as alterações com o comando git commit, utilizamos o comando git push para enviar as alterações para o servidor git configurado em nosso repositório. Basicamente, é com este comando que fazemos o “upload” das alterações.

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO
  • Obter mudanças do servidor

Além de enviar alterações para o servidor, podemos capturar alterações que estejam salvas no servidor e não localmente. Para isso, utilizamos o comando git pull. Este comando é muito útil quando estamos desenvolvendo um projeto em equipe e precisamos obter as alterações feitas por outro membro do time.

  • Obter status

Para obter o status das alterações feitas nos arquivos do repositório, utilizamos o comando git status. Este comando irá retornar a lista de arquivos que foram modificados e que podem ser enviados para o servidor.

Git Merge e Git Rebase: quando usá-los?

O Git é uma ferramenta de controle de versão que facilita muito o trabalho das equipes de desenvolvimento. Muitos desenvolvedores utilizam o Git para realizar o controle dos artefatos de código que vão sendo gerados ao longo do tempo. E, certamente, este controle envolve administrar os possíveis conflitos em arquivos quando dois ou mais desenvolvedores alteram o mesmo trecho de código ao mesmo tempo. Nesse tipo de situação, temos o famoso e temido “merge”, onde precisamos mesclar as alterações de todos os desenvolvedores, de modo que nenhum deles perca seu trabalho.

Quando falamos exclusivamente sobre o Git, nós temos duas maneiras de fazermos este trabalho de “mistura” de código: utilizando o comando rebase ou utilizando o comando merge. Vamos verificar nesse artigo as diferenças entre estes dois comandos e quando é a melhor hora de usar cada um. Ambos os comandos resolvem o mesmo problema, porém, de maneiras diferentes.

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

O que é o git merge?

Vamos imaginar que você precisa começar a trabalhar em uma tarefa dentro de um projeto controlado pelo Git. Se você seguir corretamente o Git Flow, você precisará criar um branch para que você consiga trabalhar em sua tarefa. Podemos ilustrar esta situação da seguinte maneira:

À medida que você for trabalhando na sua tarefa, você provavelmente irá gerar vários commits em seu branch. Nossa ilustração poderia ficar da seguinte maneira:

Até aí, tudo ocorrendo na normalidade. Porém, o grande problema que podemos enfrentar é quando o branch master em nosso cenário fica “dessincronizado” com relação ao branch da nossa funcionalidade. Essa dessincronização pode acontecer por uma situação bem comum: outras pessoas mexeram no branch master enquanto trabalhávamos no branch da nossa tarefa. E a grande confusão vem do fato que o branch da nossa tarefa também foi gerado através do master, porém, em um momento anterior destas alterações. Podemos ilustrar essa situação da seguinte maneira:

Nós precisamos, de alguma maneira, misturar os commits do branch da nossa tarefa com os commits posteriores que foram feitos no branch master, quando este for “fundido” novamente. Uma das maneiras de se fazer isso é justamente utilizar o git merge.

O merge basicamente cria um novo commit no branch onde o merge é realizado. Este commit puxa consigo a última referência do branch a partir do qual o merge é realizado. Este commit “especial” é chamado de merge commit. Supondo então que você rode os comandos abaixo:

git checkout feature # indo para o branch da feature
git merge master     # fazendo o merge entre o feature e o master

Nós podemos ter a ilustração abaixo:

O merge é legal principalmente porque ele não altera os branches envolvidos. Na ilustração anterior, você pode perceber que tanto o branch feature quanto o branch master não são gerados. O master nem teve suas estruturas envolvidas na operação, enquanto o branch feature teve somente um commit adicional.

O fato de a estrutura dos branches envolvidos não ser diretamente modificada reduz a possibilidade de haver problemas durante a operação de merge, mas também cria um commit adicional “esquisito” a cada operação. Esse commit adicional pode prejudicar a leitura do histórico dos commits através do git log, principalmente para quem ainda não está tão ambientado ao Git e seus conceitos.

O que é git rebase?

Vamos, mais uma vez, considerar a situação na qual os branches feature e master estão “dessincronizados” e precisam ser misturados. Vamos relembrar a ilustração que mostra esta situação.

Nós também podemos resolver esta situação através do rebase. O rebase literalmente unifica os branches envolvidos, puxando os commits para frente do branch de destino. É como se ele estivesse “refazendo” a base do branch onde o comando é executado.

Sendo assim, se executarmos os comandos abaixo:

git checkout feature # indo para o branch da feature
git rebase master    # fazendo o rebase entre o feature e o master

Nós podemos ter a ilustração abaixo.

Pela ilustração acima, podemos ver que algo legal que o rebase faz é produzir um histórico linear, mais limpo e mais fácil de ser lido, pois os branches são literalmente fundidos. Pela fusão, também não é gerado aquele commit adicional “estranho” que acontece no merge.

Agora, o grande problema é que o rebase mexe com toda a estrutura dos branches envolvidos, reescrevendo inclusive o histórico de commits destes branches. Se este processo de reescrita não for bem executado, podem ocorrer vários problemas no histórico dos branches envolvidos, causando até mesmo perda de trabalho durante o processo de mesclagem. Existe também o ponto de que, pelo fato de o rebase não gerar o merge commit, você não consegue ter a “rastreabilidade” de quando dois branches de fato foram fundidos, já que o rebase gera um branch linear no final do processo.

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

Quando usar o git merge e quando utilizar o git rebase?

Ambos os comandos são muito úteis, porém, em situações diferentes. Quando seguimos corretamente o Git Flow, existe uma regra que chamamos de “Golden Rule of Rebasing”. Basicamente, essa regra diz que o rebase não deve ser utilizado em branches públicos, já que ele tem um alto potencial catastrófico e destrói o histórico de commits, causando sempre divergências entre os branches locais e os branches remotos. Porém, existe um fluxo de trabalho muito legal que pode ser utilizado, combinando ambos os comandos.

Vamos voltar à nossa situação inicial: você precisa desenvolver uma tarefa. Você provavelmente irá gerar um novo branch para desenvolver sua tarefa a partir do master. Podemos ter então o comando abaixo:

git checkout –b feature # criando o branch de trabalho

Isso gerará a seguinte ilustração:

Depois, nós poderemos gerar nossos commits, salvando nosso trabalho gradativamente…

… enquanto outras pessoas podem ir misturando seus commits ao master.

Agora chega a hora de integrarmos nossos commits ao master. Nós precisamos fazer isso em duas vias, basicamente:

1) Trazer as alterações que foram inseridas no master posteriormente para dentro de nosso branch. Precisamos deste passo para garantir que as alterações posteriores não irão “quebrar” as alterações que fizemos em nosso branch;

2) Levar as alterações do nosso branch para o master, atualizando-o com o nosso trabalho e o disponibilizando para os demais desenvolvedores.

Vamos tratar do primeiro passo neste momento. Se pararmos para analisar a situação, faz mais sentido trazer os commits de master para feature de maneira “transparente”, ou seja: sem a necessidade de um commit adicional. Isso vai manter o nosso histórico completamente linear e irá garantir que os novos commits advindos do master serão aplicados a nosso branch no “momento correto”, preservando a ordem no qual eles foram gerados. Por isso, para esta primeira etapa, o rebase faz muito mais sentido. Sendo assim, supondo que já estejamos no branch feature, podemos executar o comando abaixo:

git rebase master

Isso irá produzir a seguinte ilustração:

O primeiro passo foi concluído! Nós temos o nosso branch feature devidamente sincronizado. Porém, nosso branch master, que é o branch principal, ainda está defasado, pois ele ainda não possui os nossos commits. Nós precisamos puxar nossos commits do branch feature para o branch master. Como estamos falando do branch principal, é importante mantermos a rastreabilidade do processo de gestão do código, deixando claro inclusive quando os commits de branches locais foram puxados para o branch master.

Por isso, para essa segunda etapa, o merge é muito mais interessante do que o rebase.
Nesta situação, todos os possíveis problemas de “mistura” dos dois branches (como conflitos) foram resolvidos durante o processo de rebase. Nesta segunda etapa, nós podemos simplesmente trocar o ponteiro do nosso branch master, apontando-o para o último commit do nosso branch feature. Quando esse processo acontece, nós chamamos esta estratégia de merge de fast-foward. O fast-foward é possível quando não existem conflitos entre os branches envolvidos e quando o branch de desenvolvimento está à frente do branch principal. E, pela ilustração anterior, é exatamente esta a situação.

Portanto, se executarmos os comandos abaixo:

git checkout master # indo para o branch do master
git merge feature    # fazendo o merge entre o master e o feature

Teremos no final a ilustração abaixo:

Por isso, nosso branch master agora está da seguinte maneira:

Veja que, dessa maneira, temos o melhor dos dois mundos: não temos o histórico de commits poluído pelos commits secundários no branch feature (graças ao rebase) e temos a rastreabilidade do momento onde o branch master foi modificado por uma integração (por causa do merge).

Git e GitHub: quais as diferenças?

Muitas pessoas pensam que Git e GitHub são a mesma coisa. Isso é uma dúvida comum principalmente de quem está começando. Entender cada um deles e como eles funcionam é importante, pois se não agora, uma hora você vai precisar.

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

O que é o Git?

O Git é um sistema de controle de versão de arquivos. É um software livre e muito utilizado no desenvolvimento de software onde diversas pessoas estão contribuindo simultaneamente, podendo criar e editar arquivos. Sempre quando alguém disponibiliza sua parte do projeto no Git, ele gerencia as alterações feitas e guarda um histórico. Isso é importante pois se houver algum problema você pode desfazer as alterações e voltar para a versão que estava estável.

O Git foi projetado e desenvolvido pelo Linus Torvalds para o desenvolvimento do Linux e foi adotado por muitos outros projetos.

Existem sites que provêm hospedagem gratuita de código fonte para repositório Git, um deles é o GitHub.

O que é o GitHub?

O GitHub é uma plataforma onde você pode armazenar seus projetos. É como se fosse uma rede social, só que de códigos, onde seus desenvolvedores podem disponibilizá-los para outras pessoas verem.

Quando seu projeto está no GitHub, você pode facilmente baixar uma cópia em outro computador. É uma plataforma gratuita e armazena milhões de projetos, tanto open source, pessoais e até mesmo comerciais. Alguns projetos bem conhecidos são o WordPress e o Linux. Hoje o GitHub pertence a Microsoft, que o adquiriu no ano de 2018.

Muitas pessoas utilizam o GitHub como portfólio de seu trabalho para que empresas possam vê-lo. Se você ainda não possui um GitHub e quer fazer parte, basta criar uma conta e um repositório.

O GitHub só suporta o Git, então para você subir seus projetos deve utilizá-lo, mas a integração entre eles é bem fácil. Agora caso queira utilizar somente o Git, não tem problema. Ao contrário do GitHub, o Git não depende do GitHub para ser utilizado.

Se você quiser aprofundar seus conhecimentos no Git e GitHub, conhecer os comandos e tudo mais, dá uma conferida no nosso curso 😊

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

Até mais!