Amplamente utilizado por programadores para divulgar seus trabalhos, com a possibilidade de contribuições de outros programadores, o GitHub é uma plataforma de hospedagem de código-fonte com controle de versão. Esse controle é feito pelo sistema Git, que foi inicialmente projetado e desenvolvido por Linus Torvalds para o desenvolvimento do kernel Linux, mas foi adotado por muitos outros projetos. Cada diretório de trabalho do Git é um repositório (local de armazenamento dos códigos) com um histórico completo e habilidade total de acompanhamento das versões/revisões.
Após fazer sua conta no site do GitHub, é oferecido um tutorial muito bom para começar a trabalhar com esse sistema. Ele é chamado de Hello World, um nome tradicional dado aos programas simples voltados aos iniciantes em uma linguagem de programação. Abra uma nova aba e siga o tutorial para:
1. Criar e usar um repositório (“repository”)
Um repositório geralmente é usado para organizar um único projeto; podem conter pastas e arquivos (textos, imagens, vídeos, planilhas, conjuntos de dados, etc)
2. Começar e gerenciar um novo ramo (“branch”)
“Branching” é o modo de trabalhar em diferentes versões de um repositório ao mesmo tempo. Por padrão, seu repositório possui um ramo chamado “master” (mestre), que é considerado o ramo definitivo. Quando você cria uma ramificação, você está fazendo uma cópia do “master” como era nesse momento – como se você criasse um código “teste_v1.sh” copiando o arquivo original “teste.sh”.
3. Fazer alterações em um arquivo e enviando-o para o GitHub como uma confirmação (“commit”)
As mudanças salvas são chamadas de commits (confirmações). Um commit em um repositório git registra uma fotografia (snapshot) de todos os arquivos no seu diretório. O Git tem por objetivo manter os commits tão leves quanto possível, de forma que ele não copia cegamente o diretório completo toda vez que você “commita”. Ele pode (quando possível) comprimir um commit como um conjunto de mudanças (ou um “delta”) entre uma versão do seu repositório e a seguinte.
Cada commit tem uma mensagem de confirmação associada, que é uma descrição explicando a mudança, para que outros contribuidores possam entender o que você fez e por quê. O Git também mantém um histórico de quando ocorreu cada commit. No post How to Write a Git Commit Message existem muitas dicas de como escrever boas mensagens de commit – curtas e completas.
4. Abrir e combinar um pedido de manejo do código (“pull request”)
Ao abrir um “pull request”, você está propondo suas mudanças e solicitando que alguém analise e extraia sua contribuição, juntando-as em seu ramo principal (nesse exemplo, você está solicitando para você mesmo). Os pedidos de envio mostram “diffs” (diferenças) do conteúdo de ambos os ramos – adições e subtrações são mostradas em verde e vermelho, respectivamente. Ao usar o sistema “@mention” do GitHub na sua mensagem de solicitação, você pode solicitar comentários de pessoas ou equipes específicas.
5. Mesclar seu “pull request” (“merge”)
Unir modificações feitas no ramo trabalhado com o ramo principal (“master”).
Nesse tutorial, é utilizado o arquivo README.md, voltado para descrever o repositório. As extensões .md e .markdown são arquivos de texto escritos na sintaxe Markdown, uma linguagem de marcação que converte o texto em XHTML válido (clique no link para ver algumas formatações básicas). Se você tiver um Readme.md no seu repositório, o GitHub mostrará o conteúdo na página inicial dele.
Aqui vai o exemplo de um perfil de um usuário do GitHub, de onde é possível acessar o(s) repositório(s) criados e mantidos por ele.
Baixar o repositório em seu computador, trabalhar com ele e atualizar o GitHub
Geralmente trabalhamos em nosso computador para depois usar o GitHub de modo a disponibilizar o código online. Isso pode ser feito instalando-se o git em seu computador e executando alguns procedimentos, conforme segue. O git é um programa que pode ser instalado no Linux/Debian através do comando “sudo apt-get install git”.
Primeiramente, acesse o GitHub e crie um repositório, conforme tutorial do início do post. Clique no botão “Clone or download” e copie a URL informada.
Agora, você precisa trazer este projeto para o seu computador, processo esse chamado “clonar”. Para isso, dirija-se ao seu diretório de trabalho (onde deverá ficar o diretório do projeto, a ser criado) e execute o seguinte comando (onde URL é aquele link copiado anteriormente, algo do tipo https://github.com/
git clone URL
Uma pasta com o nome do projeto é criada e ele é baixado para a sua máquina. Nela, você pode criar ou copiar seus arquivos para ele e editar. Posteriormente, você deverá executar alguns comandos (executados dentro da pasta clonada) para adicionar esses arquivos ao projeto no GitHub, fazendo uso de versionamento:
git add arquivo1 arquivo2 ...
– Adiciona o(s) arquivo(s) em um lugar chamado de INDEX, que funciona como uma área do git no qual os arquivos (novos ou alterados) possam ser enviados ao Github (ainda não está adicionando um arquivo novo ao repositório, só dizendo que o arquivo, novo ou não, está sendo preparado para entrar na próxima revisão do repositório) – se fizer alguma nova alteração no arquivo depois desse comando, ele deve ser executado novamente.
git commit -m "SEU COMENTÁRIO"
– Pega todos os arquivos que estão no INDEX e cria uma revisão com um número e um comentário (em uma área chamada de HEAD, que aponta para o último commit feito). O comando “git commit –amend” modifica a mensagem do commit mais recente, abrindo um editor de texto (útil caso você tenha incluído arquivos por engano e queira retirá-los, por exemplo).
git push
– Publica todos os seus commits para o github (precisa usar sua senha).
git status
– Exibe o status do seu repositório atual.
Caso comece a trabalhar em outro computador, basta repetir o procedimento de clonar o código para a nova máquina e os procedimentos para subir novamente os arquivos criados/modificados.
E se o projeto local está desatualizado? Ou seja, se voltar a trabalhar naquela sua primeira máquina ou se você/alguém fez uma alteração (diretamente no site ou subindo arquivos para o GitHub). Nesse caso, você deverá baixar novamente o projeto, mas não usando “clone”, e sim esse comando:
git pull
Para investigar conflitos, use o comando “git fetch” seguido de “git diff origin/master”. No Git existem duas versões do repositório local: uma versão contém o seu código, com suas alterações, e a outra versão espelha o repositório remoto, para que seja usada como contraste à sua versão local do código no caso de fazer merge ou diff, por exemplo. Você vai ver as diferenças entre o seu código local e o código remoto (que na verdade agora está em sua máquina graças ao fetch), com a alteração que acabou de ser feita, sem que o código local seja alterado.
Em vez de usar o terminal, existe uma interface gráfica. Ela pode ser instalada através do comando “sudo apt install gitk” e executada através do comando “gitk”.
Para clonar todos os repositórios de um usuário USERNAME, você pode usar o seguinte comando no terminal:
curl -s "https://api.github.com/users/USERNAME/repos?per_page=100" | jq -r ".[].clone_url" | xargs -L1 git clone
Para funcionar, deve-se instalar o cURL e o JSON processor (sudo apt install curl jq).
Gists
Um serviço oferecido pelo GitHub é o Gists: um conjunto de repositórios Git usados pra manter pedaços de código (“snippets”) como se fosse um rascunho (não pertencem a nenhum projeto específico). Geralmente são usados como referência de código utilizados com frequência. É semelhante ao pastebin, só que permite controle de versão. No link, está disponível um exemplo de perfil de Gists.
Ao clicar no Gist de interesse, abre uma nova tela contendo o código, espaço para comentários, opção para fazer o download do código e até a opção de incorporar o conteúdo a um site através de tag javascript, conforme o exemplo a seguir:
Por fim, veja mais sobre o tema no post sobre Bitbucket: configuração e branches clicando no link.
Veja procedimentos rápidos no post Guia rápido de versionamento.
Fontes
- Learn Git Branching (tutorial em forma de jogo)
- Tableless
- Git – guia prático
- Wikipedia
4 comments