Artigo do BLOG

Guia prático de Git para iniciantes

Olá, Maycon aqui novamente. Dessa vez para inaugurar a seção do blog “Café com Código”.

Fiquei pensando sobre qual seria o primeiro tema abordado aqui… e escrevendo o último post “Sopa de Letrinhas” veio a ideia de falar sobre o Git, essa ferramenta tão importante e que me ajudou a conquistar uma excelente vaga de estágio. Então, aqui vamos nós.

Afinal, o que é Git e por que ele é tão importante?

Git é um sistema de controle de versões distribuído, usado pela maioria esmagadora de empresas do ramo de tecnologia e desenvolvimento de software. Foi projetado inicialmente pelo Mestre Louva-a-Deus Linus Torvalds, para o desenvolvimento do kernel Linux; mas é um programa de código aberto (open-source). Basicamente, através do Git, uma equipe de desenvolvimento consegue rastrear alterações no código e manter de maneira eficiente o controle de versão.

Existem outros programas que fazem trabalho, mas o Git é de longe a solução mais usada no mercado. Independente se você irá trabalhar com front-end ou back-end, saber o básico de Git é sem dúvida uma competência fundamental, que deve ser desenvolvida e aprimorada desde o início da sua carreira.

Diferença entre Git, Github e Gitlab

Tanto o GitHub quanto o GitLab são sites onde você pode fazer o upload dos seus projetos git. São os dois mais famosos do mercado. Então, para ficar mais claro: o git é a ferramenta utilizada para versionar projetos, enquanto o GitHub e o GitLab são interfaces, sites onde você pode colocar seus projetos versionados.

Tanto o GiHub quanto o GitLab possuem versões gratuitas e versões pagas, com funcionalidades distintas. Aconselho você a criar uma conta no GitLab para seguir este tutorial. É bem simples e rápido.

Começando pelo essencial

A ideia deste post é dar um ponta pé inicial nos seus conhecimentos sobre git, sem ter nenhuma pretensão de encerrar o assunto ou abordar tudo que o ele compreende. Mas, para quem ainda nunca se aventurou com esta solução open-source, tenho certeza que o que mostrarei aqui será de grande valia. O pré-requisito é ter criado uma conta no GitLab. Após isso, seguiremos os seguintes passos:

Abordaremos aqui:

  • Criando um projeto no GitLab;
  • Ciclo de vida dos arquivos;
  • Instalação e configuração;
  • Inicializando o repositório do projeto;
  • Ciclo de vida dos status dos arquivos;
  • Criação de uma conta no GitLab;
  • Criando o primeiro repositório local;
  • Vinculando o repositório local ao repositório remoto no GitLab;
  • Fazendo o primeiro commit e o primeiro push.

Instalação e Configuração

Instalar o git é bem simples e prático. Você pode conferir na página oficial do Git agravés deste link: https://git-scm.com/downloads

Basicamente, se você usa Windows, é só baixar o instalador e clicar next, next e sucesso! No Linux normalmente já vem instalado por padrão. Caso contrário, pode executar esse comando no terminal:

$ apt-get install git;

Agora, você irá configurar as informações que serão utilizadas em todos os repositórios futuros. Por isso, deverá definir user name e e-mail globais, através desses comandos:

$ git config --global user.name "<seu nome>"
$ git config --global user.email "<seu email>"

Se der tudo certo, não aparecerá nenhum erro no seu terminal. Opcionalmente, você pode definir o editor padrão que será usado quando for realizar um commit, por exemplo. Para isso, utilize o comando:

## utilize essa opção para usar o nano. Esse é o que eu uso no dia a dia
$ git config --global core.editor nano

Essas são as configurações mais básicas. Se você quiser ver outras opções de configuração, pode utilizar o comando:

$ git config --list

Criando projeto no GitLab

Vamos criar nosso projeto dentro do GitLab. Para isso, na sua página inicial do GitLab, clique no botão “New Project” situado no canto superior direito.

Em seguida, preencha as informações básicas do projeto, como nome, descrição e visibilidade. No meu caso, optei por deixá-lo público, e não cliquei no checkbox de inicializar o Readme. Este arquivo é muito importante, pois ele fica em evidência na página do seu projeto e serve como uma porta de entrada. Não abordarei aqui sobre o que escrever exatamente no Readme, mas vale a pena dar uma pesquisada sobre este assunto. Apenas deixei ele de fora porque irei justamente criar este arquivo dentro do nosso tutorial.

Com o projeto criado mas sem nenhum arquivo, o próprio GitLab irá mostrar uma série de instruções de linha de comando úteis. Mesmo não entrando no mérito de cada uma delas aqui, vale a pena dar uma olhada com atenção. Uma dessas instruções iremos usar logo mais mais neste guia:

Inicializando o repositório do projeto na nossa máquina local

Agora, com as configurações iniciais setadas e nosso projeto criado no GitLab, vamos inicializar o git no nosso repositório local. Então, crie ou vá até uma pasta que você destinará para o projeto que irá versionar. No meu caso, eu criei uma pasta chamada git-basico. Na pasta desejada, você deve rodar o comando:

$ git init

Ele será o responsável por iniciar e enxegar o repositório, rastreando todas as mudanças que você efetuar dentro dessa pasta. Se você reparar, será criado automaticamente uma pasta .git (possível visualizar utilizando o comando $ ls -la no linux). Dentro desta pasta ficará armazenado algumas informações sobre o repositório, branches etc. Não iremos nos aprofundar nessas informações neste momento. Mas, agora o git já está visualizando e acompanhando todos os arquivos e modificações neste seu projeto.

Cliclo de vida dos status dos arquivos

O git possui um ciclo de vida dos arquivos com 4 status: untracked, unmodified, modified e staged. Esta imagem é bem explicativa sobre como funciona:

É bem simples de entender como cada um funciona. O untracked (ou não marcado) refere-se aos arquivos que foram recém adicionados no projeto/repositório, e que o git não conhece nenhuma versão deles. A partir do momento que você adiciona o arquivo, o git começa a enxergar a versão inicial dele e irá considerar realmente como “primeira versão”, passando para o status unmodified (não modificado). Na medida em que você faz as alterações neste arquivo, ele passa para o status modified (modificado). Depois de fazer as alterações pertinentes, você deverá adicioná-lo no stage. Isso quer dizer que o git saberá da modificação feita, mas que não é permanente no repositório. O próximo commit que você fizer incluirá todos os arquivos que estão no stage.

Muita informação? Ficou um pouco confuso? Fique tranquilo que vamos ver tudo isso na prática.

Fazendo o primeiro commit

Na pasta que você criou para o repositório, digite o comando:

$ git status

Como não colocamos nenhum arquivo ainda, você deve ver uma mensagem muito parecida com essa:

A mensagem também informa que estamos no branch master, que não temos nenhum commit e que também não temos nenhum arquivo para “commitar”. Em seguida, crie um arquivo de exemplo qualquer. No meu caso, criei um arquivo chamado Readme.md com uma linha escrita “# Guia Básico de Git”. Ao executar novamente o comando $ git status, você perceberá algumas alterações:

Como é possível ver, nosso arquivo está no primeiro status mencionado acima, o untracked. Ele acabou de ser criado, mas o git ainda não o conhece. Para que o git consiga exergá-lo, devemos utilizar o comando:

$ git add Readme.md

Visualizando o status novamente, podemos perceber que ele estará já no staged, pois está pronto para ser “commitado”:

Se editarmos o arquivo antes do commit e verificarmos o status, veremos algo parecido com isto:

Como é possível ver, o arquivo Readme.md ainda tem uma versão que está no stage, pronta para o commit. Mas, existe uma versão dele que está no status modified, e que não está no staged. Se quisermos levar essas alterações para o commit, devemos repetir o comando $ git add Readme.md , onde a última versão estará no stage e ficará pronta para o commit.

Chegou a hora do commit. Já fiz menção dele algumas vezes, mas não expliquei exatamente do que se trata. O commit nada mais é do que pegar todos os arquivos que estão no stage e fazer um “snapshot”, uma versão. Para realizar o commit, basta digitar o comando:

# git commit -m "<mensagem>"

No meu caso, coloquei na mensagem “Commit Inicial”. É sempre importante colocar nos comentários o que você de fato fez, como “adicionou uma nova funcionalidade”, “corrigiu um bug”, etc. Ficou assim:

# git commit -m "Commit Inicial"

Fazendo o primeiro push para o GitLab

Agora temos nosso arquivo com sua última versão rastreada pelo git. Contudo, ele ainda está na nossa máquina. Para podermos subí-lo no nosso repositório no GitLab, nós devemos primeiro vincular nosso repositório local com o repositório remoto. Como mencionei anteriormente, o GitLab já havia dito qual o comando que deve ser utilizado para fazer isso lá na nossa página do projeto. A instrução é a seguinte:

$ git remote add origin git@gitlab.com:mayconb2/guia-git-iniciante.git

Você pode conferir se deu tudo certo através do comando:

$ git remote -v

Você deverá ver algo como isto:

Agora, iremos fazer o “push” dos arquivos prontos do nosso repositório local para o repositório remoto. Para isso, utilize este comando:

$ git push origin master

Neste comando, “origin” se refere ao repositório remoto e o “master” à branch onde foi feito o commit. Se visualizarmos novamente o nosso projeto no GitLab, veremos que agora ele já irá conter o arquivo Readme.md, na nossa branch master, e a mensagem do nosso commit:

That’s all, folks!

Ufa! Foi bastante conteúdo, mas espero que você tenha gostado.

Fazendo uma pequena recapitulação: neste guia nós aprendemos um pouco mais sobre o git, sobre o ciclo de vida dos stauts, e também a criar um repositório local e outro no GitLab, transferindo arquivos da nossa máquina para o nosso projeto do GitLab.

Gostaria de reforçar mais uma vez que eu abordei assuntos mais básicos, sem a pretensão de abordar tudo o que está relacionado ao Git. Com estas instruções, pelo menos já é possível subir alguns projetos, como seu portfólio, para o GitLab, ou mesmo, para o GitHub, que adotaria praticamente o mesmo procedimento. Em um segundo momento irei escrever sobre como trabalhar com diversas branches no mesmo projeto! (aguardem e confiram)

Espero que tenham gostado. Se você acha que algum ponto ficou confuso ou que eu deveria abordar algo não contemplado neste artigo, deixe um comentário. Ficarei feliz em saber sua opinião. Por último, se conhece alguém que está iniciando em programação ou sabe pouco sobre git, compartilhe este artigo com ele. Até a próxima!

Share on linkedin
LinkedIn
Share on facebook
Facebook
Share on whatsapp
WhatsApp
Share on email
Email
Sobre o Autor
Nossos Colunistas