16 de mar de 2018

Tutorial para iniciantes em Git e GitHub: faça seu primeiro commit

Matthew Setter

Git e GitHub são duas ferramentas muito interessantes para os desenvolvedores. O Git, apesar de sua complexidade, é a ferramenta de controle de versão favorita da maioria dos profissionais, de web designers a desenvolvedores kernel.

Já o GitHub é a plataforma de hospedagem de código mais utilizada do mundo e onde você encontrará de tudo, de experimentos lúdicos e simples ao próprio kernel do Linux.

Ambas as ferramentas são extremamente sofisticadas, proporcionando uma vasta gama de funcionalidades. E, para extrair o máximo de cada uma, é preciso estar preparado para as complexidades que se apresentarão pelo caminho.

Leia: Por que todo profissional deve aprender programação?

Como usar o Git

O Git é um sistema de controle de versão de arquivos e, antes de abordar mesmo conceitos básicos de GitHub, é importante entender como funciona esse repositório local.

Fundamentos de Git

Passo 1

Antes de qualquer coisa, é preciso que você instale algumas coisas, como a versão mais recente de Git para o seu sistema operacional. Se estiver usando o Linux, você poderá instalá-la usando seu gerenciador de pacotes.

Passo 2

É preciso que você esteja minimamente familiarizado com a utilização da linha de comando. Caso ainda não esteja, tudo bem: este artigo trata tudo de forma clara e simples.

Passo 3

Crie um repositório simples, composto por um arquivo de código e um README. Certifique-se de ter um diretório reservado para isso.

Com tudo preparado, agora vamos passar para um conjunto padrão de ações que você costuma seguir diariamente – mais especificamente, init, clone, add, commit, diff e log.

Começando um repositório

O primeiro passo para trabalhar com o Git é inicializar um repositório de projeto para que o próprio Git possa gerenciá-lo. Para isso, execute o comando git init . como demonstrado abaixo.

Um novo diretório oculto chamado .git surgirá no diretório de seu projeto. Nesse local, o Git armazena seus conjuntos de dados e informações de configuração.

Clonando um repositório

Esta é uma maneira alternativa de acessar um repositório: clonando. Semelhante à verificação de um repositório em outros sistemas, executar a função git clone < repository URL > criará uma cópia completa do repositório remoto em seu sistema local. Agora, você pode modificá-lo da maneira que quiser.

Leia: Ele trocou a engenharia de software por data science

Adicionando um novo arquivo

Eu sou um desenvolvedor PHP, então utilizarei essa ferramenta para o tutorial. Se preferir utilizar o Python, Go ou alguma outra linguagem, fique à vontade. Crie um novo arquivo, chamado index.php, no diretório de seu projeto e adicione o seguinte código:

<?php print "Hello World";

Salve o arquivo e execute o comando git status. Isso exibirá o status atual de seu repositório, que, por sua vez, deve ser semelhante à captura de tela abaixo, com index.php listado como um novo arquivo não rastreado.

Vamos ver como você opera com vários arquivos, sem comprometer todos eles. Crie um segundo arquivo chamado README.md. Adicione algumas informações, como o nome do projeto, seu nome e seu e-mail. Execute novamente git status e você verá os dois arquivos listados como não rastreados, conforme abaixo:

Agora, vamos focar apenas no index.php e deixar o README.md de lado, por enquanto. Para isso, execute o comando git add index.php. Em seguida, execute git status novamente e você verá index.php listado como um novo arquivo ““Changes to be committed,” e README.md dentre os arquivos não rastreados.

Atualizando a configuração do Git

Agora você está pronto para o commit index.php. Antes disso, quero mostrar como configurar o editor que o Git utilizará quando você escrever mensagens de commit. Isso pode ser muito útil, especialmente se você não for um usuário de linha de comando.

Por padrão, o Git usa o programa especificado nas variáveis ​​de ambiente $ VISUAL ou $ EDITOR que, em sistemas Linux, normalmente são pico, vi, vim ou emacs. Se não está familiarizado com isso, talvez seja melhor migrar para uma ferramenta que já conheça, como o Notepad, TextEdit, or Gedit.

Para isso, execute o seguinte comando:

git config --global core.editor <nome do seu app>

Existem muitas outras mudanças de configurações possíveis, como seu nome ou e-mail, o padrão visual da mensagem de commit, etc. Para ver a lista completa, entre na seção de configuração do Git. Para esse tutorial, usarei o vim como meu editor. Mas use o que você preferir.

O primeiro commit

O commit do Git é muito parecido com o commit de outros sistemas de controle de versão, como o Subversion. Após iniciado o processo, adicione uma mensagem de commit que explique o motivo da alteração e pronto. O arquivo está alterado. Execute git commit. Seu editor abrirá e aparecerá o modelo de commit abaixo:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# 
# Initial commit
# 
# Changes to be committed:
# new file:   index.php
# 
# Untracked files:
# README.md

Tal como acontece com o output do git status, você pode acompanhar o status de seu repositório de trabalho, o que facilita lembrar onde está trabalhando com commit e onde não está.

Uma boa mensagem de commit é composta por duas partes: uma mensagem curta, com menos de 72 caracteres, o que indica resumidamente (na voz ativa) a alteração que está sendo feita; e uma descrição mais longa e opcional.

No nosso caso, não é necessário escrever nada muito elaborado. Estamos apenas adicionando o arquivo ao repositório. Mas, se a alteração envolvesse um algoritmo mais complexo, seria importante compartilhar com seus colegas desenvolvedores o motivo pelo qual efetuou a mudança.

Agora, adicione apenas a mensagem “Adicionando arquivo de script ao repositório”, salve e feche o editor. Execute git status novamente e você verá que README.md continua listado como não rastreado.

Leia: Porque Google, IBM e outras grandes empresas que não exigem diplomas

Vendo as diferenças

Agora que já temos alguns arquivos sob controle de versão e analisamos os comandos básicos, vejamos como revisar as alterações de arquivos. Por isso não completei o último commit.

Para rever as alterações em um arquivo, usamos o comando git diffcommand. O Git diff, similar ao Linux diff e outros programas diff, comparam dois arquivos e mostram as mudanças dos arquivos mais recentes.

Vamos retomar as mudanças do README.md. Para isso, execute git diff README.md. Aconteceu algo inesperado? Acho que você estava esperando para ver a diferença entre a versão mais recente e a cópia do arquivo. Isso pode atrapalhar um pouco no começo.

É preciso ter em mente que tipo de arquivo você está manipulando. Por padrão, git diff diferenciará os arquivos. Se você quiser ver mudanças escalonadas, então execute o git diff --cached README.md. Esse comando se desdobrará em algo similar a isto:

diff --git a/README.md b/README.md new file mode 100644 index 0000000..27c0a86 --- /dev/null +++ b/README.md @@ -0,0 +1,5 @@ +# Simple Git Project + +## Authors + +Matthew Setter matthew@maltblue.com

É onde você visualiza as alterações no arquivo. Dada a notável complexidade, focaremos apenas nas últimas cinco linhas. Antes de cada linha, há um sinal de adição (+), o que denota que todas as linhas estão sendo somadas ao arquivo. Se estivéssemos removendo algum conteúdo, teríamos um sinal de subtração (-).

Há uma série de opções que podem ser transmitidas para diff. Acesse aqui as referências online.

Histórico de alterações

E se você quiser ver o histórico do repositório ou do arquivo? Use git log. Isso mostrará uma lista das alterações em ordem cronológica reversa. Você verá o hash de confirmação, o nome e o e-mail do autor da mudança, data/hora do commit e a mensagem de confirmação.

Mas, e se você quisesse filtrar essas informações? Por exemplo, visualizar apenas a hash do commit e mensagem do commit? Para isso, execute --oneline e altere para git log dessa forma: git log --oneline.

Isso exibirá informações do histórico, como mostrado na captura de tela abaixo, que tirei do projeto Zend Framework 2, pois ainda não temos histórico suficiente para o nosso projeto. --oneline é um atalho para --pretty=oneline. Em vez de oneline, você poderia usar short, medium ou email para diferentes tipos de perspectivas em seu histórico de repositório.

Para toda as opções, você pode utilizar log, executar git help log ou pesquisar a documentação de referência Há um grande número de alternativas disponíveis. Isso facilita configurar a ferramenta da forma que você achar conveniente.

Leia: Conheça 4 programadoras que fizeram história

Ramificação (branching)

Estamos caminhando para o fim, mas não podemos deixar de falar sobre ramificação, um dos aspectos fundamentais do trabalho com Git. Talvez você nunca tenha usado esse recurso e esteja acostumado a trabalhar com branch master – na terminologia git, com a equipe.

Pode ser feito dessa maneira, mas os problemas surgirão quando mais de uma pessoa estiver trabalhando na mesma seção de um mesmo arquivo. Os branches são essenciais para que conceitos e ideias sejam experimentados com segurança.

O Git facilita a criação dos branches, bem como seus testes e implementações, além de realizar o merge das alterações com os branches de desenvolvimento. Vejamos como isso funciona.

Você deve ter notado que, neste tutorial, estamos usando o branch master, que é o padrão do Git. Agora, vamos criar o branch de desenvolvimento.

Leia: Machine Learning: entenda as oportunidades profissionais dessa área

Execute git checkout -b develop para criar um novo branch chamado develop. Esse comando cria e checa o branch que, a princípio, nada mais é do que uma cópia do branch master.

Se executar git status, você ainda verá as duas mudanças separadas no README.md. Faça o commit de ambas, e vamos aprender a fazer o merge dessas alterações de volta ao branch master.

Feito isso, estamos prontos para o merge. Antes de mais nada, verifique o branch em que faremos o merge. Execute git checkout master.

Agora é preciso fazer o merge das alterações realizadas Para isso: git merge develop.

Quando o processo estiver completo, você verá os resultados dos arquivos alterados e um breve resumo dessas alterações.

Tão simples quanto isso! Existem outras maneiras para atingir esse mesmo resultado, mas, nesse momento, o foco são apenas os aspectos mais fundamentais.

Como usar o GitHub

Agora que estamos mais familiarizados com o Git, vamos tratar do GitHub. Para facilitar o aprendizado, utilizarei capturas de telas de um projeto do GitHub. Sim, essa ferramenta é muito mais que um simples repositório de projeto. Mas é nele que você passará a maior parte do tempo.

Você está vendo um projeto de site. Na parte de cima, no ponto 1, estão listados o nome do projeto, quantas pessoas o estão visualizando, quantas pessoas aderiram e quantas solicitaram permissão para fazer mudanças e contribuir com o projeto.

O ponto 2 mostra o número de commits do branch atual, o número de branches, o número de releases e o número de colaboradores. No ponto 3 fica o coletor de branches, uma lista dos arquivos do projeto e quando os últimos commits foram realizados.

Ao lado direito, ponto 4, temos as opções de navegação. São elas:

  • Code: A exibição padrão dos arquivos do projeto.
  • Issues: Um rastreador de problemas simples e eficaz, se você e a equipe quiserem denunciar erros e problemas, solicitar novos recursos, etc.
  • Wiki: Um wiki simples (e também eficaz) para documentar o projeto de forma mais detalhada do que permite um arquivo README padrão.
  • Pulse: Um resumo das estatísticas do projeto que inclui problemas que surgiram e suas respectivas soluções. É com esse recurso que podemos medir as progressões do projeto.
  • Graphs: Um apanhado geral dos commits realizados, separados por cada colaborador do projeto. Com base em uma série de métricas e indicadores, podemos usar as guias disponíveis para análise detalhada da atividade evolutiva do projeto.

Por fim, ainda no lado direito, fica o link para o repositório URL. Se quiser clonar esse projeto, essa é a URL que você deve passar pelo git clone.

Agora vamos analisar o histórico dos commits, clicando em commits. Aqui é possível visualizar os commits em ordem cronológica reversa. No lado esquerdo podemos ver uma breve descrição dos commits: nome do autor e data de realização. À direita fica a versão resumida e um link para o commit.

Clique para ver as respectivas alterações. Nesse exemplo, podemos ver as diferenças do arquivo README do projeto comparado a um segundo arquivo library/Zend/Version/Version.php.

É possível ver no lado esquerdo o que foi removido da versão anterior e, no lado direito, o que foi adicionado a essa versão. Acima de cada commit, no lado esquerdo, você vê um breve resumo mostrando tanto o total de alterações (neste caso, 15) quanto uma representação visual dessas mudanças. Vamos nos divertir um pouco.

Passe o mouse sobre o lado direito ou esquerdo. Observe que um ícone azul apareceu. Se clicar nesse ícone, você pode fazer um comentário naquele código específico. É esse tipo de característica que torna o GitHub uma ferramenta verdadeiramente colaborativa.

Uma última dica: quer fazer um comentário geral no commit? Ao fim de cada um deles existe um espaço para comentários gerais. Clique nas outras guias e explore o que cada uma tem para oferecer.

Leia: Descubra 6 habilidades que estão em alta no mercado

Como adicionar nosso projeto ao GitHub

Vamos cuidar de passar nosso projeto para o GitHub Para isso, faça seu login, clique no sinal de soma (+) no canto superior direito e, no menu suspenso, clique em New repository. Isso dará acesso ao formulário de criação de um projeto.

No campo Repository name, adicione um nome. Não precisa de nada especial. Pode ser “primeiro projeto”. Se quiser, faça uma breve descrição. Talvez “Meu primeiro projeto no GitHub”. Em seguida, mude o padrão do projeto para “Public”. Isso fará com que qualquer um consiga acessá-lo.

Por fim, clique em Initialize this repository with a README e deixe os dois checkboxes marcados como None. Agora, clique em Create repository.

Isso nos conduzirá à página de configuração. Esta página oferece uma série de informações sobre a integração do novo projeto GitHub e o repositório local já existente. Vamos adicionar o GitHub como um controle remoto para nosso projeto.

Para isso, copie a primeira linha abaixo do …or push an existing repository from the command line e a cole no terminal que está sendo utilizado até agora.

Isso não apresentará nenhum resultado. Agora, copie a segunda linha e cole-a no terminal. Esse comando conduzirá nossas alterações ao GitHub. Você verá um resultado parecido com a tela abaixo.

Agora, volte ao Github em seu navegador e atualize a página. Você verá o README.md e index.php na lista de arquivos, e também o conteúdo do README.md representado na parte inferior da página.

Referências e estudos complementares

O que vimos até aqui são os fundamentos do Git e do GitHub. E, embora haja muitos conceitos a serem adotados, uma vez que você consegue entender o básico, o domínio desses fundamentos virão com o tempo.

Não temos tempo para tratarmos de tudo aqui e existe muito mais a ser explorado. Para isso, a comunidade por trás dessas duas ferramentas servirá como um indispensável suporte colaborativo. Você estará em boas mãos.

Leia: 21 (possíveis) empregos do futuro para conhecer hoje

Abaixo, confira os links para leituras e estudos complementares. Com tudo isso em mãos, você encontrará quase tudo que precisa para se tornar um mestre em Git e GitHub.

Artigo originalmente publicado no blog americano da Udacity

Matthew Setter