Entendendo Git: Como começar? — Parte 1

Como desenvolvedores, muitas vezes precisamos trabalhar em equipe: projetos de laboratório, atividades de disciplinas, projetos reais, e também desenvolvimento em empresas, são fatores que contribuem fortemente para isso, tornando o domínio do git tão importante. A ideia desse post não é falar sobre a história do Git ou dissertar sobre sua importância, mas um hands-on em como começar.

Entre os objetivos principais do git, estão o controle de versionamento e o suporte ao desenvolvimento em equipe. Entretanto, para conseguir fazer isso adequadamente, é preciso ter uma maior atenção durante o processo. Utilizar o git não é difícil, mas alguns passos são importantes para iniciar o uso da ferramenta e o primeiro deles é escolher um host para o git. Existem diversas opções de hosts, sendo GitHub, GitLab e BitBucket algumas das mais conhecidas. Para fins de exemplo estarei usando o Github, mas o tutorial serve igualmente para todos os hosts então sinta-se livre para escolher o que mais te agradar ou for familiar :)

O Git é organizado em repositórios e cada um deles pode conter sua própria estrutura de pastas, arquivos de código, imagens, etc. Entretanto, como uma das regras principais das boas práticas no uso de Git, cada repositório deve ter um propósito específico. O objetivo principal de manter essa regra é que o escopo do projeto ali contido e implementado fique melhor definido, não misturando diferentes ideias no mesmo conjunto de arquivos. Essa forma de organização tem um enorme papel na comunidade open source e facilita o entendimento e desenvolvimento de aplicações pela comunidade.

Os primeiros passos consistem na criação da conta e na instalação e configuração do git na máquina, mas já existem muitos tutoriais bem detalhados para cada sistema operacional que podem ser encontrados facilmente e, por esse motivo, não serão abordados aqui.

Podemos então iniciar a partir da criação de um repositório. No GitHub, e logado em sua conta, existe o botão New Repository (Novo Repositório): basta clicar nele para ir até a tela onde são inseridas as configurações para seu novo repositório. A mesma tela pode ser alcançada clicando no +, no canto superior direito, clicando em New Repository em seguida.

Capture da Criação de um Repositório

Em seguida, é necessário preencher os dados básicos sobre o repositório que se quer criar: nome, se é privado ou não, descrição, etc. Criado o repositório, para começar o desenvolvimento é necessário conectar uma pasta da sua máquina ao repositório. Para isso, precisamos da url (https ou ssh, dependendo da sua configuração) dada na página do repositório, como indica a imagem abaixo.

Com esse link em mãos, podemos conectar a pasta ao repositório pelo terminal através dos comandos:

$ mdkir exemplo && cd exemplo # criamos uma pasta vazia e entramos
$ git init # inicia o git na pasta
$ git remote add origin https://github.com/juliobguedes/exemplo.git # configura a origem do repositório no git

Agora, todos os arquivos inseridos ou criados na pasta poderão ser enviados ao repositório no GitHub.

Adicionando arquivos localmente

Até agora nós configuramos a nossa pasta, que agora passa a servir como um link entre nossos arquivos locais e os arquivos no host que escolhemos. Vamos supor que nós tenhamos criado um novo arquivo:

$ touch novoArquivo.txt # cria um novo arquivo

A partir de agora, o git começa a ver diferenças entre o nosso repositório local e o repositório no host. Podemos verificar isso através do comando git status :

$ git status
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
novoArquivo.txt
nothing added to commit but untracked files present (use "git add" to track)

Acima, é possível ver a resposta dada pelo git e analisar seu conteúdo: na primeira linha, logo de cara, somos informados em que branch estamos. Em seguida, vemos que ainda nenhum commit foi feito, e que existem arquivos não rastreados, apresentando os seus nomes logo em seguida.

Para iniciar a rastrear esses arquivos, precisamos adicioná-los ao repositório usando git add novoArquivo.txt . Os arquivos, entretanto, não precisam ser adicionados um a um (como estamos fazendo): caso nosso objetivo seja enviar todas as mudanças que fizemos até agora para o host, podemos incluir toda a nossa pasta, junto com as modificações que fizemos em arquivos, arquivos que foram incluídos e arquivos que foram excluídos: git add . , onde . significa a pasta atual, e portanto, caso você esteja na pasta principal, todo o conteúdo das pastas filhas serão também adicionados. Quando executamos o add, o git não mostra nenhuma saída, mas é possível notar a diferença quando executamos o git status novamente:

$ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file:   novoArquivo.txt

Como remover um arquivo adicionado

Como podemos ver na resposta do nosso último git status , para remover um arquivo podemos executar o comando git rm --cached <file> . Porém, existe uma sutileza envolvendo o comando git rm : quando queremos manter o arquivo e apenas remover sua adição ao git, devemos usar o parâmetro --cached que ele nos indica; caso o arquivo deva ser removido do repositório (i.e. excluído), o parâmetro correto a ser utilizado é -f , que indica que o arquivo deve ser removido forçadamente. Ao dar o git rm --cached novoArquivo.txt , temos como output rm 'novoArquivo.txt' . Caso tenhamos a intenção de excluir o arquivo (tanto do git quanto da pasta) e usarmos o comando git rm -f novoArquivo.txt , temos o mesmo output.

Entretanto, se olharmos o git status após cada operação, teremos a noção de que após a primeira operação o status é similar ao status quando havíamos acabado de criar o arquivo novo:

$ git status
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
novoArquivo.txt
nothing added to commit but untracked files present (use "git add" to track)

Caso estejamos olhando o git status após a segunda operação de remoção, o status é bem parecido ao status de quando ainda não havíamos adicionado nosso primeiro arquivo:

$ git status
On branch master
No commits yet
nothing to commit (create/copy files and use "git add" to track)

Caso tenha adicionado um arquivo indevidamente, essas duas opções de remoção devem cobrir a maior parte das situações que você irá passar na prática.

Enviando as alterações locais para o host

Considerando agora que temos todos os arquivos que queremos enviar ao host adicionados (git add ), podemos fazer um commit. Um commit é a etapa intermediária no envio dos arquivos locais para o host, e serve como forma de confirmar os arquivos adicionados naquele momento, concluindo essa etapa de adição — para que os arquivos adicionados após o commit ser feito sejam enviados ao host, deverá ser feito outro commit. Cada commit tem uma mensagem que, de acordo com as boas práticas de git, deve descrever o que foi modificado naquele envio. Após ser enviado ao host, o commit recebe um código de identificação.

Considerando que adicionamos nosso novo arquivo de texto, vamos então criar um commit, adicionando o parâmetro -m e a mensagem entre aspas em seguida:

$ touch novoArquivo.txt
$ git add novoArquivo.txt
$ git commit -m "adicionando novo arquivo"

Temos, então, um commit criado localmente. Para enviar os arquivos e modificações deste commit para o host faremos um push , e ao dar um push, devemos indicar para qual branch queremos enviar nossas alterações. Por enquanto, como podemos ver no git status , estamos trabalhando na branch master (on branch master ), então é para ela que faremos o push . Além disso, vamos indicar que a branch master está na origem do repositório, através da palavra origin:

$ git push origin master

Dado esse comando o git irá enviar os dados para o repositório no host. Podemos ir até o nosso repositório no GitHub e ver as alterações que foram enviadas:

Repositório após adicionar novo arquivo

Para dar continuidade ao seu projeto apenas é necessário adicionar mais arquivos e continuar implementando. Entretanto, outras situações e tópicos serão abordados nas próximas partes :)

Espero que todos tenham gostado 😃. Qualquer feedback é bem vindo!

PS: Quando eu estava aprendendo Git, tomei como base o site do Roger Dudler. É um site bem simples mas que mostra muito sobre git, embora não seja tão explicativo. Por isso, estarei dando continuidade a série de publicações sobre.