Controle de Versões com GitHub

Git

 Git é um sistema de controle de versão distribuído e um sistema de gerenciamento de código fonte, com ênfase em velocidade. O Git 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 com um histórico completo e habilidade total de acompanhamento das revisões, não dependente de acesso a uma rede ou a um servidor central.

GitHub

Está é uma plataforma de hospedagem de código-fonte com controle de versão usando o Git. Ele permite que programadores, utilitários ou qualquer usuário cadastrado na plataforma contribuam em projetos privados e/ou código aberto (Open Source) em qualquer lugar. GitHub é amplamente utilizado por programadores para divulgação de seus trabalhos ou para que outros programadores contribuam com o projeto, além de promover fácil comunicação através de recursos que relatam problemas ou mesclam repositórios remotos (issues, pull request).

Instalando git

        O programa que pode ser instalado neste link para Windows, neste para Mac, ou então através do comando sudo apt-get install git para plataformas Linux/Debian, como o Ubuntu.

Criando sua conta no GitHub

        O github não possui instalação, ele é um serviço, e caso você não tenha uma conta, chegou a hora de criá-la, neste link. Porém, você pode utilizar sua versão desktop e criar a conta diretamente na aplicação, o instalador desta versão será encontrado neste link.                                

Conceitos básicos para utilização do GitHub

        Quando falamos do uso de versionamento com o GitHub, temos sempre que lembrar a estrutura de árvore que é utilizada pelo mesmo.

        Temos uma “Raiz” do repositório que é denominada “Master” onde a partir dela, são criadas “Branches”/Galhos de desenvolvimento.

        Você pode realizar seus testes ao longo do desenvolvimento de uma funcionalidade no sistema dentro do esquema de Branch, evitando assim, qualquer quebra de código do repositório principal (Master).

        Além disso, temos um processo singular para o uso desta tecnologia que segue a seguinte ordem:

  1. Criação do repositório (Master)
  2. Criação de uma Branch a partir do Master
  3. Processo de Clonar o repositório (Trazer o código para o ambiente local)
  4. Adicionar itens na Branch local
  5. Atualizar a Branch que está sendo trabalhada com o código do repositório(Pull)
  6. Checar possíveis diferenças entre os códigos da branch com o master (Diff)
  7. Registrar a alteração na branch local (Commit)
  8. Enviar o código da branch local para a branch do repositório (Push)
  1. Em casos de conflitos, mais de uma pessoa atualizando o mesmo código. Efetuar um processo de mesclagem dos códigos (Merge)

        Configurando o Git

        Uma vez instalada a versão desktop do GitHub, o arquivo de configuração .gitconfig deverá aparecer na sua pasta de usuário do Windows (C:\Users\<Seu Usuário>) e deve estar preenchido com algo semelhante à próxima imagem. Caso não esteja, atualize as informações de usuário no arquivo.

Utilizando o GitHub Desktop

Após criar a conta, você verá um botão “+” no menu superior esquerdo conforme a próxima imagem. Após clicar em “Create” você entrará na tela onde poderá criar um repositório de acordo com a tela a seguir. Obs.: Selecione o local onde você desenvolverá seu projeto (de preferência) caso contrário, terá de mover todas as alterações feitas manualmente, acrescentando um ou mais passos ao processo de versionamento.



        Após a criação de seu repositório temos a tela inicial de seu projeto :

        Dentro da interface inicial, você pode adicionar o código diretamente no seu diretório do Explorer através de um clique com o botão direito no menu lateral esquerdo :

Neste exemplo, temos um projeto criado no Eclipse na mesma pasta, mas como podem ver, ele não aparece no histórico do GitHub enquanto no Explorer temos toda estrutura inicial do projeto :

        Para resolver isto, vamos realizar nosso primeiro commit (primeiro envio de arquivos). Dentro do GitHub clique na aba Changes no topo do container principal da aplicação e preencher os campos de sumário e descrição para habilitar o “Commit to master” :

        

Após o commit, teremos a mesma tela em branco, onde não haverá nenhum histórico de mudanças nos arquivos que foram “commitados”. Mas ao retornar para a aba de History teremos a seguinte visão :

        A primeira parte da entrega foi feita localmente, para enviar os dados para o seu repositório no servidor do GitHub, clique no publish no topo direito do container principal.

        Note que poderá notar na aba superior do container principal, uma linha do tempo (timeline) de suas alterações :

        

Lembrando de sempre sincronizar o código pressionando o botão Sync para pegar as últimas atualizações da timeline.

        Para começar o seu desenvolvimento, é aconselhado se utilizar da branches (galhos) que podem ser criados facilmente no GitHub. Para criar a sua primeira branch, clique no botão  no canto superior esquerdo do container principal :


        Sempre que você realizar alterações no seu código local, um sinalizador aparecerá na aba de “Changes” e você poderá visualizar o que foi alterado ou criado dentro do seu Workspace.

        

Após realizar o processo de commit e publish na branch, teremos um novo processo de entrega, o “Pull Request” onde enviaremos o novo código da branch para o Master.

        Após o Pull request na branch, você deve acessar o seu repositório através do botão localizado no mesmo local do Pull request, ele estará com esse formato . Acessando o site, você deverá autorizar o Pull Request para que ele surta efeito, lembrando que todos aqueles que tiverem branches provenientes de seu repositório, precisarão da mesma autorização para efetuar as entregas no master.

        

Após realizar o merge (neste caso não houve nenhum conflito de arquivos), você deverá atualizar o app para visualizar a alteração.

Observações

  • Nunca autorize a entrega de códigos sem uma prévia validação de conflitos. A aplicação já ajuda bastante neste ponto, mas todo cuidado com o código valerá a pena mais na frente do desenvolvimento.
  • Utilizar o esquema de branches é aconselhado sempre que houver uma atuação de 2 ou mais desenvolvedores no mesmo Repositório/Projeto.
  • Os processos podem parecer mais lentos, mas garantirão um versionamento eficaz que ajudará bastante na correção de bugs.
  • Existem outras features que a ferramenta pode proporcionar, nunca é demais estudar mais formas de se trabalhar com ela.
Comments ( 0 )
  1. No comments yet.
Comments are currently closed.
Trackbacks & Pingbacks ( 0 )
  1. No trackbacks yet.
  2. Trackbacks are currently closed.