Desde que comecei a estudar programao com maior assiduidade procuro metodologias de documentar o que venho aprendendo de alguma forma. Um amigo recomendou utilizar o Dev.to e minha experincia tem sido bastante positiva.

Sendo assim, irei documentar tudo que acabo estudando ou desenvolvendo, alm da soluo de problemas que eventualmente venham a ser um percalo no meu processo de aprendizado.

Neste Post irei tratar da utilizao do Git. Abordando todos os pontos que estudei e desafios enfrentados durante o estudo. Sintam-se livres para comentar e adicionar dicas adicionais. Posteriormente poderei criar anexos com observaes e dicas teis que edifiquem o contedo tratado. Ento vamos l.

ndice

1. O que Git
2. Como configurar o git
3. Repositrios
4. Ciclo de vida de arquivos
5. O que um commit
6. Visualizando diferenas entre arquivos
7. Branch
8. Visualizando Logs
9. Manipulando commits
10. Merge

O que Git

Em resumo, o git um sistema de controle de versionamento. isso.

Ok, a definio certamente mais complexa, mas foi a melhor frase que encontrei para definir a funo principal do Git. Ele certamente o sistema de controle de versionamento mais utilizado no mundo, e essa fama se d pela facilidade de uso, e principalmente no desempenho.

Mas o que so sistemas de controle versionamento?

O controle de verso a atividade de rastrear e gerenciar as mudanas em um cdigo de software. Atravs dele as equipes de desenvolvimento conseguem realizar mltiplas tarefas e modificaes de cdigo com o intuito de adicionar funcionalidades, corrigir bugs entre outras atividades.

Os sistemas de controle de verso guardam as alteraes ao longo do tempo em um tipo de banco de dados especial que pode ser visualizado e chamado quando se deseja obter uma certa verso especfica do cdigo. Geralmente essa solicitao ocorre quando erros so cometidos e se quer voltar numa verso anterior do cdigo.

Assim como todo software, necessitamos configurar suas opes para que possamos utilizar com maior preciso e utilizar seus recursos com maestria. Desse modo, vamos comear pelo bsico.

Como configurar o Git

Baixando o Git

Para comearmos a utilizar o controle de verso em nossos projetos devemos inicialmente instalar o Git no nossa mquina. Essa instalao pode ser feita atravs do download do Git atravs do site oficial do Git.

No meu caso estou utilizando atualmente o Windows 10 Pro e a verso mais atual do Git disponvel esta do dia 06/06/2021.

Configurando o Git

Aps instalado o Git em nosso sistema, devemos fazer as primeiras configuraes para utilizarmos o controle de verso adequadamente.

As configuraes do utilizador podem ser visualizadas atravs do comando:

git config --list

Numa primeira instalao, algumas informaes como o nome do usurio, e-mail e editor padro por exemplo no tero sido definidas. Sendo assim, configuraremos cada informao.

Escopos do Git

Antes de nos aprofundarmos nas configuraes do Git, quero apenas explanar parcialmente sobre os escopos dos comandos.

O Git guarda as informaes em trs lugares:

• GitConfig --system:Altera as configuraes para todos os usurios do seu sistema se utilizada a opo --system
• GitConfig do usurio --global:Altera as configuraes apenas para o usurio que est executando o projeto. --global
• GitConfig do projeto:Altera as configuraes apenas do projeto que se est desenvolvendo. O comando para utilizar este escopo :git config

Configurao dos dados

Para definir informaes que aplicaremos para todos os repositrios de um usurio, utilizaremos a configurao global.

Configurando o user-name:

git config --global user.name "nomedousuario"

Configurando o e-mail:

git config --global user.email "seuemail"

Voc pode utilizar tambm um editor padro para o seu cdigo. Por padro o Vim utilizado. No meu caso, quero definir meu editor de texto padro para o VS Code. Voc pode utilizar o seguinte comando para utiliza-lo tambm:

git config --global core.editor "code --wait"

Caso voc utilize outro editor de texto, sugiro procurar a documentao que trate desta temtica.

Essas so as configuraes elementares do Git. Para visualizar as configuraes definidas, voc pode chamar no control cada uma:

git config user.name - No caso do nome do usurio.
git config user.email - No caso do e-mail.

Pronto, a configurao mais bsica do git foi feita. Agora, quando realizamos alteraes em nosso cdigo e submete-las ao git, essas informaes sero levadas tambm.

Repositrios

Obviamente todo mundo que est desenvolvendo um projeto precisa colocar esse projeto em algum lugar para administrar suas verses, guardar de maneira segura seus dados, enfim, gerenciar todas as atividades desenvolvidas durante o processo de produo. Como eu j disse, o Git auxilia nisso, e para comearmos a executar tais atividades necessitamos criar algo chamado repositrio.

O repositrio Git armazena todas as alteraes feitas em um projeto dentro de uma pasta chamada .git/. Aqui ele constri algo como uma linha do tempo que armazena cada alterao enviada. Cada alterao guarda um cdigo Hash nico que poder ser chamado posteriormente para consulta dos dados armazenados. Vou detalhar tudo a seguir. Vamos partir para a inicializao e cada etapa ser explanada.

Inicializando repositrios

Para iniciarmos um repositrio devemos antes de qualquer coisa ter um projeto, neste caso vou criar um diretrio atravs do terminal do Win10.

mkdir git-project

Depois de criado o diretrio, podemos adicionar um novo arquivo, no nosso caso irei criar um HTML para simular algumas alteraes.

touch index.html

Pronto, agora temos um repositrio chamado git-project e dentro dele temos um arquivo chamado index.html. Vamos imaginar que esse o nosso super projeto, iremos usa-lo por hora para explicar alguns conceitos.

Destrinchando o Git Init

Agora que j temos o mnimo para iniciar o repositrio, podemos prosseguir com o estudo.

Vamos inicializar um novo repositrio para o diretrio criado, a inicializao feita atravs do seguinte comando:

git init

Quando inicializamos um repositrio atravs do comando supracitado, o Git cria um repositrio vazio o .git/ com subdiretrios para objects, refs/heads, refs/tags arquivos e models. Alm disso, cria uma branch vazia sem nenhum commit. (Veremos mais sobre branches em breve).

Bom citar que existem outros tipos de Git Init, no pretendo me aprofundar muito, mas para efeito de informao temos:

git init Transforma o diretrio atual num repositrio Git.
git init <directory> Transforma um diretrio especificado num repositrio Git.
git init --bare Cria um novo repositrio vazio (um repositrio para ser usado apenas como um repositrio remoto). Esse tipo de init utilizado em servidores e so considerados apenas repositrios para armazenamento. Ele facilita a troca de informaes entre os desenvolvedores. No link a seguir voc pode ver um pouco sobre a diferena entre git init e git bare.

Caso voc inicialize um repositrio Git num diretrio errado voc pode remover o repositrio muito facilmente. Basta utilizar o comando $ rm -rf .git e pronto, seu repositrio local foi removido.

Caso exista o .gitignore/ e .gitmodules/ voc pode exclui-los tambm utilizando o comando $ rm -rf .git*

Quando executar, sugiro visualizar se alguma pasta oculta ainda existe.

Tudo pronto, aprendemos a iniciar um repositrio local no nosso Git. Agora podemos comear a manipular arquivos livremente. A partir daqui somos capazes de realizar alteraes em nosso cdigo e transferi-los entre status. A seguir vamos entender o ciclo de vida de arquivos e como eles se comportam no Git.

Ciclo de vida de arquivos

O ciclo de vida dos arquivos uma descrio bem grosseira para referenciar os status que cada arquivo passa durante o processo de produo de um projeto.

Quero explicar antes de tudo cada um dos status para melhor entendimento do assunto.

Status

Os status so situaes (num grosso modo) que os arquivos se encontram. Esses status so:

• Untracked - O arquivo acabou de ser adicionado mas ainda no foi visto pelo Git

• Unmodifier - Quando o arquivo foi visto pelo git mas no foi modificado.

• Modified - O arquivo foi modificado.

• Staged - rea onde ser criada a verso.

Como vemos na imagem, existem regras que levam um arquivo de um status para outro. Seguindo o fluxo podemos definir como sendo:

• Untracked -> Unmodified
  Quando adicionamos um arquivo e ele visto pelo Git e no tem modificaes, ele passa a ter o status de unmodified.

• Unmodified -> Modified
  Quando qualquer alterao no arquivo executada.

• Modified -> Staged
  Quando a modificao salva no Git. Neste momento ela ainda no foi efetivada.

• Staged -> Unmodified
  Essa alterao se d quando realizamos um commit, aqui um cdigo hash da modificao gerada e nosso arquivo est apto a receber novas mudanas do cdigo para um novo commit.

• Unmodified -> Untracked
  Quando removemos um arquivo.

Podemos visualizar o status de cada arquivo atrves de um comando que o Git nos fornece, o git status.

Este comando exibe algumas informaes relevantes sobre os status dos nossos arquivos, essas informaes podem ser:

• Onde o arquivo est.
• Os commits realizados.
• Se existe algum commit pendente.

Aqui podemos ver alguns exemplos:

Untracked

Arquivo house.html foi criado mas no foi visto pelo Git.

Staged

Aqui o arquivo foi adicionado atravs do comando git add house.html. Ele passa para o estgio stage e est pronto para ser commitado.

Staged -> Unmodified

Aqui o arquivo foi commitado, ou seja, criamos uma snap (ou espelho) das modificaes que estaro salvas num cdigo hash que podemos utilizar posteriormente.

O commit feito atravs do comando git commit -m "First commit"

-m = comando para passarmos uma mensagem.
"" = A mensagem passada entre as aspas.

A partir desse momento o arquivo tem o status de unmodified pois ele foi criado, adicionado e commitado. Agora o Git aguarda modificaes do arquivo.

Quando modifico o arquivo ele vai para o status de modified e aguarda ser transferido para o status staged. E o ciclo se inicia novamente.

Como podemos ver, entender os ciclos no muito complexo. Caso voc tenha alguma dvida, existe um curso gratuito na udemy que pode te auxiliar em todo o contexto de entendimento bsico do Git.

https://www.udemy.com/course/git-e-github-para-iniciantes/

A prpria documentao do Git pode te auxiliar nisso tambm. O link abaixo te direciona para um artigo que explica mais detalhadamente os status do Git.
https://git-scm.com/docs/git-status

O que um commit

Sei que j falei bastante de commits, que precisamos dele para subir alteraes num projeto e bla bla bla, mas no cheguei a explicar ele muito bem. Vou fazer a boa e dar uma breve introduo sobre commits para ficamos alinhados a partir daqui.

Bom, o git commit usado para salvar alteraes num repositrio local. E esse comando s funciona quando arquivos so inseridos para serem commitados, ou seja, quando passamos esses arquivos para o status staged atravs do comando git add.

Quando commitamos informaes de um arquivo criamos uma cpia dos arquivos no que podemos chamar de espelho. Cada espelho guarda todas as informaes do commit, como um cdigo hash por exemplo, que seria basicamente um ID nico que nomeia aquele commit. Quando precisamos retornar as informaes de um determinado commit, esse cdigo hash que utilizamos. Alm do hash, temos tambm quem realizou o commit e quando foi feito. Posteriormente explicarei a estrutura de informaes do commit quando estivermos estudando o git log.

Acho importante frisar que o commit adiciona no repositrio LOCAL as alteraes realizadas, ou seja, para inserirmos num remoto, precisamos de outro comando que subiria para o GitHub por exemplo, mas nos limitaremos apenas a Git neste artigo.

Aqui voc pode ler um pouco tambm sobre commits

Visualizando diferenas entre arquivos

Diff commit

Quando vamos realizar commits, podemos comparar as alteraes entre os arquivos atravs do comando git diff. As alteraes so listadas conforme a seguir:

Branch

A partir desse ponto iremos falar muito sobre branches. um assunto bem recorrente quando comeamos a trabalhar em projetos com outras pessoas, sendo assim, um conceito que precisamos entender bem para manipular com mais eficincia nosso processo de produo.

Branch exatamente o que diz a palavra se traduzida, so ramos. Esses ramos so criados para que possamos trabalhar de maneira organizada em nossos projetos. Isso porque nossos repositrios so como uma rvore, onde temos uma estrutura base(o tronco) e dela derivam todas as ramificaes(os galhos).

Quando criamos um repositrio, ele contem uma branch principal chamada branch master da qual derivam todas as outras branches. Na imagem abaixo exibida como a estrutura de ramos dos nossos repositrios.

Ao criarmos uma nova branch temos agora duas linhas de trabalho diferentes, onde podemos executar modificaes em nosso projeto sem impactar diretamente no funcionamento do mesmo. Isso permite para ns desenvolvedores, criamos funcionalidades e testa-las sem impactar no projeto principal.

Manipulando branches

Como eu disse, quando criamos um projeto novo, ele j contm uma branch, a branch master. Podemos verificar isso digitando:
git status. Ele exibir exatamente em qual branch estamos.

O caso acima nos mostra que estamos na branch master.

Alm disso, podemos ver quais branches esto disponveis no nosso projeto a partir do comando git branch.

O asterisco exibe em qual branch estamos no momento. Note que existe outra branch ativa chamada feature, nela poderemos desenvolver ferramentas para nosso projeto e depois vincular as alteraes a branch master.

Criando nova branch

Para criarmos uma nova branch, basta executarmos o comando git checkout -b nomedabranch

Quando criamos uma nova branch, automaticamente a branch ativa trocada. Acima o prprio git nos informa que "NovaBranch" a branch ativa no momento, sendo assim, as alteraes no cdigo que forem efetuadas, estaro vinculadas a essa branch especfica.

Deletando branches

Para excluirmos uma branch criada, o comando que podemos executar git checkout -D nomedabranch. Desse modo, a branch especificada ser removida do nosso projeto.

Alternando entre branches

Para mudarmos para outra branch existente basta digitarmos o comando git checkout nomeDaBranch. Assim, iremos trocar a branch ativa.

Note que aps executado o comando, o git nos informa que mudamos a branch ativa. Na imagem acima, fao a mudana para a branch master.

Voc pode acessar esse artigo do medium para entender um pouco mais sobre branch e manipulao.

Sabendo disso, podemos partir para as prximas partes do artigo. Lembrando que manipulao de branches de extrema importncia caso queiramos trabalhar com grandes projetos.

Visualizando Logs

Git Log

git log

O log tem relao direta com o seu significado em portugus, registro. Com esse comando voc pode visualizar as informaes de registro de um commit realizado. Caso tenha interesse, voc pode ler sobre esta funo aqui.

Supondo que temos um projeto j criado, o git j iniciado, e commits j executados, podemos visualizar os commits e as informaes pertinentes a cada um apenas utilizando o comando git log.

Se executar o comando, poderemos ver algo bem semelhante a imagem acima. Para descrever melhor cada informao, temos ento:

• Commit - cdigo Hash nico que nomeia o commit
• Author - Quem que executou o commit
• Date - Data que o commit foi realizado
• Mensagem - Por ltimo a mensagem que foi passada atravs do git commit -m "sua mensagem". importante descrever bem o que foi executado para que posteriormente possamos identificar com melhor preciso um commit em especfico.

Git decorate

Podemos visualizar as logs exibindo a relao entre as branches atravs do seguinte comando git log --decorate.

Diferente do git log convecional, podemos ver agora as branches de cada commit realizado.

Git Log Author

Para visualizarmos apenas os commits realizados por um autor em especfico, podemos utilizar o comando git log --author "Nome do Autor". Veja o exemplo.

Aqui o que se exibe so as mesmas informaes do git log s que filtradas por autor.

Git log graph

Podemos visualizar de forma grfica as branches dos commits realizados com o comando git log --graph, bem til caso queiramos ter uma melhor visualizao do fluxo de trabalho que estamos executando no projeto.

A linha lateral mostra o caminho que percorremos durante os commits. Note que todos os commits realizados neste caso ilustrado foram realizados diretamente na branch master, no uma prtica recomendada quando estamos trabalhando com mais pessoas e diversas outras funcionalidades. Existem metodologias de fluxo de trabalho que utilizam branches para melhor desenvolvimento de aplicaes. Vamos conhecer uma delas em breve.

Git Shortlog

Caso desejemos visualizar a relao de commits realizada por autor, podemos visualizar com o comando git log shortlog

A lista de commits por autor exibida pelo shortlog nos mostra a quantidades de commits, e a mensagem passada em cada commit. bem til caso queiramos visualizar quem executou determinada alterao no cdigo.

Caso queiramos visualizar as quantidade de commits sem exibir a mensagens, basta adicionar o comando -sn na frente do cdigo. Sendo assim, git log shortlog -sn.

Git show

Como eu j disse, a hash de um commit serve para retornar dados referente a ele e fazer algumas alteraes quanto ao projeto. O git show "cdigo hash da branch" mostra os detalhes de um commit especfico.

Existe uma documentao do prprio Git que trata do Git show. Voc pode verificar aqui no link: https://git-scm.com/docs/git-show

Manipulando commits

Quando fazemos alteraes em arquivos bem natural que existam erros e bugs. Quando executamos alteraes que influenciam negativamente na usabilidade da ferramenta que estamos desenvolvendo muitas vezes necessitamos retornar para verses antigas at que um problema seja corrigido. Para nos auxiliar no gerenciamento de verses, podemos utilizar algumas funes especficas do Git. Vamos conhecer algumas delas.

Git checkout

O comando git checkout opera em trs entidades distintas: os arquivos, os commits e as branches.

Uma descrio mais precisa da funo do checkout descrita pela Atlassian :
O checkout pode ser utilizado para visualizar commits antigos alm de realizar operaes nas branches criadas. A verificao das branches semelhante verificao de commits e arquivos antigos, e novas alteraes so salvas no histrico do projeto ou seja, no uma operao apenas de leitura.

O git checkout permite a navegao entre branches. A verificao de uma branch atualiza os arquivos no diretrio atual para que fique igual verso armazenada na branch referenciada e diz ao Git para gravar todos os novos commits nessa branch.

Retornando status de arquivos

Quando estamos desenvolvendo, natural que alguns erros sejam cometidos, utilizar a linha do tempo do Git muito til caso queiramos manipular arquivos ao bel prazer.

Quando estamos editando arquivos e eles passam do status unmodified para modified, podemos retornar essas alteraes atravs do comando git checkout NomeDoArquivo. Veja o exemplo a seguir:

Aqui existe um arquivo chamado house.html, ele est com status unmodified. Farei uma pequena modificao para visualizarmos a funo do git checkout na prtica.

Arquivo sem nenhuma modificao:

Arquivo modificado:

Quando executamos o comando git checkout house.html ele retorna o arquivo do status modified para o status unmodified, sendo assim, as alteraes deixam de existir e o arquivo volta ao seu estgio inicial.

Podemos observar com o git diff que no existe nenhuma modificao. Sendo assim, o arquivo voltou ao seu estgio de unmodified.

Git reset

Como vimos, o checkout retorna um arquivo do status modified para unmodified. Ou seja, no tem influencia quando adicionamos um arquivo para staged ou quando ele commitado. Para suprir essa necessidade, podemos utilizar outros comandos bem comuns para nos auxiliar. O git reset e suas opes.

Git reset HEAD

O comando git reset HEAD NomeDoArquivo retorna um arquivo do status staged para o status modified, desse modo, podemos fazer alguma pequena alterao antes de um commit ser realizado.

Na imagem abaixo realizei uma alterao no arquivo house.html e o adicionei ao status staged atravs do comando git add * (o asterisco adiciona todos os arquivos modificados).
Quando o arquivo passou para o status de staged utilizei o comando git reset HEAD house.html para retornar o status do arquivo especificado house.html para o status de modified. Podemos ver que aps executado o prprio git nos informa o que foi executado.

Unstaged changes after reset:M       house.html

Desse modo, podemos realizar alteraes em arquivos que esto no status staged facilmente.

Git reset e suas variaes

Alm do git reset HEAD temos outras 3 variaes de reset que devem ser utilizadas em situaes distintas. Cada um dos comandos altera de forma especfica o status de cada arquivo. As formas do git reset que temos so:

git reset --soft
git reset --mixed
git reset --hard

bom explanar que, quando queremos modificar um arquivo do comando reset, devemos sempre referenciar a hash do commit anterior ao que se est tentando dar reset. Para ilustrar posso usar os commits da imagem a seguir:

Caso eu queria realizar modificaes no commit grifado com azul, eu devo utilizar o reset referenciando o ltimo commit antes do alvo, neste caso, o hash grifado em vermelho. Sabendo disso, podemos seguir com a explicao.

Reset Soft

git reset --soft
Retorna o commit para o status staged.

Utilizamos este comando quando realizamos um commit num arquivo e desejamos corrigir ou adicionar algo.

No caso acima, referenciei a hash de um commit anterior ao foco e utilizei o git status para mostrar que o arquivo house.html voltou para o status de staged, pronto para ser commitado.

Reset Mixed

git reset --mixed
Retorna o commit para o status modified.

Aqui o commit retorna para antes de ser adicionado, apenas para o momento que foi modificado. Sendo assim, o status modified.

Reset Hard

git reset --hard
Este comando elimina totalmente o seu commit, e retorna para o commit do hash que voc est referenciando. Tudo depois dele ser eliminado.

Log antes do git reset. No comando iremos referenciar o segundo commit.

Aps o git reset --hard podemos notar que os commits posteriores ao referenciado deixam de existir.

importante lembrar que quando fazemos alguma alterao do tipo, essas alteraes so feitas no repositrio local, quando se trata de repositrios remotos alguns problemas podem surgir, como conflito de informaes entre arquivos por exemplo.

Merge

Quando estamos desenvolvendo aplicaes em times e precisamos realizar modificaes em cdigos, adicionar novas funcionalidades ou corrigir bugs, utilizamos as branches do Git para trabalhar.

Ao finalizamos as alteraes, precisamos mover essas alteraes para a branch principal (master) para que nossas funcionalidades sejam aplicadas ao projeto. Sendo assim, temos duas metodologias de fluxo de trabalho que podemos seguir para executarmos nossas alteraes devidamente. So elas o Merge e o Rebase.

Para explicar o processo de produo do Merge utilizarei a imagem a seguir. Ela exemplifica o mapa de commits num Merge. Os seus detalhes explicarei a seguir.

Na ilustrao acima podemos notar a presena de duas branches, a master e a feature. Em cada uma das branches so executados commits de acordo com as modificaes realizadas. Num determinado momento, os commits realizados na branch feature precisam ser enviados para a branch master. Desse modo, garantimos que a aplicao receba o que foi desenvolvido em outras ramificaes.

Para melhor entendimento, deixe-me descrever melhor:

• C1 - O primeiro commit realizado na branch master
• C2 - Segundo commit realizado. Aqui foi criada a nova branch chamada feature. A partir daqui comeamos a dividir o nosso fluxo de trabalho para o desenvolvimento de uma nova funcionalidade.
• C3 - Na nova branch feature, comeamos a realizar commits que inserem as configuraes da funcionalidade que queremos implementar.
• C4 - Em paralelo ao desenvolvimento na branch feature, temos modificaes executadas na prpria master. Essas alteraes so exibidas no commit C4.
• C5 - As ltimas modificaes da feature so efetuadas e a partir daqui precisamos unir nossas alteraes realizadas na branch feature, com nosso projeto da master.
• C6 - A unio das duas branches acontece atravs do commit C6, e temos agora todas as modificaes do cdigo realizadas na feature pertencendo a branch master.

Gostaria de fazer uma simulao de um Merge na prtica, desse modo sinto que visualizar o cdigo ser mais efetivo para concretizar o conhecimento.

Configuraes do projeto

• Diretrio chamado merge
• Arquivo index.html que ser modificado
• Duas branches presentes, a branch master e outra chamada feature.

O arquivo index.html foi iniciado e commitado na branch master. Alternamos agora para a branch Feature e criamos um novo arquivo chamado index.js, iremos commita-lo na branch feature. Aps isso, realizamos um novo commit na branch master. Aps essas alteraes podemos realizar um Merge entre as branches, vinculando as alteraes da branch Feature com a branch Master.Desse modo temos a estrutura de commits das duas branches ilustrada a seguir.

Descrevendo o fluxo de commits de cada branch:

Master

Apenas o commit do index.html que chamei de first commit.

Feature

Criamos uma nova branch e commitamos um novo arquivo chamado index.js na nova branch feature. Abaixo podemos verificar os commits realizados.

Como podemos ver, temos dois commits, o primeiro realizado na branch master e o o segundo na branch feature.

Master

Alternamos para a branch master e realizamos um novo commit, dessa vez alterando o contedo do arquivo index.html.

Agora precisamos unir as alteraes das branches atravs do Merge. Para realizamos um merge, utilizamos o comando:

git merge feature

O comando acima junta a branch feature com a branch master. Lembrando que para o comando funcionar, voc precisa estar na branch master, onde a feature ser mesclada. A imagem a seguir exibe a unio das duas branches. O arquivo index.js foi adicionado, logo tivemos uma nova insero.

Agora podemos verificar o histrico de commits em forma de grfico com o comando git log --graph. Ele exibe todo o fluxo de commits e nos mostra tambm de onde surgiu determinado commit.

Pela ordem de commits temos:

• first commit realizado na branch master;
• add html document realizado na branch master;
• add js realizado na branch feature;
• merge, unio entre as duas branches.

A branch master agora contm todas as alteraes realizadas na branch feature e na prpria branch master.

Com isso podemos finalizar essa breve introduo ao Git. Voc pode utilizar este artigo para fins de consulta. Aprender a teoria de assuntos muito importante para nos aprofundarmos em algum estudo, mas no se sinta pressionado a decorar cada um dos comandos, programar exige mais capacidade de aprender a consultar do que decorar mtodos.
Pretendo atualizar este guia inicial periodicamente, colocando dicas que vocs podem me mandar ou que eu posso acabar descobrindo, sintam-se livres para opinar nos comentrios. At a prxima.