Pular para o conteúdo
Início » Tutoriais / Livros / Cursos » GIT – Gerenciamento profissional de código-fonte de software

GIT – Gerenciamento profissional de código-fonte de software

Visão geral

Livro / Tutorial que organiza os artigos com o objetivo de apresentar uma sequência lógica para o aprendizado e aperfeiçoamento no uso do sistema de versionamento de código fonte GIT.

sim Não Sugerir edição
Última atualização em 1 de dezembro de 2021

O que é Gerenciamento de código fonte

Gerenciamento de código fonte (do Inglês Source Code ManegementSCM) é usado para rastrear modificações em um repositório de código fonte de um projeto de desenvolvimento de software.

O SCM monitora o histórico de mudanças em execução em uma base de código e ajuda a resolver conflitos ao mesclar atualizações de vários programadores. SCM também é sinônimo de controle de versão.

À medida que os projetos de software crescem em linhas de código e número de colaboradores, os custos de sobrecarga de comunicação e complexidade de gerenciamento também aumentam.

SCM é uma ferramenta crítica para melhorar organizacionalmente as complexidades crescentes de desenvolvimento de softwares.

Vídeo aula do curso Git Básico e Essencial

A importância das ferramentas de gerenciamento de código fonte

Quando vários desenvolvedores estão trabalhando em uma base de código de maneira colaborativa, é comum fazer alterações em uma parte compartilhada do código.

Desenvolvedores separados podem estar trabalhando em um recurso aparentemente isolado, no entanto, esse recurso pode usar um módulo de código compartilhado.

Portanto, o desenvolvedor 1 que está trabalhando no recurso 1 pode fazer algumas edições e descobrir depois que o desenvolvedor 2 que está trabalhando no recurso 2 tem edições conflitantes no mesmo arquivo ou conjunto de arquivos.

Sem a adoção do SCM, este é um cenário de pesadelo.

Por exemplo: os desenvolvedores podem editar arquivos de texto diretamente e movê-los para locais remotos usando FTP ou outros protocolos.

Imagine que o Desenvolvedor 1 faz edições, na sequência, o Desenvolvedor 2, sem saber, salva suas edições sobre o trabalho do Desenvolvedor 1 e apaga as alterações.

O papel do SCM como mecanismo de proteção contra este cenário específico é conhecido como Controle de Versão.

Leia o artigo Controle de Versão – O que é? para aprofundar seu conhecimento neste conceito.

SCM

O Gerenciamento de código fonte trouxe proteções de controle de versão para evitar a perda de trabalho devido à substituição de conflitos.

Essas proteções funcionam rastreando as alterações de cada desenvolvedor individualmente, identificando áreas de conflito e evitando gravações sobrepostas de porções de código.

O SCM então comunicará esses pontos de conflito aos desenvolvedores para que eles possam revisar e resolver com segurança antes de mesclar suas alterações na versão definitiva.

Este mecanismo básico de prevenção de conflitos  tem o efeito colateral, benéfico, de fornecer comunicação passiva para a equipe de desenvolvimento.

Desta forma a equipe pode acompanhar e discutir o trabalho em andamento que o gerenciamento de código-fonte está monitorando.

O SCM rastreia todo o histórico de mudanças na base de código. Isto permite que os desenvolvedores examinem e revisem as edições que podem ter introduzido bugs (erros) ou regressões de funcionalidades. Isto é, perda de trabalho quando uma alteração é sobreposta com uma versão antiga de código.

Git Log auxiliando no gerenciamento do códifo-fonte
Exemplo de um histórico de projeto gerenciado por Git

Os benefícios do gerenciamento de código fonte

Além do controle de versão, o SCM fornece um conjunto de outros recursos úteis para tornar o desenvolvimento de código colaborativo uma experiência mais amigável ao usuário.

Depois que o SCM começa a rastrear todas as alterações em um projeto ao longo do tempo, ele cria um registro histórico detalhado da vida do projeto.

Este registro histórico pode então ser usado para “desfazer” as alterações na base de código. O SCM pode reverter instantaneamente a base de código para um ponto anterior no tempo.

Isso é extremamente valioso para evitar regressões nas atualizações e desfazer erros.

O arquivo de Versionamento de cada mudança durante o tempo de vida de um projeto, fornece um registro valioso para as notas (anotações, comentários) de versão de lançamento de um projeto.

Um registro de histórico de SCM limpo e mantido com boa descrição das alterações pode ser usado alternadamente como notas de versão.

Isso oferece uma visão e transparência sobre o andamento de um projeto que pode ser compartilhado com usuários finais ou equipes que não são de desenvolvimento de software.

A gestão de código fonte reduzirá a sobrecarga de comunicação de uma equipe e aumentará a velocidade de liberação de novas versões.

Sem o SCM, o desenvolvimento é mais lento porque os contribuidores precisam fazer esforço extra para planejar uma sequência não sobreposta de desenvolvimento para lançamento.

Com o versionamento do software, os desenvolvedores podem trabalhar independentemente em ramos separados no desenvolvimento de recursos, eventualmente mesclando-os.

Ramos são linhas de tempo isoladas, chamadas branch.

Em geral, o gerenciamento de código fonte é uma grande ajuda para as equipes de engenharia de software, que reduz os custos de desenvolvimento, permitindo que os recursos de engenharia sejam executados com mais eficiência.

SCM é essencial na era moderna do desenvolvimento de software.

Equipes profissionais usam controle de versão e sua equipe também deve utilizar.

Resumo

  • Versionamento pelo gerenciamento de código fonte é uma ferramenta inestimável para o desenvolvimento de software moderno.
  • As melhores equipes de software praticam versionamento de software e sua equipe também deve adotar.
  • O gerenciamento de código fonte é muito fácil de configurar em um novo projeto e o retorno do investimento é alto.

Mantenha-se atualizado

Não esqueça de me seguir no Twitter e assinar o Canal Mazer.dev no Youtube para receber atualizações de novos artigos, vídeo aulas e cursos gratuitos em desenvolvimento e engenharia de software.


Para aprender mais sobre versionamento de software, gerenciamento de código fonte, e as ferramentas usadas para executá-lo, como Git, Github e Gitlab, leia os meus artigos:

sim Não Sugerir edição
Última atualização em 2 de setembro de 2021

Controle de Versão - O que é?

Você sabe “O que é Controle de Versão“, e por quê é importante no processo desenvolvimento de software?

Controle de versão é um sistema que registra alterações em um arquivo ou conjunto de arquivos ao longo do tempo, para que você possa, se necessário, recuperar e manipular versões específicas ao longo do tempo.

É importante compreender que “Controlar versões” de artefatos faz parte de diversos métodos de gestão de projetos.

Em geral o controle de versão é utilizado em arquivos de código-fonte de software que possuam controle de versão, embora na realidade você possa fazer isso com quase qualquer tipo de arquivo em um computador.

Assista o vídeo deste conteúdo

Se você é um designer gráfico, web designer ou programador – desenvolvedor de software, e quer manter todas as versões de uma imagem, layout de site (seus arquivos html e css) ou código-fonte de programa de computador – o que você certamente deveria querer, um sistema de controle de versão (VCS – Version Control System) é a ferramenta correta a ser usada.

Retornos no uso

Praticar o controle de versão de software ou projeto de outra natureza, possibilita à equipe atingir uma série de benefícios.

Desta maneira utilizar Controle de versão permite:

  • que você reverta para qualquer estado anterior determinados arquivos ou um projeto inteiro
  • compare as mudanças entre arquivos fonte ao longo do tempo
  • verifique quem modificou pela última vez algo que pode estar causando um problema
  • verifique quando e quem introduziu um determinado problema

Usar um VCS também significa que se você estragar tudo, por exemplo alterou uma rotina em um sistema e introduziu um erro crítico; ou ainda perder arquivos, pode facilmente recuperar a versão anterior e correta com muito pouco trabalho.

Tipos de Softwares para Controle de Versão

Podemos citar três estratégias diferentes de sistemas que podem ser utilizadas para controlar versões de arquivos ou projetos, são elas:

  • sistemas locais de controle de versão
  • sistemas centralizados de controle de versão
  • sistemas distribuídos de controle de versão

Sistemas Locais de Controle de Versão

O método para controlar versão de muitas pessoas é copiar os arquivos para outro diretório – talvez um diretório com carimbo de tempo.

Esta abordagem é muito comum porque é simples, mas também é incrivelmente propensa a erros. É fácil esquecer em qual diretório você está e, acidentalmente, sobrescrever o arquivo errado ou copiar arquivos que não deveria.

Buscando resolver este problema, programadores há muito tempo desenvolveram os VCS locais que possuem um banco de dados simples o qual mantêm todas as alterações nos arquivos sob controle de revisão.

Na figura de exemplo, o arquivo representado pelo ícone verde, tem suas várias versões referenciadas dentro do banco de dados de versão. Tudo isto sendo controlado no computador local.

Controle de Versão Local
Diagrama representando Sistema de Controle de Versão Local

Softwares de Controle de Versão Locais

Uma das ferramentas VCS Locais mais populares foi um sistema chamado RCS, que ainda é distribuído com muitos computadores atualmente.

Até mesmo o popular sistema operacional Mac OS X inclui o comando rcs quando você instala as Ferramentas de Desenvolvimento.

O RCS funciona mantendo conjuntos de alterações (ou seja, as diferenças entre os arquivos) em um formato especial no disco rígido; ele pode, em seguida, re-criar qualquer arquivo como era em qualquer ponto no tempo, para isto adicionando todas as suas alterações.

Sistemas Centralizados de Controle de Versão – CVCS

A próxima questão importante que as pessoas encontram é a necessidade delas colaborarem com desenvolvedores em outros sistemas ou projetos.

Para lidar com este problema, os Sistemas Centralizados de Controle de Versão (CVCS) foram desenvolvidos.

Estes sistemas, têm um único servidor que contém todos os arquivos de controle de versão, e um número de clientes que usam arquivos a partir desse local central.

Por muitos anos, esta foi a estratégia padrão da indústria de desenvolvimento de software para o controle de versão de programas.

Na figura de exemplo a seguir, o controle de versão é centralizado em um computador na rede, o servidor central de VCS.

Controle de Versão Centralizado CVCS
Diagrama representando um Sistema de Controle de Versão Centralizado CVCS

Neste computador central fica o banco de dados com as versões dos arquivos.

Cada pessoa que necessita trabalhar com um determinado arquivo, deve realizar um checkout do mesmo para o seu computador, e, após alterá-lo, realizar um checkin retornando as mudanças para o servidor central.

Softwares de Controle de Versão Centralizados

Exemplos de CVCS são o Subversion e o Perforce.

O Subversion chegou a ser o mais utilizado sistema de controle de versão no início dos anos 2000.

Vantagens dos Controles de Versão Centralizados

Esta configuração oferece muitas vantagens sobre o controle de versão local. Por exemplo: todo mundo sabe, até certo ponto o que todos os envolvidos no projeto estão fazendo.

Os administradores têm controle refinado sobre quem pode realizar quais alterações; sendo também muito mais fácil de administrar um servidor centralizado do que lidar com bancos de dados locais em cada computador “cliente”.

Desvantagens dos Controles de Versão Centralizados

No entanto, esta configuração também tem algumas desvantagens graves.

O mais óbvio é o ponto único de falha que o servidor centralizado representa. Se esse servidor apresentar problemas por uma hora, durante este período ninguém poderá colaborar ou salvar as alterações de versão para o que quer que eles estejam trabalhando.

Se o disco rígido do banco de dados central for corrompido, e backups apropriados não forem mantidos, você perde absolutamente tudo – toda a história do projeto, exceto imagens pontuais que desenvolvedores possam ter em suas máquinas locais.

Sistemas VCS locais sofrem com esse mesmo problema, isto significa que sempre que você tem toda a história do projeto em um único local, existe o alto risco de perder tudo.

Sistemas Distribuídos de Controle de Versão – DVCS

É neste ponto que Sistemas Distribuídos de Controle de Versão (DVCS) entram em cena. Atualmente pode-se afirmar que estes sistemas se confundem com a explicação sobre “o que é controle de versão”.

Em um DVCS os clientes não somente usam o estado mais recente dos arquivos: eles duplicam localmente o repositório completo.

Clique aqui e leia este artigo no blog, que ensina o Git básico.

Desta maneira, se qualquer servidor morrer, e diversas pessoas estiverem colaborando por meio de um sistema distribuído de controle de versão, qualquer um dos repositórios de clientes podem ser copiado de volta para o servidor para restaurá-lo.

Podemos afirmar que cada clone de repositório é, de fato, um backup completo de todos os dados.

Na figura de exemplo a seguir, o controle de versão possui um repositório central, onde todos os clientes colaboram enviando suas alterações e recuperando as mudanças dos demais colaboradores.

Controle de Versão Distribuído DVCS
Diagrama representando um Sistema de Controle de Versão Distribuído – DVCS

Porém, como está demonstrado na figura, em cada computador, o banco de dados de versão é duplicado entre os diversos colaboradores, de forma a apresentar distribuidamente diversas cópias dentre todos os colaboradores.

Além disso, muitos desses sistemas trabalham muito bem com vários repositórios remotos, tal que você possa colaborar em diferentes grupos de pessoas de maneiras diferentes ao mesmo tempo dentro do mesmo projeto.

Isso permite que você configure vários tipos de fluxos de trabalho que não são possíveis em sistemas centralizados, como, por exemplo, modelos de trabalho hierárquicos.

Softwares para Controle de Versão Distribuídos

Os softwares de controle de versão distribuídos mais conhecidos são: Git, Mercurial, Bazaar e ainda Darcs.

Atualmente, principalmente nos projetos de desenvolvimento de software, a principal ferramenta de versionamento de software é o Git.

Ele é usado inclusive como a base para serviços de gerenciamento de repositórios como Github e Gitlab.

Você pode ter uma visão geral do uso de Git no artigo Git Básico, ou conhecer algumas dicas e truques no artigo Git – Dicas Rápidas.

Se já conhece um pouco de Git mas têm dúvidas quanto a alguns conceitos essenciais, leia o artigo Diferença de TAG e BRANCH em GIT.

Considerações finais

Conhecer os conceitos e aplicar versionamento de software, principalmente para os projetos de desenvolvimento de software é essencial para garantir altos níveis de qualidade nos produtos finais.

Para continuar evoluindo neste conhecimento, leia o artigo O que é Gerenciamento de código fonte.


Este post apresentou uma visão geral sobre o que é controle de versão e suas diferentes abordagens por sistemas. Ele é livremente baseado no livro Pro Git.


Mantenha-se atualizado

Não esqueça de me seguir no Twitter e assinar o Canal Mazer.dev no Youtube para receber atualizações de novos artigos, vídeo aulas e cursos gratuitos em desenvolvimento e engenharia de software.

sim Não Sugerir edição
Última atualização em 23 de agosto de 2021

Git Básico

Neste artigo apresento uma visão geral e introdutória do sistema de versionamento e os comandos básicos do Git para iniciar o trabalho de gerenciamento de versão de código fonte com ele. É o sistema base para gestão de repositórios em serviços de nuvem como o Github e Gitlab.

Porém, antes de mais nada, você consegue responder à seguinte pergunta: O que é “controle de versão“, ou que é “versionamento de software“?

Conceito de Versionamento de Software

Um sistema de controle de versão registra alterações em um arquivo ou conjunto de arquivos ao longo do tempo, para que versões específicas possam ser recuperadas e gerenciadas. Esta é uma definição muito resumida sobre versionamento de software e você deveria aprofundar o conhecimento no artigo sobre “Gerência de Configuração de Software” (em desenvolvimento de software)

Git é hoje o sistema de controle de versão de fato do mercado de desenvolvimento de softwares.

Recomendo o artigo Controle de Versão – O que é? para uma compreensão mais abrangente sobre Versionamento de Software.

Git Básico – introdução

Assista a vídeo aula deste artigo e baixe os slides. No vídeo aprofundo as explicações para os fundamentos, e apresento de forma pratica o uso dos comandos essenciais.

Acima de tudo, é necessário compreender como funcioná o Git, para desta forma não se tornar apenas um executor de comandos como se seguisse uma receita passo-a-passo sem a real compreensão da gestão por trás do processo.

Git considera que os dados são como um conjunto de snapshots (captura de algo em um determinado instante, como em uma foto). Portanto, é possível navegar em diferentes instantes pelo tempo de seu projeto.

Cada vez que você salva ou consolida – ou seja, realiza um commit, o estado do seu projeto no Git, em resumo, é como se ele tirasse uma foto de todos os seus arquivos naquele momento e armazenasse uma referência para essa captura.

Com o propósito de ser eficiente, se nenhuma alteração foi realizada em um determinado arquivo, em um instante de versionamento, a informação deste arquivo não é armazenada novamente. Em outras palavras, apenas um link para o arquivo idêntico anterior que já foi armazenado. Dessa forma o sistema garante economia eficiente de espaço, além de performance.

Checkins, commits no tempo
Visão de registros de versionamento em um repositório

Características

A princípio, as principais características são:

  • Quase todas operações são locais
  • Git tem integridade checksum
  • Git geralmente só adiciona dados

Estados dos arquivos

  • consolidado (committed): quando estão seguramente armazenados em sua base de dados local
  • modificado (modified): quando houve uma alteração que ainda não está consolidada
  • preparado (staged): quando um arquivo modificado é marcado para fazer parte de um commit

Workflow

O fluxo básico e diário de trabalho pode ser descrito com os seguintes passos:

  1. Você modifica arquivos no seu diretório de trabalho.
  2. Você seleciona os arquivos, adicionando snapshots deles para sua área
    de preparação.
  3. Você executa um commit (que é um comando do Git), o qual leva os arquivos como eles estão na sua área
    de preparação e os armazena permanentemente no seu diretório Git.
Fluxo de operações local

Seus repositórios locais consistem em três “árvores” mantidas pelo git.

  • Working Directory que contém os arquivos vigentes.
  • Index que funciona como uma área temporária (stage)
  • HEAD que aponta para o último commit (confirmação) que você fez.
Árvores de organização do git

A partir de um estado “não gerenciado”, os arquivos entram em um ciclo de alterações de estado a cada modificação e posterior consolidação.

Fluxo do Git básico

Instalando o Git – Linux e Windows

Em sistemas operacionais Linux baseados em Debian, ou seja: Ubuntu, Linux Mint, o Git está disponível nos repositórios padrões de pacotes, basta executar o seguinte comando no console:

sudo apt-get install git

Para o Windows é necessário fazer o download de um instalador, que ao ser executado além de disponibilizar o Git, também disponibiliza um console compatível com Bash Shell dos terminais Linux.

Primeiramente baixe o arquivo no site git for Windows.

Encontre o arquivo em seu computador e execute o instalador, a partir deste ponto apenas siga os passos de instalação.

Para informações mais detalhadas sobre a instalação do Git, clique aqui.

Configuração básica do Git

Para utilizar o git em sua máquina, em primeiro lugar é necessário configurar com seus dados de autor. Uma vez que todos os commits devem ser identificados.

O arquivo /etc/gitconfig contém valores de configuração para todos usuários do sistema e todos os seus repositórios. Se você passar a opção --system para git config, ele lerá e escreverá a partir deste arquivo especificamente.

O arquivo ~/.gitconfigé específico para seu usuário. Você pode fazer o Git ler e escrever a partir deste arquivo passando a opção --global.

O arquivo de configuração no diretório git (ou seja, no repositório local) .git/config é específico para aquele único repositório. Cada nível sobrepõem o valor do nível anterior, sendo assim valores em .git/config sobrepõem aqueles em /etc/gitconfig.

Em sistemas Windows, Git procura pelo arquivo .gitconfig no diretório $HOME. Isto significa um dos diretórios a seguir: C:\Documents e Settings\$USER, para a maioria dos usuários.

Comandos para configurar nome e email

Definir seu nome e email para serem adicionados como autor nos commits.

Para configuração global no sistema atual, por exemplo usando meus dados:

git config --global user.name "Ademir Mazer Junior"
git config --global user.email [email protected]

Para entender como configurar seu username e email por projeto ou para todo o sistema, clique aqui.

Configurar o Git com Prompt colorido:

git config --global color.ui true

Comandos para listar configurações

Para listar todas as configurações

git config --list

Para listar uma configuração específica, por exemplo o user.name:

git config user.name

Ajuda no Git

Para listar comandos (ações) disponíveis e abrir o manual de help para cada ação, use os comandos a seguir:

git

Digitar apenas git lista todas as ações disponíveis com uma explicação resumida de seu objetivo. Desta maneira é possível ter uma visão geral dos comandos existentes.

git help <ação>

Abre a página de manual da ação especificada, por exemplo: git help commit

Criando um repositório local no Git

Para criar um novo repositório:

git init
  • crie uma nova pasta (pode ser criado um novo repositório em uma pasta com arquivos existentes)
  • acesse a nova pasta pela linha de comando
  • digite o comando de criação de repositório

Por exemplo, em um sistema linux:

mkdir novodiretorio
cd novodiretorio
git init

Verificando o status

Para verificar o status do repositório, isto é, em que branch e quais arquivos estão modificados, utilize:

git status

Obtendo um repositório remoto no Git

Primeiramente, obter um repositório significa realizar um clone de um repositório remoto, com a finalidade de baixar e conectar seu diretório de trabalho git local com ele.

O clone será criado a partir do diretório onde você está situado, dessa forma, tenha certeza que o subdiretório estará no local que deseja.

Para criar uma cópia de trabalho em um repositório local executando o comando:

git clone /caminho/para/o/repositório

Por exemplo, quando usar um servidor remoto Github, seu comando poderá ser

git clone https://github.com/uepg/laravel-sybase.git

Desse modo o comando acima criará o subdiretório laravel-sybase a partir do ponto em que você está no sistema de arquivos.

Adicionar e confirmar alterações

As ações de: adicionar arquivos para serem rastreados, informar mudanças e consolidar estas alterações; é o núcleo do fluxo de trabalho de versionamento com Git. Em resumo, é o seu fluxo básico, ou seja, o que você faz diariamente para garantir este controle.

Para adicionar (propor) mudanças, isto é, adicioná-las ao Index, este é o primeiro passo no fluxo de trabalho básico do git, use a ação git add, por exemplo:

git add <arquivo>
git add *

Usando o coringa tudo ( * ) você adiciona todas as alterações e novos arquivos. Mas pode, e geralmente, deve, selecionar o conjunto de arquivos indicando-os individualmente ou em conjunto.

Para realmente confirmar estas mudanças, isto é, consolidar no repositório local, use commit. Como boa prática, sempre com comentários, por exemplo:

git commit -m “comentários das alterações”

Como resultado o arquivo é “enviado” para o HEAD, no repositório local, no entanto, ainda não para o repositório remoto.

Em resumo: ao criar ou alterar arquivos, git add, em seguida, consolida-se com git commit.

Ignorando arquivos

Primeiramente é necessário entender que rastrear arquivos binários, como executáveis, ou diretórios e arquivos de configuração de IDEs, por exemplo, não são boas práticas, pois o repositório usará muito recurso de espaço e aumentará o uso de tempo para processar suas ações. Por consequência degradando seu desempenho se tornando menos eficiente.

Dessa forma informar ao Git que certos arquivos ou diretórios devem ser ignorados é uma boa prática para gestão de repositórios.

Para ignorar arquivos, crie padrões dentro de um arquivo .gitignore no raiz do repositório. Por exemplo:

# Compiled source #
*.com
*.class
*.dll
*.exe
*.o
*.so

Os arquivos .ignore podem ser usados no raiz do projeto, ou em subdiretórios se isto facilitar a sua gestão.

Com o intuito de oferecer um conjunto de arquivos comuns a serem ignorados, o gist a seguir, do Octocat no Github, por exemplo, possui uma série de arquivos .ignore que podem servir de base inicial para seu repositorio

https://gist.github.com/octocat/9257657

Atenção: Arquivos que já estão sendo rastreados não são afetados pelas regras do .gitignore, dessa forma, não adianta incluir um arquivo nas regras depois que ele já estiver sendo gerenciado pelo Git.

Enviando alterações ao repositório remoto

Suas alterações agora estão no HEAD da sua cópia de trabalho local, ou seja, o repositório remoto não contém estas alterações. Para envia-las ao seu
repositório remoto, por exemplo, enviar a branch master, execute

git push origin master

Altere master para qualquer ramo (branch) desejado, enviando suas alterações para ele.

Porém, se você não clonou, isto é, não criou o repositório a partir de um repositório existente e deseja conectar seu repositório a um servidor remoto, você deve adicioná-lo com o comando

git remote add origin <servidor>

Dessa forma agora você é capaz de enviar suas alterações para o servidor remoto selecionado.

Log do repositório

Para consultar o histórico (log) das alterações, commits, tags criadas, isto é, se você deseja verificar o log de alterações de um repositório (tag, branch), basta usar o comando

git log

Este comando irá listar a atividade em ordem cronológica do mais recente para mais antiga. A listagem é apresentada possibilitando sua navegação, por exemplo, usando setas para cima e para baixo. Para sair desta navegação utilize a tecla q (que).

Atualizar e mesclar alterações

Para atualizar seu repositório local, isto é, “puxar” as alterações mais novas de versionamento, provavelmente de seus colegas de equipe, do repositório remoto, execute o comando a seguir na sua
pasta de trabalho. Este comando executará duas ações: obter as alterações remotas e fazer merge (mesclar) com as alterações locais.

git pull

Para fazer merge de um outro branch em seu branch ativo, por exemplo, se você está no branch feature-200 e deseja incorporar as alterações já aceitas no dev:

git merge <branch>
# seguindo o exemplo descrito
git merge dev

Conflitos

Quando um merge resulta em conflitos, isto é, porções do mesmo código foram alteradas por usuários diferentes, ou em branches diferentes; você é responsável por fazer o merge destes conflitos manualmente editando os arquivos exibidos pelo git.

Depois de realizar as alterações de ajuste dos conflitos, é necessário marcá-los como merged com o comando git add <arquivo> antes de fazer o merge das alterações.

Estou escrevendo um artigo exclusivamente para tratar de mesclagem de códigos e gestão de conflitos com Git, me siga no twitter para receber a atualização quando for lançado

Ramificações

Primeiramente, o que são ramos? Branches ou “ramos” são utilizados para desenvolver funcionalidades isoladas umas das outras. O branch master é o ramo “padrão” quando você cria um
repositório. De forma geral, uma boa prática, é utilizar outros branches para desenvolver e mescla-los (merge) ao branch master após a conclusão das alterações. Como por exemplo demonstrado na imagem a seguir

Representação simples de um branch/merge
Demonstração de uma ramificação do master e posterior merge

O “mapa” visual mais comum para representar os ramos de um repositório seguem o exemplo a seguir

Representação de ramificações em um repositório Git
Representação de ramificações em um repositório Git

Criando branches e navegando entre eles

Em primeiro lugar, é importante saber que a criação de um novo branch é realizada como uma cópia do “momento” em que você está em seu diretório de trabalho do repositório.

Há mais de um comando Git para criar branch:

  • git branch <nome-da-branch>
  • git checkout -b <nome-da-branch>

Utilizo com frequência a ação de navegar entre ramos:- git checkout, com a opção -b, para criar um novo branch, pois se utilizar o git branch diretamente será necessário ainda executar um git checkout para mudar o diretório de trabalho para a nova branch recém criada.

Por exemplo, se quero criar um ramo chamado funcionalidade_x, a partir do ponto em que estou, uso o comando

git checkout -b funcionalidade_x

Como resultado, o branch funcionalidade_x é criado e o git altera o diretório de trabalho para ele. Dessa forma, ao alterar arquivos e realizar os commits, as alterações serão consolidades neste ramo.

Leia também este artigo Diferença de TAG e BRANCH em GIT

Se precisar trocar de branch, isto é, navegar ou, alterar o seu diretório de trabalho em outro branch, use checkout sem o -b, por exemplo, para voltar ao branch master

git checkout master

Se precisar excluir, ou seja, remover um ramo do diretório de trabalho local, use a opção -d da ação branch. Por exemplo para excluir o ramo funcionalidade_x

git branch -d funcionalidade_x

Fique atento à atualização do repositório central se necessitar disponibilizar um branch aos demais integrantes da equipe, ele não estará disponível a menos que você o envie ao remoto

git push origin <nome-do-branch>

Como visto neste artigo, Git é um sistema de versionamento eficaz e eficiente para a Gestão de Configuração em seu projeto de software. Esta foi uma introdução que demonstrou um panorama geral do uso diário e mais comum das duas funções.

Em breve disponibilizarei novos artigos e material de estudos aprofundados cobrindo tópicos e ações específicas no fluxo de trabalho com Git.

Não deixe de realizar a prática inicial guiada, que está disponível no final do conjunto de slides do arquivo a seguir. Também assista a vídeo aula onde explico com mais detalhes os itens e conceitos descritos neste artigo.

Mantenha-se atualizado

Não esqueça de me seguir no Twitter e assinar o Canal Mazer.dev no Youtube para receber atualizações de novos artigos, vídeo aulas e cursos gratuitos em desenvolvimento e engenharia de software.


Mais sobre Git, Github, Gitlab e Versionamento

Mantenha-se atualizado

Não esqueça de me seguir no Twitter e assinar o Canal Mazer.dev no Youtube para receber atualizações de novos artigos, vídeo aulas e cursos gratuitos em desenvolvimento e engenharia de software.

sim Não Sugerir edição
Última atualização em 14 de setembro de 2021

Git commits semânticos

Commits semânticos no uso de Git e outros VCS (sistemas de versionamento de código), são a melhor forma de documentação de execução de implementação, por conferir contexto à gestão de mudanças.

Escrever mensagens de commits nada claras, como task done ou bug fixed não auxiliam na manutenção de código e no histórico evolutivo do sistema.

Analise o histórico de mensagens de commit a seguir:

commit e71fcf2022b6135e18777bdc58c2ac3180202ec7
Author: mazerdev
Date: Tue Apr 24 01:25:48 2021 +1000
Extrair informações de pagamento

commit d1952883b05b685f2d22e4c41b4fbc4362fd6bd0
Author: mazerdev
Date: Mon Apr 23 22:16:50 2021 +1000
[WIP] integração

commit 74b8920d96e3e09d5cd958ffa369a0e3c86a6851
Author: mazerdev
Date: Mon Apr 23 21:09:11 2021 +1000
Gerar link para pagamento

commit b02255b25eed57c7595504c66233d5ee3024190c
Author: mazerdev
Date: Mon Apr 23 18:32:40 2021 +1000
[WIP] Pesquisa nos widgets

O pensamento de quem escreve os commits assim seriam: “Eu nunca vou me preocupar em utilizar o commit body”.

Quando você está trabalhando em uma empresa que ao criar um PR, fazer revisão de código não é comum, ninguém se preocupará em lhe pedir para escrever uma boa mensagem de commit.

Porém, isto muda quando você começa a trabalhar com equipes com uma boa cultura de engenharia, onde escrever uma mensagem de commit explícita e semântica, define a aceitação e qualidade de suas entregas.

Por onde começar?

A maioria das linguagens de programação tem convenções bem estabelecidas sobre o que constitui seu estilo idiomático, ou seja, nomenclatura, formatação e assim por diante.

Existem variações dessas convenções, mas a maioria dos desenvolvedores concorda que escolher uma e cumpri-la é muito melhor do que o caos que surge quando todos fazem suas próprias escolhas em código compartilhado.

É importante então entender que a abordagem de uma equipe para seu log de commit não deve ser diferente.

Para criar um histórico de revisão útil, as equipes devem primeiro concordar com uma convenção de mensagem de commit que estabelece pelo menos as três coisas:

  • Estilo: Sintaxe de marcação, quebra de margens, gramática, capitalização, pontuação. Remova essas coisas, elimine as conjecturas e torne tudo o mais simples possível. O resultado final será um registro notavelmente consistente que não é apenas um prazer de ler, mas que na verdade é lido regularmente.
  • Conteúdo: Que tipo de informação deve conter o corpo da mensagem de commit (se houver)? O que não deve conter?
  • Metadados: Como os IDs de rastreamento de issues e tasks, os ids de Pull e Merge Requests, etc. devem ser referenciados?

Felizmente, assim como para linguagens de programação, existem convenções bem estabelecidas sobre como uma mensagem Git commit deve ser escrita para ser idiomática.

Assim, há nada que você e sua equipe precisem reinventar. Basta seguir as sete regras abaixo e você estará no caminho certo para se comprometer (commiting 😀 ) como um profissional.

As sete regras para uma mensagem semântica de commit do Git

Somente saiba que: tudo isso foi dito antes.

  1. Separe o assunto do corpo com uma linha em branco
  2. Limite a linha de assunto a 50 caracteres
  3. Coloque a linha de assunto em maiúscula
  4. Não termine a linha de assunto com um ponto
  5. Use o humor imperativo na linha de assunto
  6. Envolva o corpo em 72 caracteres
  7. Use o corpo para explicar o quê e por quê vs. como

Conventional Commits para commits semânticos

A especificação definida pelo Conventional Commits é oferecer uma convenção simples para utilizar nas mensagens de commit.

Ela define um conjunto de regras para criar um histórico de commit explícito, o que facilita a criação de ferramentas automatizadas baseadas na especificação.

Esta convenção se alinha com o SemVer, descrevendo os recursos, correções e modificações que quebram a compatibilidade, tudo nas mensagens de commit.

A mensagem do commit deve ser estruturada da seguinte forma:

<tipo>[escopo opcional]: <descrição>

[corpo opcional]

[rodapé(s) opcional(is)]

Vamos entender o que cada bloco de informação significa e como deve ser preenchido.

A mensagem do commit contém os seguintes elementos estruturais, para comunicar a intenção ao utilizador da sua biblioteca:

  1. fix: um commit do tipo fix soluciona um problema na sua base de código (isso se correlaciona com PATCH do versionamento semântico).
  2. feat: um commit do tipo feat inclui um novo recurso na sua base de código (isso se correlaciona com MINOR do versionamento semântico).
  3. BREAKING CHANGE: um commit que contém no rodapé opcional o texto BREAKING CHANGE:, ou contém o símbolo ! depois do tipo/escopo, introduz uma modificação que quebra a compatibilidade da API (isso se correlaciona com MAJOR do versionamento semântico). Uma BREAKING CHANGE pode fazer parte de commits de qualquer tipo.
  4. Outros tipos adicionais são permitidos além de fix: e feat:, por exemplo @commitlint/config-conventional (baseado na Convenção do Angular) recomenda-se build:chore:ci:docs:style:refactor:perf:test:, entre outros.
  5. Outros rodapés diferentes de BREAKING CHANGE: <descrição> podem ser providos e seguem a convenção simular a git trailer format.

Observe que esses tipos adicionais não são exigidos pela especificação do Conventional Commits e não têm efeito implícito no versionamento semântico (a menos que incluam uma BREAKING CHANGE). Um escopo pode ser fornecido ao tipo do commit, para fornecer informações contextuais adicionais e está contido entre parênteses, por exemplo feat(parser): adiciona capacidade de interpretar arrays.

Referências

sim Não Sugerir edição
Última atualização em 7 de dezembro de 2021

Como corrigir GIT lento com SSH no Github, Gitlab ou Bitbucket

Para corrigir comandos GIT de push e pull lentos, quando estamos usando chaves ssh nos serviços de repositórios Github, Gitlab e Bitbucket, é necessário alterar a configuração de versão de IP utilizada.

Eu gosto de usar as conexões por HTTPS dos serviços de versionamento e repositório de códigos fonte, principalmente pela praticidade de usar os serviços em qualquer máquina sem a necessidade de criar chaves SSH para a conexão GIT.

Porém, principalmente depois de Github e Bitbucket obrigarem a interação com seus repositórios por meio de chaves ssh, em alguns momentos a velocidade de conexão virou um problema.

Nos últimos dias, experimentei conexões muito lentas ao enviar novos commits por push para o Bitbucket, principalmente, via linha de comando shell, SourceTree ou mesmo PHPStorm.

O envio de um commit com apenas um arquivo alterado estava levando 50 segundos, ou até mais, cerca de 3 minutos em alguns casos.

Depois de depurar a conexão ssh em um comando de git push, o resultado foi algo similar com o apresentado a seguir:

ssh -Tv [email protected] [...] debug1: Connecting to bitbucket.org [2401:1d80:1010::152] port 22. debug1: connect to address 2401:1d80:1010::152 port 22: Operation timed out debug1: Connecting to bitbucket.org [104.192.143.2] port 22. debug1: Connection established. [...]

Se você não está calejado com os problemas de IPv6, não saltou aos seus olhos como saltou aos meus, o problema: minha instalação git está tentando usar IPv6 ao invés de IPv4 para as conexões de transferências de dados.

Corrigindo GIT lento com SSH no Github e outros serviços

Como já afirmei no parágrafo anterior, a conexão SSH via IPV6 está levando a conexão ao um tempo limite, atingindo o timeout.

Apenas após este timeout que, em seguida, IPV4 é usado. Isso estava acontecendo a cada git commit, git pull ou git push.

Como uma solução rápida – diria definitiva, decidi desligar o IPV6 para conexões SSH.

Para realizar isso, você deve abrir o arquivo /etc/ssh/sshd_config em seu Linux Ubuntu ou Mint, e adicionar as linhas a seguir:

Host *
  AddressFamily inet

Após reiniciar a sessão, suas conexões ssh utilizarão IPv4 por padrão e a lentidão será resolvida.

Caso deseje desabilitar o uso de IPv6 nas conexões ssh em apenas alguns servidores ou serviços específicos, especifique o host como no exemplo a seguir:

Host bitbucket.org
  AddressFamily inet

Na configuração acima eu desabilitei o IPv6 em ssh apenas para os servidores do Bitbucket.

Você pode fazer o mesmo para os servidores do Github ou Gitlab. Ou ainda, para qualquer outro serviço que acesso via ssh.

Referências

Post: https://grosse.io/blog/posts/Fixing-slow-Bitbucket-git-connections-via-SSH

Imagem de destaque: Foto de invisiblepower no Pexels

sim Não Sugerir edição
Última atualização em 17 de novembro de 2021

Como configurar username e email por projeto com Git

Se você trabalha com diferentes usuários em projetos pessoais e de trabalho, é interessante configurar seu username e email no Git de maneira local, por projeto, para que seja corretamente rastreado no Github, Gitlab e Bitbucket.

Por padrão o arquivo /<users>/.gitconfig é usado para armazenar as suas configurações globais de usuário e e-mail para o Git.

Conteúdo do arquivo .gitconfig

Este é um exemplo de como um arquivo de configuração .gitconfig é composto:

[user]
	name = Ademir Mazer Junior
	email = email [at] mazer.dev
[pull]
	rebase = false
[commit]
	gpgSign = false
[gui]
	pruneduringfetch = true
[smartgit "submodule"]
	fetchalways = true
	update = true
	initializenew = true
[push]
	recurseSubmodules = check

Como você pode verificar, a tag [user]é usada para que todos os clientes Git encontrem seu username e email para configurar os push e commits.

Configurando username e email por projeto no Git

O Git oferece três possibilidades de definir seu nome de usuário e e-mail. As configurações serão consideradas na seguinte ordem, onde 1 > substituirá 2 > substituirá 3.

  1. projeto – Os dados são armazenados diretamente no projeto correspondente (repositório) em git/config.
  2. global – para todos os repositórios do usuário atual. O arquivo de configuração pode ser encontrado em seu diretório home ~/.gitconfig.
  3. sistema – Esta é uma configuração de todo o sistema e está disponível para todos os usuários e todos os repositórios. Você o encontrará nos sistemas Linux, em geral, em /etc/gitconfig.

Na maioria dos casos, você definirá uma configuração global para o usuário e, na sequência, definirá as configurações específicas de cada projeto.

Vamos verificar os três níveis de configuração, do mais abrnagente (item 3 acima) para o mais específico, o item 1 – por projeto:

Configurando username e email para todo o sistema no Git

Esta não é uma indicação tão comum nos tutoriais e cursos, mas você pode configurar para todos os usuários de um sistema operacional um username e email para o Git:

$ git config --system user.name "Nome de usuário do sistema"
$ git config --system user.email "[email protected]"

Esta portanto é a configuração global para todos os usuário de seu sistema operacional.

Configurando username e email globalmente no Git

Relembrando os comandos de configuração mais difundidos ao instalar Git:

$ git config --global user.name "Meu nome global"
$ git config --global user.email "[email protected]"

Esta é a configuração global para seu usuário de sistema operacional.

Configurando username e email no Git para um projeto específico

Por fim, esta opção sobrepõe as configurações anteriores, para cada projeto em que ela for utilizada. Similarmente às demais opções, você usara os comandos git config, dentro do diretório de seu projeto, porém, desta vez, sem utilizar o parâmetro global ou system:

# lembre-se de navegar para o raiz do projeto
$ cd pasto-do-projeto
$ git config user.name "Meu nome neste projeto"
$ git config user.email "[email protected]"

Você também pode usar a opção --local para “garantir” a configuração local.

Verificando as configurações de nome de usuário e email

Para verificar como estão as configurações utilize o comando git config com a opção --get:

$ git config --get user.name
$ git config --get user.email

Os comandos acima mostrarão as configurações locais, para verificar globalmente ou no sistema, adicione as opções --global ou --system.

Artigos de referência:

Mantenha-se atualizado

Não esqueça de me seguir no Twitter e assinar o Canal Mazer.dev no Youtube para receber atualizações de novos artigos, vídeo aulas e cursos gratuitos em desenvolvimento e engenharia de software.

Mais sobre Git, Github e Gitlab

Erro
Como resolver o “error: src refspec main does not match any”no Git

A mensagem de erro: “error: src refspec main does not match any” acontece por algumas ca…

black tablet computer on brown wooden table
Livros e-books gratuitos de programação e computação em geral

Procurando livros e-books gratuitos sobre programação, desenvolvimento de software e o…

Git logo
Git dica rápida: git checkout de arquivos específicos de outra branch

O comando git checkout pode ser usado para atualizar arquivos ou diretórios específico…

Logo Github
Criando o README do seu perfil no Github

Personalize o README do seu perfil no Github, deixe seu cartão de visitas de programador com …

Commit
Git commits semânticos

Commits semânticos no uso de Git e outros VCS (sistemas de versionamento de código), s&…

Conexão lenta git
Como corrigir GIT lento com SSH no Github, Gitlab ou Bitbucket

Para corrigir comandos GIT de push e pull lentos, quando estamos usando chaves ssh nos serviç…

sim Não Sugerir edição
Última atualização em 14 de setembro de 2021

Instalando Git no Windows, Linux e MacOS

O sistema de versionamento de software Git não vem instalado por padrão nos sistemas operacionais Linux, Windows e MacOS.

Mesmo se ele já tiver sido instalado, é uma boa ideia atualizar para a versão mais recente.

Cada um dos sistemas possui uma maneira diferente para fazer esta instalação, sendo que, por padrão, após realizada, os comandos Git ficam disponíveis por meio do terminal de comando ou console. Você pode instalá-lo como um pacote ou através de outro instalador, ou até mesmo baixar o código fonte e compilá-lo.

A seguir você verá como instalar o Git nos principais sistemas operacionais e em diferentes distribuições Linux.

Instalar Git no Windows

Existem algumas maneiras de instalar o Git no Windows. A versão mais oficial está disponível para download no site do Git.

Acesse o endereço https://git-scm.com/download/win e o download começará automaticamente. Observe que este é um projeto chamado Git para Windows, o qual é separado do próprio projeto principal doGit; para obter mais informações sobre ele, acesse a página https://gitforwindows.org.

Para baixar uma instalação automatizada, você pode usar o pacote Git Chocolatey. Observe que o pacote Chocolatey é mantido pela comunidade. Mesmo assim, cada versão de cada pacote passa por um processo de moderação rigoroso antes de ir ao ar, que normalmente inclui:

  • Segurança, consistência e verificação de qualidade
  • Teste de instalação
  • Verificação de vírus por meio do VirusTotal
  • Moderação por humanos que realizam a revisão final e as assinam

Mais uma maneira instalar o Git no Windows é através da instalação do GitHub para Windows. O instalador inclui uma versão de linha de comando do Git, bem como a GUI.

Ele também funciona bem com o PowerShell, e configura o cache de credenciais sólidas e as devidas configurações CRLF.

Em outros artigos/lições tratarei sobre credenciais e configurações CRLV

Você pode baixá-lo da página GitHub para Windows, em https://windows.github.com.

Instalar Git no Mac

Assim como no Windows, existem várias maneiras de instalar o Git em um Mac. O mais fácil é instalar as ferramentas de linha de comando Xcode.

No Mavericks (10,9) ou acima, você pode fazer isso simplesmente executando o comando `git` no Console do Terminal pela primeira vez. Caso ele não esteja instalado o sistema irá pedir-lhe para instalá-lo.

Se você quiser trabalhar com a versão mais atualizada, geralmente não disponível com a mesma velocidade nos repositórios, você pode instalá-lo usando um instalador binário.

Um instalador OSX Git é mantido e disponibilizado para download no site do Git, acesse o endereço http://git-scm.com/download/mac para baixar o instalador.

Instalador Git no MacOS

Você também pode instalá-lo como parte do instalador GitHub para Mac. Sua ferramenta GUI Git tem uma opção para instalar as ferramentas de linha de comando.

Para baixar essa ferramenta acesse a página do GitHub para Mac, em http://mac.github.com.

Instalar Git no Linux

O processo de instalação do Git no Linux / Unix geralmente é feito através da ferramenta básica de gerenciamento de pacotes que vem com sua distribuição.

Sendo o Git uma ferramenta essencial para desenvolvedores e profissionais de infraestrutura, DevOps, os pacotes para sua instalação sempre estão presentes e bem atualizados.

Fedora

Para as distribuições Linux que usam o gerenciador de pacotes yum, como o Linux Fedora por exemplo, você pode usar o o seguinte comando:

$ sudo yum install git-all

Usar yum funcionará para Fedora até a versão 21, para Fedora 22 e mais novos utilize dnf:

$ dnf install git

Debian, Ubuntu, Mint

Se você usar uma distribuição baseada em Liux Debian como o Ubuntu ou Mint, use o gerenciador de pacotes apt-get:

$ sudo apt-get install git-all

Você pode usar o seguinte repositório oficial para as versões mais recentes, deve funcionar para as três distribuições baseadas em Debian:

$ add-apt-repository ppa:git-core/ppa
$ apt update
$ apt install git

Gentoo

$ emerge --ask --verbose dev-vcs/git

Arch Linux

$ pacman -S git

OpenSUSE

$ zypper install git

Mageia

$ urpmi git

Nix/NixOS

$ nix-env -i git

FreeBSD

$ pkg install git

Solaris 9/10/11 (OpenCSW)

$ pkgutil -i git

Solaris 11 Express

$ pkg install developer/versioning/git

OpenBSD

$ pkg_add git

Alpine

$ apk add git

Red Hat Enterprise Linux, Oracle Linux, CentOS, Scientific Linux, et al.

RHEL e derivados normalmente fornecem versões mais antigas do git. Você pode baixar um tarball e compilar a partir do código-fonte ou usar um repositório de terceiros, como o IUS Community Project para obter uma versão mais recente do git.


Simples assim, executando o comando de instalação correto de sua distribuição o Git estará disponível, para testar pode verificar sua versão com o seguinte comando:

$ git --version

Mantenha-se atualizado

Não esqueça de me seguir no Twitter e assinar o Canal Mazer.dev no Youtube para receber atualizações de novos artigos, vídeo aulas e cursos gratuitos em desenvolvimento e engenharia de software.

Mais sobre GIT

Como resolver o “error: src refspec main does not match any”no Git
A mensagem de erro: "error: src refspec main does not match any" acontece por algumas causas rotineiramente comuns, principalmente ao iniciar um novo repositório de projeto. Uma segunda linha de mensagem com o texto: "error: …
Livros e-books gratuitos de programação e computação em geral
Procurando livros e-books gratuitos sobre programação, desenvolvimento de software e outras áreas de computação? Esta lista trás estes temas e ainda livros sobre engenharia de software, e outros assuntos. O período de pandemia fez explodir …
Git dica rápida: git checkout de arquivos específicos de outra branch
O comando git checkout pode ser usado para atualizar arquivos ou diretórios específicos em sua árvore de trabalho com os de outra ramificação (branch), sem que seja necessário mesclar a ramificação inteira. Isso pode ser …
Criando o README do seu perfil no Github
Personalize o README do seu perfil no Github, deixe seu cartão de visitas de programador com a "sua cara" e aumente a visibilidade e clareza de sua posição técnica na área de desenvolvimento de software. …
Git commits semânticos
Commits semânticos no uso de Git e outros VCS (sistemas de versionamento de código), são a melhor forma de documentação de execução de implementação, por conferir contexto à gestão de mudanças. Escrever mensagens de commits …
Como corrigir GIT lento com SSH no Github, Gitlab ou Bitbucket
Para corrigir comandos GIT de push e pull lentos, quando estamos usando chaves ssh nos serviços de repositórios Github, Gitlab e Bitbucket, é necessário alterar a configuração de versão de IP utilizada. Eu gosto de …
sim Não Sugerir edição
Última atualização em 14 de setembro de 2021

Git Workflow simples

Neste artigo apresento uma proposta para um fluxo de trabalho simples usando a ferramenta de gestão de versão de código fonte padrão do mercado, um Git workflow.

Para uma gestão eficiente de um projeto de desenvolvimento de software, além do uso elementar de uma ferramenta de versionamento, é importante definir uma padronização de organização para a equipe.

Git workflow simples

A imagem a seguir apresenta um diagrama que resume o trabalho regular, de forma simplificada, em um projeto de desenvolvimento com versionamento de código usando Git:

Git Workflow simples

A sequência a seguir descreve o passo a passo para este fluxo de trabalho, considerando um caminho sem a ocorrência exceções no andamento do desenvolvimento de um projeto de software:

  • Criação do repositório
$ git init
  • Commit inicial no branch master
$ git add .
$ git commit -m 'Initial commit'
  • Proteger o branch master para que não seja possível fazer push direto nele.
  • Criação do branch dev para ser utilizado pelo desenvolvimento
$ git checkout -b dev
  • Realizar os commits no branch dev
$ git add .
$ git commit -m 'Minha nova funcionalidade'

# push para o repositório central sempre que necessário
$ git push origin dev
  • Ao chegar em um momento de realizar testes para publicação da aplicação em produção, criar o branch test:
    • Caso o branch ainda não exista, crie o mesmo a partir de dev:
$ git checkout -b test
  • Fazer o merge de dev em test, enviar para o repositório central e realizar o deploy no servidor de testes
$ git checkout test
$ git merge dev
$ git push origin test
  • Se todos os testes passarem, fazer o merge de test em master, criar tag de versão, então publicar em produção
$ git checkout master
$ git merge test
$ git tag 'v.0.1.0'
$ git push origin master
$ git push --tags
  • Continuar o desenvolvimento em dev
$ git checkout dev
  • Novo ponto de estabilidade para publicação em produção, novamente fazer o merge de dev em test
$ git checkout test
$ git merge dev
  • Caso algum erro/falha seja encontrado no teste, corrigir em dev
  • Após correções, novo merge de dev em testcomandos anteriores
  • Após todos os testes serem aceitos, merge de test em master, tag de versão, publicar em produção – comandos de publicação em produção e master explicados acima
  • Continuar o fluxo de trabalho descrito

Desta maneira, consideramos que a versão em produção será sempre igual à última tag do branch master. A última versão no ambiente de testes será sempre a última entrada (HEAD) no ramo test.

Enquanto o desenvolvimento continua trabalhando no branch dev com as novas funcionalidades a serem implementadas.

Git fluxo de trabalho simples e correções de erro

Note que ainda é possível criar ramificações a partir do master caso algum erro seja identificado na versão de produção, enquanto o desenvolvimento de novas funcionalidades avançou, o diagrama a seguir exemplifica este contexto:

Git workflow simples com bugix

Portanto, quando um bugfix é necessário na versão que está rodando em produção:

  • Inicia-se um novo branch para a correção do bug, neste exemplo o branch é chamado de bugfix-0.1.0
  • Este novo branch deve ser iniciado a partir do master pois o branch dev já está com alterações que ainda não foram testadas
$ git checkout master
$ git checkout -b bugfix-0.1.0
  • Faz-se os commits necessários para a correção/alteração na branch bugfix-0.1.0
  • Testa-se, podendo ou não enviar ao branch test , neste exemplo consideramos um teste direto do bugfix
  • Faz-se o merge de bugfix para master, e também para dev, com o objetivo de não perder a correção nas versões futuras que estão em desenvolvimento
$ git add .
$ git commit -m 'Correções implementadas'

# testes realizados
$ git checkout master
$ git merge bugfix-0.1.0
$ git push origin master
$ git checkout dev
$ git merge bugfix-0.1.0
$ git push origin dev
  • Neste ponto é possível excluir o ramo de bugfix se desejado, pois as alterações terão sido incorporadas no branch dev

Considerações finais

Este é um workflow muito simples, porém que atende a projetos com equipes pequenas ou projetos onde o desenvolvimento de funcionalidades e entregas ocorre de forma “linear” ou sequencial.

Eu diria que funciona bem, principalmente, para desenvolvedores solo.

Mantenha-se atualizado

Não esqueça de me seguir no Twitter e assinar o Canal Mazer.dev no Youtube para receber atualizações de novos artigos, vídeo aulas e cursos gratuitos em desenvolvimento e engenharia de software.

Mais sobre Git

Como resolver o “error: src refspec main does not match any”no Git
A mensagem de erro: "error: src refspec main does not match any" acontece por algumas causas rotineiramente comuns, principalmente ao iniciar um novo repositório de projeto. Uma segunda linha de mensagem com o texto: "error: …
Livros e-books gratuitos de programação e computação em geral
Procurando livros e-books gratuitos sobre programação, desenvolvimento de software e outras áreas de computação? Esta lista trás estes temas e ainda livros sobre engenharia de software, e outros assuntos. O período de pandemia fez explodir …
Git dica rápida: git checkout de arquivos específicos de outra branch
O comando git checkout pode ser usado para atualizar arquivos ou diretórios específicos em sua árvore de trabalho com os de outra ramificação (branch), sem que seja necessário mesclar a ramificação inteira. Isso pode ser …
Criando o README do seu perfil no Github
Personalize o README do seu perfil no Github, deixe seu cartão de visitas de programador com a "sua cara" e aumente a visibilidade e clareza de sua posição técnica na área de desenvolvimento de software. …
Git commits semânticos
Commits semânticos no uso de Git e outros VCS (sistemas de versionamento de código), são a melhor forma de documentação de execução de implementação, por conferir contexto à gestão de mudanças. Escrever mensagens de commits …
Como corrigir GIT lento com SSH no Github, Gitlab ou Bitbucket
Para corrigir comandos GIT de push e pull lentos, quando estamos usando chaves ssh nos serviços de repositórios Github, Gitlab e Bitbucket, é necessário alterar a configuração de versão de IP utilizada. Eu gosto de …
sim Não Sugerir edição
Última atualização em 30 de agosto de 2021

O que é Git

Você conhece o conceito geral e sabe o que é o GIT? Este que é, de longe, o sistema de controle de versão moderno mais usado no mundo atualmente.

O Git é um projeto de código aberto maduro e com manutenção ativa, desenvolvido em 2005 por Linus Torvalds, o famoso criador do kernel do sistema operacional Linux.

Um número impressionante de projetos de software depende do Git para controle de versão, incluindo projetos comerciais e de código-fonte aberto (open-source).

Os desenvolvedores que trabalharam com o Git estão bem representados no pool de talentos de desenvolvimento de software disponíveis e funcionam bem em uma ampla variedade de sistemas operacionais e IDEs (Ambientes de Desenvolvimento Integrado).

A base da arquitetura de GIT é distribuída, ele é um exemplo de DVCS (sigla que em português significa Sistema de Controle de Versão Distribuído).

Basicamente, ao invés de existir apenas um único local para o histórico completo da versão do software, como é comum em sistemas de controle de versão centralizados, outrora populares, como CVS ou Subversion (também conhecido como SVN), no Git, a cópia de trabalho de todo desenvolvedor também é um repositório que pode conter o histórico completo de todas as alterações. Além de ser distribuído, o Git foi projetado para apresentar alto desempenho, segurança e flexibilidade.

Para saber mais sobre estas diferenças de tipos de sistemas de controle de versão, leia o artigo com a e a vídeo aula: O que é controle de versão.

Características do GIT

Desempenho

As características de desempenho do Git são extremamente altas quando comparadas a outros sistemas de controle de versão.

Fazer o commit de novas alterações, criar branches, mesclar diferentes ramos e realizar comparação de versões – tudo é otimizado para desempenho. Os algoritmos implementados no Git aproveitam o conhecimento profundo sobre atributos comuns de árvores de arquivos de código-fonte reais, como costumam ser modificados ao longo do tempo e quais são os padrões de acesso.

Leia também

– o artigo Git Básico para os comandos mais comuns no uso de Git
– o artigo Git workflow simples para um fluxo de trabalho inicial

Diferente de alguns softwares de controle de versão, o Git não erra ao gerenciar pelos nomes dos arquivos ao determinar qual deve ser o armazenamento e o histórico de versões da árvore de arquivos. Em vez disso, o Git trabalha no conteúdo do arquivo.

Os arquivos de código-fonte são renomeados, divididos e reorganizados com frequência. O formato do objeto dos arquivos de repositório do Git usa uma combinação de codificação delta (armazenamento de diferenças de conteúdo) e compactação e armazena com clareza o conteúdo do diretório e os objetos de metadados da versão. Isto significa que apenas as porções alteradas do conteúdo de um arquivo são armazenadas em uma nova versão.

A distribuição também oferece benefícios significativos de desempenho.

Por exemplo, digamos que uma desenvolvedora, Agnes, faça alterações no código-fonte, adicionando um recurso para a próxima versão, 2.0, e faça o commit dessas alterações com mensagens descritivas.

Ela então trabalha em um segundo recurso e faz o commit dessas alterações também. Como esperado, eles são armazenados como elementos de trabalho separadas no histórico de versões.

Agnes então muda para o branch da versão 1.3 do mesmo repositório de software para corrigir um erro que afeta apenas a versão mais antiga.

O objetivo disso é permitir que a equipe de Agnes lance uma versão de correção de bug, a versão 1.3.1, antes que a versão 2.0 esteja pronta.

Agnes pode retornar ao branch 2.0 para continuar trabalhando nos novos recursos da versão 2.0, fazendo tudo isso sem nenhum acesso à conteúdo disponível na rede e, sendo um processo rápido e confiável no seu repositório local. Ela poderia até fazer isso em um local sem acesso à internet.

Quando estiver pronta para fazer o commit de todas as alterações como itens individuais, enviando-os ao repositório remoto, Agnes vai poder fazer um “push” em um único comando.

Segurança

O Git foi projetado com a integridade do código-fonte gerenciado como uma prioridade. O conteúdo dos arquivos, bem como os relacionamentos entre arquivos e diretórios, versões, tags e commits, todos esses objetos no repositório do Git são protegidos com um algoritmo de hash de criptografia seguro chamado SHA1.

Isto protege o código e o histórico de alterações contra alterações acidentais e maliciosas e garante que o histórico tenha rastreabilidade total.

Com o Git, você pode ter a certeza de poder acessar um histórico de conteúdo autêntico do código-fonte.

Alguns outros sistemas de controle de versão não têm proteções contra alterações secretas posteriores. Isso pode ser uma vulnerabilidade séria de segurança das informações para qualquer empresa que depende do desenvolvimento de software.

Flexibilidade

Um dos principais objetivos de design do Git é a flexibilidade. Ele foi construído para ser flexível em vários aspectos:

  • suporte a vários tipos de fluxos de trabalho de desenvolvimento não lineares,
  • em eficiência em projetos pequenos e grandes
  • e em compatibilidade com muitos sistemas e protocolos existentes.

O Git foi projetado para tratar os branches e tags como cidadãos de primeira classe (ao contrário do SVN) e operações que afetam branches e tags (como mesclagem ou reversão) também são armazenadas como parte do histórico de alterações.

Nem todos os sistemas de controle de versão apresentam esse nível de rastreamento.

Controle de versões com Git

Atualmente, o Git é a melhor escolha para a maioria das equipes de desenvolvimento de software para realizar versionamento de software.

Embora cada equipe seja diferente e deva realizar a própria análise, uma série de motivos pelos quais o controle de versão com Git é preferido pode ser apresentada:

O Git é bom

Pode parecer uma afirmativa arbitrária, mas Git tem a funcionalidade, desempenho, segurança e flexibilidade que a maioria das equipes e desenvolvedores individuais precisa. Esses atributos do Git foram explicados acima. Nas comparações lado a lado com a maioria das outras alternativas, muitas equipes acham o Git favorável em relação à elas.

Git é um padrão de fato

Sendo a ferramenta mais adotada da categoria torna o Git atraente pelos motivos que seguem:

  • Um grande número de desenvolvedores já tem experiência com o Git e uma proporção significativa de recém-formados pode acabar por ter experiência apenas com ele na universidade. Embora algumas empresas precisem escalar a curva de aprendizado ao migrar para o Git de outro sistema de controle de versão, muitos desenvolvedores existentes e futuros não precisam ser treinados nele.
  • Além dos benefícios de uma grande oferta de profissionais que o conheçam, a predominância do Git também significa que muitas ferramentas e serviços de software de terceiros já estão integrados ao Git, incluindo IDEs e novas ferramentas de uso. Alguns exemplos são o cliente de desktop DVCS Sourcetree, software de rastreamento de projetos, Jira, serviços de hospedagem de código como Github, Gitlab e Bitbucket.
  • Se você é um desenvolvedor inexperiente que quer desenvolver habilidades valiosas em ferramentas de desenvolvimento de software, quando se trata de controle de versão, o Git deve ser uma das suas prioridades na lista.

Git é um projeto de código aberto de alta qualidade

O Git é um projeto de código aberto com amplo suporte da comunidade, com mais de uma década de administração sólida.

  • Os mantenedores do projeto demostraram gerenciamento equilibrado e abordagem madura para atender às necessidades de longo prazo dos usuários, com lançamentos regulares que melhoram a usabilidade e a funcionalidade. É fácil examinar a qualidade do software de código aberto, e inúmeras empresas dependem muito dessa qualidade para decidirem por sua adoção.
  • O Git tem excelente suporte da comunidade e uma ampla base de usuários. A documentação é de alta qualidade e abundante, incluindo livros, tutoriais e sites dedicados. Existem também podcasts e tutoriais em vídeo.
  • O código aberto reduz o custo para desenvolvedores amadores, pois eles podem usar o Git sem pagar por ele. Para uso em projetos de código aberto, o Git é sem dúvida o sucessor das gerações anteriores de sistemas bem-sucedidos de controle de versão de código aberto como SVN e CVS.

Resumo do artigo

  1. Git tem uma posição atual de ampla adoção no desenvolvimento de software
  2. Ele apresenta alta qualidade de código, tendo como características principais: segurança, desempenho e flexibilidade
  3. A gestão de seu próprio projeto é um exemplo de equilíbrio e garantia para que empresas o adotem como sua ferramenta de versionamento de código.

Agora que você entende o que é o controle de versão, o que é o Git e por que as equipes de software deveriam optar por ele, continue lendo para descobrir os benefícios que o Git pode oferecer em toda a empresa.

Mantenha-se atualizado

Não esqueça de me seguir no Twitter e assinar o Canal Mazer.dev no Youtube para receber atualizações de novos artigos, vídeo aulas e cursos gratuitos em desenvolvimento e engenharia de software.

Mais sobre GIT

Como resolver o “error: src refspec main does not match any”no Git
A mensagem de erro: "error: src refspec main does not match any" acontece por algumas causas rotineiramente comuns, principalmente ao iniciar um novo repositório de projeto. Uma segunda linha de mensagem com o texto: "error: …
Livros e-books gratuitos de programação e computação em geral
Procurando livros e-books gratuitos sobre programação, desenvolvimento de software e outras áreas de computação? Esta lista trás estes temas e ainda livros sobre engenharia de software, e outros assuntos. O período de pandemia fez explodir …
Git dica rápida: git checkout de arquivos específicos de outra branch
O comando git checkout pode ser usado para atualizar arquivos ou diretórios específicos em sua árvore de trabalho com os de outra ramificação (branch), sem que seja necessário mesclar a ramificação inteira. Isso pode ser …
Criando o README do seu perfil no Github
Personalize o README do seu perfil no Github, deixe seu cartão de visitas de programador com a "sua cara" e aumente a visibilidade e clareza de sua posição técnica na área de desenvolvimento de software. …
Git commits semânticos
Commits semânticos no uso de Git e outros VCS (sistemas de versionamento de código), são a melhor forma de documentação de execução de implementação, por conferir contexto à gestão de mudanças. Escrever mensagens de commits …
Como corrigir GIT lento com SSH no Github, Gitlab ou Bitbucket
Para corrigir comandos GIT de push e pull lentos, quando estamos usando chaves ssh nos serviços de repositórios Github, Gitlab e Bitbucket, é necessário alterar a configuração de versão de IP utilizada. Eu gosto de …
sim Não Sugerir edição
Última atualização em 2 de setembro de 2021

Cache temporário das credenciais GIT - username e password

Existem situações em que você precisa trabalhar com um repositório GIT usando o protocolo HTTPs e não pode armazenar permanentemente as credenciais de usuário na configuração local. Uma solução é armazenar em um cache temporário as credenciais (username e password – senha) por um tempo limitado.

git-credential-cache é o auxiliar que vamos usar para armazenar temporariamente as senhas na memória.

Veja também como definir o autor de um comando Git para uma única execução do comando nesta dica rápida, ou ainda Como configurar username e email por projeto com Git.

O comando git-credential-cache

git config credential.helper 'cache [<options>]'

Descrição

Este comando armazena credenciais na memória para uso por um determinado tempo do programa Git.

As credenciais armazenadas nunca são armazenadas em disco, sendo esquecidas após um tempo limite configurável.

O cache pode ser acessado por meio de um soquete de domínio Unix, restrito ao usuário atual por permissões do sistema de arquivos.

Options

Algumas opções estão disponíveis no uso do comando:

--timeout

Especifica o tempo em segundos para armazenar as credenciais em cache. O valor padrão é 900 o equivalente a 15 minutos.

--socket <path>

Use a opção socket especificando o path (caminho em disco) para contatar um daemon de cache em execução, ou inicie um novo daemon de cache se não tiver sido iniciado.

O padrão é $XDG_CACHE_HOME/git/credential/socket, a menos que ~/.git-credential-cache/ exista, se existir o caminho ~/.git-credential-cache/socket é usado no lugar.

Se o seu diretório pessoal estiver em um sistema de arquivos montado em rede, pode ser necessário alterá-lo para um sistema de arquivos local.

Ao utilizar esta opção você deve especificar um caminho absoluto.

Controlando o daemon

Se desejar que o daemon encerre antes do tempo configurado, esquecendo assim todas as credenciais em cache antes de seu tempo limite, você pode utilizar um comando de saída:

git credential-cache exit

Exemplos

O objetivo em utilizar esse helper é diminuir a quantidade de vezes que precisará digitar usuário e senha em um espaço de tempo curto, por exemplo, quando está fazendo ajustes de deploy em um servidor de testes.

Confira o exemplo de uso a seguir

git config credential.helper cache
git push https://gitlab.com/palavrasagrada.git
Username: <seu nome de usuário>
Password: <sua senha>

[passados 5 minutos]

git push https://gitlab.com/palavrasagrada.git
[Suas credenciais em cache serão utilizadas automaticamente dentro do prazo limite]

Neste exemplo de atualização do site Bíblia Palavra Sagrada, o desenvolvedor chamou o helper credential.helper cache antes de realizar o primeiro push.

Na primeira interação com o repositório, o GIT solicita que o usuário e senha sejam fornecidos, o desenvolvedor executa normalmente digitando-os.

Passados 5 minutos de trabalho no código-fonte, um novo push será executado pelo desenvolvedor, porém, desta vez as credenciais armazenadas em cache são utilizadas sem que seja necessário digitar usuário e senha novamente.

Isto acontecerá pelo prazo de 15 minutos padrão do helper.

Para aumentar o tempo limite é possível utilizar a opção --timeout fornecendo os segundos:

$ git config credential.helper 'cache --timeout=3600'

No exemplo acima o tempo definido será de 1 hora.

Mantenha-se atualizado

Não esqueça de me seguir no Twitter e assinar o Canal Mazer.dev no Youtube para receber atualizações de novos artigos, vídeo aulas e cursos gratuitos em desenvolvimento e engenharia de software.

Mais sobre GIT, Github e Gitlab

Como resolver o “error: src refspec main does not match any”no Git
A mensagem de erro: "error: src refspec main does not match any" acontece por algumas causas rotineiramente comuns, principalmente ao iniciar um novo repositório de projeto. Uma segunda linha de mensagem com o texto: "error: …
Livros e-books gratuitos de programação e computação em geral
Procurando livros e-books gratuitos sobre programação, desenvolvimento de software e outras áreas de computação? Esta lista trás estes temas e ainda livros sobre engenharia de software, e outros assuntos. O período de pandemia fez explodir …
Git dica rápida: git checkout de arquivos específicos de outra branch
O comando git checkout pode ser usado para atualizar arquivos ou diretórios específicos em sua árvore de trabalho com os de outra ramificação (branch), sem que seja necessário mesclar a ramificação inteira. Isso pode ser …
Criando o README do seu perfil no Github
Personalize o README do seu perfil no Github, deixe seu cartão de visitas de programador com a "sua cara" e aumente a visibilidade e clareza de sua posição técnica na área de desenvolvimento de software. …
Git commits semânticos
Commits semânticos no uso de Git e outros VCS (sistemas de versionamento de código), são a melhor forma de documentação de execução de implementação, por conferir contexto à gestão de mudanças. Escrever mensagens de commits …
Como corrigir GIT lento com SSH no Github, Gitlab ou Bitbucket
Para corrigir comandos GIT de push e pull lentos, quando estamos usando chaves ssh nos serviços de repositórios Github, Gitlab e Bitbucket, é necessário alterar a configuração de versão de IP utilizada. Eu gosto de …
sim Não Sugerir edição
Última atualização em 14 de setembro de 2021

Git - Dicas Rápidas

Em qualquer ferramenta utilizada e mesmo dominada no dia-a-dia, seja em desenvolvimento de software, ou qualquer outra área, sempre vai apresentar um conjunto de opções, comandos ou características que são extremamente úteis, porém necessitam ser consultados com dicas rápidas todas as vezes que é necessária sua utilização, Git não é uma exceção.

Este artigo tem o objetivo de ser atualizado com frequência com dicas rápidas no uso do software de controle de versão Git, demonstrando, e lembrando, comandos usados com frequência não tão alta quanto commit ou push, e que sempre necessitam de uma consulta no manual ou tutorial.

Veja também como armazenar temporariamente em cache as credenciais de usuário e senha para acesso a um repositório no artigo: Cache temporário das credenciais GIT – username e password

Se precisa de uma visão rápida e geral do uso de Git, que é uma ferramenta de versionamento de software, leia o artigo Git Básico.

Dicas

Definir autor para um comando específico

Ocasionalmente quando você está trabalhando em um servidor remoto, de ambiente de desenvolvimento ou stage, não é incomum realizar alterações e ter a necessidade de aplicar um commit ou stash com o seu nome de autor.

Porém, nem sempre estes ambientes estão com o autor configurado, ou, como boa prática, não devem ter um autor único configurado no Git globalmente, ou ainda, você está em um ambiente de outro autor configurado.

Para identificar-se na ação desejada, sem necessitar alterar a configuração global do Git, é possível passar na linha de execução o autor e e-mail para aquele comando específico.

Por exemplo, imagine que realizou um teste em um arquivo no ambiente de stage, verificou que a alteração de código resolve um problema, e agora irá realizar o fluxo correto, alterando em ambiente dev, remetendo para revisão e aprovação, para posterior implantação nos devidos ambientes.

Porém não deve deixar a alteração direta no servidor, e deve reverter o estado do código usando o comando stash. Para identificar-se neste único comando, utilize o parâmetro -c seguido da configuração desejada:

git -c "user.name=Ademir Mazer Junior" -c "[email protected]" stash

Portanto, ao utilizar o parâmetro -c e as configurações de nome e email, para este comando específico a informação será identificada com esta configuração, sem alterar a global.

Pode ser usado com outros comandos.

Mantenha-se atualizado

Não esqueça de me seguir no Twitter e assinar o Canal Mazer.dev no Youtube para receber atualizações de novos artigos, vídeo aulas e cursos gratuitos em desenvolvimento e engenharia de software.

Mais sobre GIT, Github e Gitlab

Como resolver o “error: src refspec main does not match any”no Git
A mensagem de erro: "error: src refspec main does not match any" acontece por algumas causas rotineiramente comuns, principalmente ao iniciar um novo repositório de projeto. Uma segunda linha de mensagem com o texto: "error: …
Livros e-books gratuitos de programação e computação em geral
Procurando livros e-books gratuitos sobre programação, desenvolvimento de software e outras áreas de computação? Esta lista trás estes temas e ainda livros sobre engenharia de software, e outros assuntos. O período de pandemia fez explodir …
Git dica rápida: git checkout de arquivos específicos de outra branch
O comando git checkout pode ser usado para atualizar arquivos ou diretórios específicos em sua árvore de trabalho com os de outra ramificação (branch), sem que seja necessário mesclar a ramificação inteira. Isso pode ser …
Criando o README do seu perfil no Github
Personalize o README do seu perfil no Github, deixe seu cartão de visitas de programador com a "sua cara" e aumente a visibilidade e clareza de sua posição técnica na área de desenvolvimento de software. …
Git commits semânticos
Commits semânticos no uso de Git e outros VCS (sistemas de versionamento de código), são a melhor forma de documentação de execução de implementação, por conferir contexto à gestão de mudanças. Escrever mensagens de commits …
Como corrigir GIT lento com SSH no Github, Gitlab ou Bitbucket
Para corrigir comandos GIT de push e pull lentos, quando estamos usando chaves ssh nos serviços de repositórios Github, Gitlab e Bitbucket, é necessário alterar a configuração de versão de IP utilizada. Eu gosto de …
sim Não Sugerir edição
Última atualização em 19 de agosto de 2021

Diferença de TAG e BRANCH em GIT

As ferramentas de versionamento de software adotam, em geral, as nomenclaturas dos conceitos de suas áreas de aplicação. Dois conceitos frequentemente encontrados, porém com pequenas diferenças de aplicação conceitual nos softwares de controle de versão são: TAG e BRANCH.

Para esclarecer seu uso, pergunto, você saberia dizer qual a diferença conceitual e de usabilidade de TAG e BRANCH em GIT?

Resposta curta:

  • a tagetiqueta em Inglês,é apenas uma marcação, em geral, dentro de um branch específico que define uma situação em um determinado momento.
  • o branchramo em Inglês, tradicional é uma ramificação, ou organização experimental, em paralelo a outro(s) ramo(s) que potencialmente será incorporado ao desenvolvimento principal, ou melhor especificando, ao branch principal.

A tag costuma marcar um releaselançamento em Inglês, uma versão ou outro marco do projeto similar. Então a tag é apenas um apontador para um commit específico enquanto que um branch é um caminho, um galho de desenvolvimento.

A tag é apenas um nome que se dá para um estado do desenvolvimento. Desta forma torna-se fácil acessar aquele estado sempre que necessário.

No Git não há “custo” em definir uma tag, elas são uma marcação simbólica e não ocupam espaço no repositório. Você não altera o que está na tag. Ela será usada eventualmente, quando há algum evento importante no desenvolvimento que necessite desta marcação para voltar nela outras vezes. Normalmente este evento é um release.

O trabalho de desenvolvimento sempre é realizado em cima de branches através dos commits.

É no branch que se faz o mergemesclagem, do estado / alterações anteriores com o que foi desenvolvido “agora”.

Um branch vai sendo acrescido de evoluções do desenvolvimento.

Uma boa prática é a criação de um novo branch, sempre que possível, quando uma nova linha de desenvolvimento vai ser iniciada.

A imagem a seguir mostra visualmente o histórico de um repositório Git com suas Tags e Branches:

Git History

Pode-se também definir um branch como uma ramificação da sua “árvore” principal de desenvolvimento, geralmente criado para se trabalhar no desenvolvimento de correções ou novas implementações.

Ao ser finalizado o trabalho para aquele contexto, podemos fazer um merge para a ramificação principal do seu projeto.

O branch fica com a responsabilidade de receber as modificações – commits, durante o contexto do desenvolvimento, a cada nova funcionalidade é aconselhável gerar novas branches. Quando o projeto já está maduro e estável é gerada uma nova release que será armazenada ou marcada por uma TAG do repositório.

Após compreender a diferença entre Tag e Branch no Git, mas se você não conhece os comandos básicos e diários de trabalho com o ele, como commit, add, clone; leia o seguinte post: Git Básico.

Se possui alguma dúvida ou necessita de ajuda com seu trabalho com Git, deixe um comentário.

Mantenha-se atualizado

Não esqueça de me seguir no Twitter e assinar o Canal Mazer.dev no Youtube para receber atualizações de novos artigos, vídeo aulas e cursos gratuitos em desenvolvimento e engenharia de software.

sim Não Sugerir edição
Última atualização em 30 de agosto de 2021
Help Guide Powered by Documentor
Sugerir edição

pt_BRPortuguese