GitHub

Integração contínua para aplicações PHP usando Github Actions

Github Actions é um serviço relativamente novo e, ainda que em estágio beta, possui boa estabilidade. Ele permite que criemos workflows com jobs a serem executados a partir dos eventos disparados no Github. Então, por exemplo, sempre que um novo pull request é criado ou que um push é feito no Github, são exemplos de eventos que podem disparar a execução de workflows. Esse serviço favorece muito a implementação de integração e entrega contínua sem que haja a necessidade de sairmos do Github para serviços externos como Travis, CircleCI etc.

No caso específico do PHP podemos criar um workflow para que a cada novo push em determinado branch dispare a execução de um job para rodar os testes unitários do projeto, executar o PHPStan (analisador estático) e até mesmo executar o PHP Insights para avaliar a qualidade do código. Enfim, é possível executar qualquer ferramenta que faça sentido pro contexto do projeto.

Mas, há de ressaltar, o Github Actions é muito mais que isso. Possui uma infinidade de eventos que podem ser trabalhados. Nesse artigo focaremos na integração contínua de uma aplicação PHP tradicional, no sentido de rodar testes unitários, executar o PHPStan e o PHP Insights a cada novo push ou pull request a fim de garantir que o código esteja dentro dos parâmetros exigidos pela equipe antes dele ser incorporado. Mas o Github Actions pode ser usado para qualquer projeto de qualquer linguagem.

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

No que se baseia o Github Actions?

O Github Actions se baseia em Workflows que são fluxos de trabalho, por exemplo: Build, Teste e Publicação poderiam ser três tipos de workflows. Cada Workflow deve possuir um ou mais jobs. O Job refere-se à execução de uma tarefa, por exemplo, poderíamos em um workflow termos um job para dar build nos assets e outros job para executar os testes. É no workflow que configuramos quais eventos e ambientes (ubuntu, macOS etc) os nossos jobs serão executados. Em resumo, temos um workflow que possui N jobs e um job possui N steps (ações). Veremos isso na prática daqui a pouquinho, o que tornará mais fácil de visualizar a dinâmica da coisa toda.

O Github Actions é pago ou grátis?

É grátis para repositórios públicos e pago para repositórios privados com cobrança por minuto de execução. Na página do Github Actions você consegue visualizar melhor os detalhes de cobrança. Lembrando que enquanto estiver em fase beta o serviço estará grátis tanto para repositórios públicos quanto para privados.

O que eu preciso fazer para começar a usar?

Como o serviço ainda está em beta é preciso que você se inscreva para utilizá-lo. Basta que você esteja logado na sua conta do Github e então clicar no botão “Sign up for the beta“:

Depois é só confirmar:

O projeto de teste

Criei um projeto de uma classe e um método só, para que foquemos no assunto central do artigo, que se trata da criação de um Workflow de teste e validação do código do nosso projeto.

O nosso Workflow executará as seguintes ferramentas:

  • PHPUnit
  • PHPStan
  • PHP Insights

Recomendo que você leia o artigo Ferramentas essenciais para um projeto PHP para conhecer um pouco mais sobre elas.

O projeto completo com o Workflow criado e ativo você pode visualizar em:

https://github.com/KennedyTedesco/github-actions-php

Antes de entrarmos na parte que toca a configuração do Workflow, primeiro quero mostrar o funcionamento visual dele lá no Github.

No projeto tem uma aba chamada Actions, clique nela:

Ela lista os Workflows configurados para o projeto. No nosso caso o workflow se chama “App Workflow“. Do lado direito temos a relação dos eventos que dispararam a execução dele. Ele foi disparado três vezes no evento de “push”, ou seja, quando subimos pro Github alterações.

No primeiro evento (de baixo pra cima) o workflow foi executado com sucesso, sem nenhum erro. Os testes passaram, o PHPStan não reportou nenhum erro e as métricas do PHP Insights estavam todas boas.

Já no segundo teste houve uma falha. Ah, o resultado da execução dos workflows também aparece na listagem dos commits:

https://github.com/KennedyTedesco/github-actions-php/commits/master

Observe os ícones de sucesso e erro.

Voltando na tela anterior, clique em um evento em que a execução do workflow teve sucesso, por exemplo, esse aqui:

https://github.com/KennedyTedesco/github-actions-php/commit/4a5be2bbaf5a09247321efa6c2e799f4c621d699/checks?check_suite_id=264838943

É nessa tela que vemos os Jobs e suas Steps (passos onde ações são executadas). No caso, o Job “Tests” (à esquerda) executou todas as Steps (ações) da tela escura à direita. As ações que configuramos foram no sentido de definir o ambiente PHP em que a execução ocorrerá, instalação das dependências do Composer no projeto e execução das ferramentas de análise e teste.

O evento que causou falha na execução do workflow se deu por causa desse commit:

https://github.com/KennedyTedesco/github-actions-php/commit/9f6fb1142a5e2b98a2ecedd904eaa10301c1eb0e

Explicitamente fiz um teste falhar ao fazer ele comparar 4 === 8.

Quando subi essa alteração para o Github, um evento de push foi disparado fazendo executar o workflow, que então falhou:

https://github.com/KennedyTedesco/github-actions-php/commit/9f6fb1142a5e2b98a2ecedd904eaa10301c1eb0e/checks?check_suite_id=264846074

Definindo o Workflow no projeto

Agora que já vimos como funciona lá na interface do Github a parte visual da execução do workflow, veremos como de fato podemos criar-lo dentro do nosso projeto.

Primeiro de tudo, devemos criar uma pasta chamada .github dentro do projeto. E, dentro dessa pasta, devemos criar uma pasta chamada workflows.

- github-actions-php
- - .github
- - - workflows
- - - - main.yaml

É dentro da pasta workflows que criamos os arquivos de definição dos nossos workflows. São arquivos yaml. Criamos apenas um workflow, portanto teremos apenas um arquivo yaml nessa pasta e demos o nome dele de main.yaml:

name: App Workflow

on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master

jobs:
  build:
    name: Tests
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@master

      - name: Setting up PHP
        uses: ./.github/actions/php

      - name: Installing Composer
        run: ./.github/scripts/run-composer.sh

      - name: Running PHPStan
        run: ./.github/scripts/run-phpstan.sh

      - name: PHP Insights
        run: ./.github/scripts/run-phpinsights.sh

      - name: Running PHPUnit
        run: ./.github/scripts/run-phpunit.sh

Esse é o nosso workflow completo. Em name definimos o nome dele.

Em on especificamos em quais eventos de quais branches esse workflow será executado. No caso, estamos dizendo que ele será executado sempre que um push ou um pull request for feito para o branch master.

Em jobs é onde definimos os jobs. No caso, temos apenas um job chamado build, veja que na estrutura do yaml eu dei o nome de build mas ao definir o nome dele lá pro Github eu o chamei de “Tests”:

  build:
    name: Tests

Isso não importa muito, você vai definir o nome que achar mais conveniente e lógico para o que você estiver executando. Eu poderia tranquilamente tê-lo chamado de:

  tests:
    name: Tests

Sem problema algum.

A diretiva runs-on do job especifica em qual ambiente a execução acontecerá. O ideal é você escolher o mesmo ambiente que você roda em produção.

Em steps é onde executamos as ações do job. Um job pode executar N ações. A action Checkout é padrão, é ela quem clona o projeto no ambiente de execução. Veja que ela possui um endereço do Github:

    steps:
      - name: Checkout
        uses: actions/checkout@master

Ela é mantida pelo Github e pode ser visualizada aqui: https://github.com/actions/checkout

Ou seja, podemos executar actions que estejam em repositórios arbitrários. Existe todo um ecossistema de actions que podem ser reutilizadas. Existe até mesmo um Marketplace de Actions no próprio Github:

https://github.com/marketplace?type=actions

Também tem uma lista de centenas de actions mantidas pela comunidade:

https://github.com/sdras/awesome-actions

Voltando ao nosso workflow, a segunda action:

      - name: Setting up PHP
        uses: ./.github/actions/php

Ela especifica que se trata de um Dockerfile contido em ./.github/actions/php que instalará a versão 7.3 do PHP que será usada para rodar os testes e validações:

https://github.com/KennedyTedesco/github-actions-php/tree/master/.github/actions/php

FROM php:7.3-cli-alpine

COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

Ou seja, podemos criar actions baseadas em Dockerfiles.

A terceira action:

https://github.com/KennedyTedesco/github-actions-php/blob/master/.github/scripts/run-composer.sh

      - name: Installing Composer
        run: ./.github/scripts/run-composer.sh

Veja que ao invés de uses ela especifica run, pois estamos definindo qual comando ou arquivo ela deverá executar ao invés de qual action ela deverá usar.

Essa action é responsável pela instalação das dependências do composer no projeto. Nesse ponto já teremos o PHP configurado. Eu gosto de trabalhar com arquivos shell script para definir as tarefas que serão executadas. O conteúdo do arquivo run-composer.sh é:

#!/bin/sh
cp .env.ci .env
composer install --no-ansi --no-interaction --no-suggest --prefer-dist

Ela copia o arquivo .env.ci para .env na raiz do projeto e depois instala as dependências. O arquivo env.ci não tem nenhuma utilidade para o nosso projeto, eu deixei ele criado apenas para mostrar o que você pode fazer quando estiver criando um workflow para uma aplicação Symfony ou Laravel que use variáveis de ambiente. Nesse sentido, você pode ter variáveis de ambiente específicas para a execução do workflow.

Ao invés de executar o arquivo run-composer.sh poderíamos ter executado esses comandos diretamente no yaml do workflow, por exemplo:

      - name: Installing Composer
        run: |
          cp .env.ci .env
          composer install --no-ansi --no-interaction --no-suggest --prefer-dist

Mas eu prefiro definir arquivos shell script.

As últimas três ações rodam o PHPStan, PHP Insights e PHPUnit, respectivamente. Também são simples arquivos shell script. E com isso fechamos a configuração do nosso workflow.

Concluindo

Eu encorajo que você leia a documentação e veja todos os recursos e opções disponíveis. Por exemplo, na página Workflow syntax for GitHub Actions tem muita informação valiosa sobre as outras sintaxes e opções.

E, não menos importante, quando você for criar um workflow para sua aplicação de maior porte, você certamente precisará lidar com a integração de variáveis de ambiente entre os jobs e actions, para isso, sugiro que você leia Virtual environments for GitHub Actions.

Como não dá pra masterizar o assunto em um artigo, tentei focar no essencial, no principal para uma aplicação PHP tradicional. Mas essas mesmas ideias podem ser agregadas para que você crie sua integração contínua para Laravel, Symfony ou outro framework qualquer. Sem contar que além do workflow de teste, você poderia ter um workflow para uma tarefa de corrigir o estilo do seu código e criar um pull request disso de forma automatizada, por exemplo. Como também poderia ter workflows para entrega/deploy contínuos. As possibilidades são muitas.

Até a próxima!

Analista DevOps Júnior
Formação: Analista DevOps Júnior
A formação Analista DevOps nível Júnior da TreinaWeb visa introduzir desenvolvedores a tecnologias como o Docker e o servidor HTTP Nginx, tecnologias estas intimamente relacionadas ao notável universo DevOps.
CONHEÇA A FORMAÇÃO

Como criar repositórios privados do Symfony Flex

O Symfony Flex possui 2 repositórios públicos onde ele busca os recipes. O primeiro é o repositório oficial onde ficam as recipes da própria equipe do Symfony. O segundo é o repositório contrib onde o pessoal da comunidade envia as recipes que são usadas para bundles públicos que não são oficiais.

Quando precisamos criar recipes para automatizar tarefas em bundles que serão usados apenas em projetos privados, os dois repositórios anteriores não são aplicáveis. Nesses casos podemos criar os nossos próprios repositórios privados para armazenar nossas recipes.

Symfony - Gerenciando aplicações com Symfony Flex
Curso de Symfony - Gerenciando aplicações com Symfony Flex
CONHEÇA O CURSO

Como criar o repositório privado

O repositório privado do Symfony Flex, na verdade, é um repositório comum Git hospedado no GitHub e integrado ao robô de verificação da equipe do Symfony. O repositório no GitHub pode ser público ou privado, em ambos os casos o recipe será reconhecido, porém já que estamos criando um repositório privado do Flex faz mais sentido o repositório do GitHub também ser privado.

No início de 2019 o GitHub passou a permitir a criação de repositórios privados ilimitados nas contas pessoais gratuitamente, mais informações https://github.blog/2019-01-07-new-year-new-github/

Vamos criar um novo repositório privado no GitHub. Uma vez logado acesse o endereço https://github.com/new e preencha as informações conforme abaixo:

Integrando o repositório do GitHub com o Flex

Agora precisamos indicar ao Symfony Flex que ele deve validar e ler os recipes que colocamos dentro do repositório que acabamos de criar. Isso é feito através de uma integração com o GitHub, acesse o endereço https://github.com/apps/symfony-flex-server/installations/new e selecione a conta que está o repositório que criamos no passo anterior:

Ele vai confirmar sua senha do GitHub e perguntar se você deseja adicionar todos os repositórios da sua conta como repositório do Flex ou apenas 1. Aconselho indicar somente os repositórios que realmente serão usados como repositórios do Symfony Flex:

Depois de clicar em instalar ele apresentará uma tela de congratulations, vamos falar dos passos explicados nessa tela mais adiante.

Desenvolvedor Symfony Full-Stack
Formação: Desenvolvedor Symfony Full-Stack
Nesta formação você aprenderá desenvolver aplicações PHP usando o framework Symfony com desenvoltura. Ao final desta formação, terá condições de trabalhar em grandes aplicações web ou APIs integradas com diversos serviços, tudo isso usando as melhores práticas do mercado.
CONHEÇA A FORMAÇÃO

Como liberar os projetos que podem acessar o repositório

Como nós temos um repositório privado é importante que apenas os projetos autorizados consigam utilizar nossos recipes. Para isso nós geramos um identificador único de cada projeto e configuramos dentro do nosso repositório.

Na aplicação Symfony que utiliza o Flex para gerenciamento, execute o comando abaixo:

composer symfony:generate-id

Esse comando não retorna nenhuma mensagem no console. Ele realiza a criação de um identificador do seu projeto dentro do arquivo composer.json na sessão extra.symfony.id:

"extra": {
    "symfony": {
        "allow-contrib": false,
        "require": "4.3.*",
        "id": "01DFEFJHVTGS3PAR3J1K2HB60T"
    }
}

Agora precisamos configurar esse id no repositório junto com todos outros projetos que terão acesso aos recipes. Esse conteúdo é definido dentro do arquivo config.json na raiz do projeto com o seguinte padrão:

{
  "projects": {
    "id1": "descriçao do projeto 1",
    "id2": "descriçao do projeto 2",
    "id3": "descriçao do projeto 3"
  }
}

Crie o arquivo na raiz do repositório:

Como enviar os recipes

Precisamos enviar os recipes que vamos usar em nossos projetos para o repositório. O processo para criação e envio do recipe é o mesmo usado para o repositório de contrib do Symfony.

Vamos ver como criar um recipe e como enviar para o repositório no próximo post.

Comandos do Git que você precisa conhecer – Parte 2 – Repositórios Remotos

Olá Web Developers! Hoje trago aqui os comandos que você precisa conhecer ao se trabalhar com Git. A primeira parte deste post abordou os comandos do Git para repositórios locais. Agora veremos os comandos para repositórios remotos e também como criar um repositório na nossa rede local.

1 – Clonando um Repositório Remoto

Para fazer download de um projeto basta executar o comando $ git clone, passando o endereço do repositório. Pode ser Github, Gitlab, Bitbucket, etc.

Esse comando é bem conhecido, mas ele está aqui por um detalhe que muitas pessoas não sabem: por padrão será criada uma pasta com o nome do projeto, mas você também pode no final do comando indicar qual o nome da pasta que você quer que seja criada.

$ git clone https://meu-endereco.com/meu-projeto.git minha-pasta

2 – Repositórios Remotos

Repositórios Remotos são repositórios presentes em outra máquina para a qual nós podemos pegar ou enviar código. Todos esses comandos começam com $ git remote. Veja os principais comandos para gerenciá-los:

2.1 – Adicionar Repositórios Remotos

Para ligar o seu repositório local com um repositório remoto, utilize o comando remote add. Precisamos passar dois parâmetros para esse comando:

  1. nome: nome que daremos ao nosso repositório remoto, como se fosse um atalho para não precisarmos ficar escrevendo a URL toda hora. O padrão é usar o nome origin
  2. url: endereço do repositório remoto ao qual o nome passado anteriormente vai se referir
$ git remote add origin https://meu-endereco.com/meu-projeto.git

Caso você queira colocar outro nome ao invés de origin não tem problema. Isso pode ser muito útil caso você precise se conectar a mais de um repositório remoto. Mas se tiver apenas um, o recomendado é seguir o padrão e usar o nome origin.

Ao adicionar mais de um repositório remoto, as alterações serão enviadas para todos. Isso pode ser útil caso você queira armazenar seu código em mais de um lugar ao mesmo tempo.

2.2 – Visualizar Repositórios Remotos

Esse comando nos mostra o endereço do repositório remoto para o qual estamos enviando nossos códigos.

$ git remote -v

Teremos um retorno como:

> origin https://meu-endereco/meu-projeto.git (fetch)
> origin https://meu-endereco/meu-projeto.git (push)

2.3 – Remover Repositórios Remotos

Pode ser que você não queira mais o seu local repositório conectado a um repositório remoto. Esse comando não apaga o repositório, apenas desfaz a conexão criada com o comando $ git remote add

$ git remote rm origin

Nesse exemplo usamos o nome origin, mas lembre-se que ali pode ser o nome que você deu ao seu repositório remoto. Se você deu um nome diferente de origin, lembre-se de usar o comando anterior para listar os repositórios remotos.

2.4 – Renomear Repositórios Remotos

Pode ser que você não queira mais o nome que você deu ao seu repositório remoto com o comando $ git remote add. Há um comando bem simples para renomear.

$ git remote rename nome-atual novo-nome

2.5 – Alterar Endereço de Repositórios Remotos

Já escreveu o endereço de um repositório remoto errado ou migrou ele para outro serviço? Com o comando set-url você será capaz de apenas alterar o endereço sem precisar mexer em mais nada. Precisamos passar dois parâmetros para esse comando:

  1. nome: nome que demos ao nosso repositório remoto, como se fosse um atalho para não precisarmos ficar escrevendo a URL toda hora. O padrão é usar o nome origin
  2. url: novo endereço do repositório remoto
$ git remote set-url origin http://meu-novo-endereco/meu-projeto.git

3 – Branches Remotas

3.1 – Listando Branches

Esse comando lista todas as branches presentes no repositório do seu computador.

$ git branch

Caso você queira que ele liste também as branches que estão no repositório remoto, adicione -a:

$ git branch -a

3.2 – Criando Branches Remotas

Ao enviar o seu código para uma branch remota que ainda não existe, basta executar o push com a opção -u junto com o nome do repositório remoto e o nome da nova branch.

$ git push -u origin minha-branch

Após a branch remota estar criada, você poderá executar simplesmente $ git push.

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

3.3 – Apagando Branches Remotas

Para apagar uma branch remota nós fazemos um push e adicionamos o --delete. Entre o --delete indicamos o repositório remoto e o nome da branch a ser apagada.

$ git push origin -d minha-branch

Também podemos escrever assim:

$ git push origin :minha-branch

3.4 – Renomeando Branches Remotas

Vimos no post anterior que para renomear uma branch local executamos:

$ git branch -m nome-atual novo-nome

Após renomear a sua branch local, basta apagar a branch remota com o nome antigo e fazer um push com a branch com o novo nome:

$ git push origin :nome-atual novo-nome

Para terminar de ligar a branch local com a remota, entre na branch com o novo nome e execute:

$ git push origin -u novo-nome

4 – Achando o culpado

Deu problema e estão dizendo que foi você? Não mais! Com o comando blame você pode ver quem alterou cada linha de um arquivo. (a menos que realmente tenha sido você 😂)

git blame nome-do-arquivo

Para não ficar muito grande, podemos usar -w para ignorar espaços em branco e usar -L para indicar um intervalo de linhas a serem exibidas.

git blame -w -L 1,12 nome-do-arquivo

E ainda podemos usar -e para que seja exibido o email ao invés do nome do usuário.

5 – Compartilhamento Offline

Podemos ter repositórios remotos que não estão na nuvem, como Github, Gitlab, ou Bitbucket. Podemos fazer com que um computador em nossa rede seja o responsável por armazenar o código e receber o push de todos os usuários. Isso é útil principalmente em empresas que possuem uma política mais rígida com a segurança de suas informações e não permitem que seus códigos sejam armazenados fora de seus próprios servidores.

Outro uso para isso é quando adicionamos mais de um repositório remoto. Você pode continuar fazendo commits para o Github e ao mesmo tempo ir armazenando uma cópia em um pendrive.

Primeiro, no local onde teremos o nosso repositório “servidor” (que receberá os pushes), iniciamos um repositório junto com --bare. Neste repositório você não poderá editar arquivos ou fazer commits, ele só permite receber pushes.

$ git init --bare

Se você iniciou, por exemplo, um repositório em uma pasta dentro de um pendrive com o caminho E:\meu-projeto, basta clonar com o comando:

$ git clone E:\meu-projeto

Ou então, como já vimos, podemos adicionar esse repositório na nossa lista de repositórios remotos, permitindo que nossos commits sejam enviados para algum lugar como o Github e para o pendrive ao mesmo tempo:

$ git remote add usb E:\meu-projeto

Nesse exemplo demos o nome usb ao invés de origin. Lembre-se que você pode dar qualquer nome.

Do mesmo jeito que fizemos um repositório em um pendrive, você pode fazer o mesmo em um outro computador na sua rede. Assim todos os usuários em sua rede poderão usar este computador como repositório remoto.

Comandos do Git que você precisa conhecer – Parte 1

Olá Web Developers! Hoje trago aqui comandos muito úteis ao se trabalhar com Git que todo mundo precisa saber para facilitar o trabalho.
Nesse primeiro post veremos os comandos para repositórios locais. Na Parte 2 desse post veremos os comandos para você dominar Repositórios Remotos.

Se você ainda não trabalha com Git, veja nosso post sobre Primeiros passos com o Git.

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

1 – Iniciando um Repositório

Todo repositørio Git armazena as informações dentro de uma pasta oculta chamada “/.git”. Para que os arquivos de uma pasta possam ser versionados pelo Git, é preciso iniciar o repositório. Basta executar o comando abaixo:

$ git init

2 – Apagando um repositório

Há momentos em que não queremos apagar nossos arquivos, mas queremos remover as informações sobre aquele repositório criado com o $ git init (talvez criar um repositório novo com os mesmos arquivos).
Para isso não usamos o Git. Lembre-se que um repositório Git armazena as informações dentro de uma pasta oculta chamada /.git. Então basta apagar esta pasta oculta que o seu atual diretório deixará de ser um repositório.

$ rm -rf .git

3 -Listando Arquivos Modificados

Esse comando indica o estado do seu repositório. Em outras palavras, ele vai listar todos os arquivos que foram modificados desde o seu último commit.

$ git status

4 – Desfazendo Alterações

Poderíamos ter um post inteiro apenas falando sobre como desfazer alterações no Git, já que há vários cenários possíveis. Mas vamos resumir os principais:

4.1 – Arquivos não monitorados

Se o arquivo foi modificado mas você ainda não executou git add, um simples git checkout removerá as alterações, deixando o arquivo como ele estava no último commit. Passe o nome do arquivo a ter as alterações desfeitas ou . para desfazer as alterações em todos os arquivos modificados. Muito útil se você está apenas experimentando um código mas não quer que ele seja salvo.

git checkout .

Esse comando não apaga novos arquivos. Para apagar novos arquivos que ainda não foram adicionados ao Stage, execute:

git clean -df

4.2 – Removendo arquivos do Stage

Se você executou git add e quer desfazer, use o reset.

git reset

Para desfazer as modificações, após o reset use o checkout ou clean mostrados anteriormente.

4.3 – Desfazendo o último commit

Caso você tenha feito alterações e já tenha chegado a realizar um commit, para desfazer é necessário usar o revert.

git revert HEAD

Será criado um novo commit indicando que o último commit foi desfeito.

Esse comando apaga novos arquivos.

5 – Renomear Commit

Escreveu algo errado no último commit? Esse comando te permite renomear a mensagem do último commit feito:

$ git commit --amend

6 – Branches

Sempre é bom não trabalhar apenas na master para evitar problemas e ter um projeto mais flexível.

6.1 – Listando Branches

Esse comando lista todas as branches presentes no repositório do seu computador.

$ git branch

Caso você queira que ele liste também as branches que estão no repositório remoto, adicione -a:

$ git branch -a

6.2 – Indo para outra branch

Para mudar para uma outra branch basta usar o comando checkout, passando o nome da branch.

$ git checkout minha-branch

Se você adicionar -b, uma nova branch será criada.

$ git checkout -b minha-nova-branch

6.3 – Excluindo branches

Para excluir uma branch local basta executar o comando branch com -d ou -D, passando o nome da branch que você quer apagar.

git branch -d nome-da-branch
git branch -D nome-da-branch

A opção -d é mais segura, pois ela só apaga a branch se você já tiver feito merge ou enviado as alterações para seu repositório remoto, evitando perda de código.

A opção -D ignora o estado da sua branch, forçando a sua remoção.

Esse comando apaga apenas a branch local, não removendo branches remotas.

6.4 – Renomeando branches

Para renomear a sua atual branch local, execute o comando branch com a opção -m, passando o novo nome.

git branch -m novo-nome-da-branch

Se você estiver em uma branch e quiser renomear outra, você deve passar primeiro o nome atual da branch que quer renomear:

git branch -m nome-atual novo-nome

6.5 – Branch Órfã

Uma branch órfã tem esse nome porque ela não está ligada à branch principal, então seus históricos não são compartilhados.

          i---j---k     <== branch 'minha branch'
         /
a---b---c---d---h---l   <== branch 'master'
     \         /
      e---f---g         <== branch 'minha outra branch'

1---2---3---4           <== branch `órfã`

Isso pode ser útil quando você quer colocar mais de um projeto em um mesmo repositório. Um bom exemplo é quando você tem um projeto no Github e quer criar um site para divulgar o seu projeto. A aplicação e o site são coisas diferentes, portanto os códigos deles devem ser versionados separadamente. Ter ambos em um mesmo repositório simplifica o gerenciamento.

Nós já ensinamos aqui no blog da TreinaWeb como criar páginas para repositórios no Github.

Para criar uma branch órfã basta usar o comando:

git checkout --orphan minha-branch-orfa

7 – Visualizando o Histórico de Commits

Para visualizar o histórico de commits basta usar o seguinte comando:

$ git log

Você ainda pode adicionar mais parâmetros a esse comando, como:

7.1 – Histórico de um ou mais arquivos

$ git log -p meus-arquivos

Você pode indicar nomes de arquivo ou de um diretório para ver o histórico apenas de um grupo de arquivos ao invés do projeto inteiro

7.2 – Histórico de um autor

Mostra o histórico de commits feitos por uma única pessoa

$ git log --autor=nome-autor

7.3 – Histórico por Data

Mostra o histórico de commits feitos antes ou após uma data:

$ git log --after="MMM DD YYYY"
$ git log --before="MMM DD YYYY"

Exemplo do formato usado nas datas: “Jul 07 2019”

7.4 – Histórico Baseado em uma Mensagem

Mostra o histórico de commits filtrado por uma mensagem

$ git log --grep produtos

Com esse comando teremos o histórico de commits em que a mensagem do commit possua a palavra “produtos”. O que passamos pode ser uma expressão regular, e podemos passar mais de uma:

// procurar por "produtos" OU "usuarios"
$ git log --grep produtos --grep usuarios

// procurar por "produtos" E "usuarios"
$ git log --grep produtos --and --grep usuarios

8 – Exibir branches em um modo mais legível

É possível mandar imprimir o histórico exibindo as branches do repositório com algo mais legível e com cores com um comando. Teremos um resultado parecido com esse:

* a102055 (HEAD -> master) commit 8
| * 196d28e (branch-2) commit 7
| * 07e073c commit 3
| * 2b077ca new fie
| | * c1369d8 (branch-3) commit 6
| | * d11bdcd commit 5
| |/
|/|
* | 2b22b75 commit 2
|/
* d5a12b0 .gitignore
* 9535426 -- commit 1

O comando é um pouco comprido:

git log --all --decorate --oneline --graph

Para decorar tudo o que devemos escrever depois de log, lembre-se de A DOG
– —all
– —decorate
– —oneline
– —graph

9 – Atalhos Personalizados

Podemos criar atalhos para não ficar escrevendo comandos grandes como o do exempo anterior.

9.1 – Criando atalhos personalizados

Para criar atalhos personalizados, basta adicionar uma configuração, passando o nome que você quiser para o alias.

Por exemplo, se eu quiser que o comando ensinado anteriormente fosse chamado a partir do atalho dog:

//deixar o comando disponível apenas no repositório atual
git config alias.dog "log --all --decorate --oneline --graph"
//deixar o comando global em sua máquina, ficando disponível para qualquer repositório
git config --global alias.dog "log --all --decorate --oneline --graph"

Como os comandos serão do Git, não precisamos ficar chamando-o. Note que o comando passado para o atalho não inicia com git.

Para remover os atalhos basta executar:

//atalhos locais
git config --unset alias.dog
//atalhos globais
git config --global --unset alias.dog

Agora podemos ter o comando do exemplo anterior apenas executando $ git dog.

9.2 – Listando atalhos personalizados

Para exibir uma lista de atalhos personalizados, podemos executar o comando git config -l, que lista todas as configurações do seu Git. O problema é que esse simples comando vai listar todas as configurações. Podemos fazer um comando mais sofisticado para ele listar apenas os nossos atalhos personalizados e ainda organizá-los em ordem alfabética:

git config -l | grep ^alias\. | cut -c 7- | sort

O comando é grande, mas tudo bem, pois agora você sabe criar atalhos, não é mesmo? Podemos, por exemplo, criar um atalho com o nome alias:

git config alias.alias "! git config -l | grep ^alias\. | cut -c 7- | sort"

Por comandos como grep e sort não serem do Git, tivemos que iniciar a linha de comando com !. Perceba que por causa disso, nossa primeira instrução teve que chamar o Git.

O $ git config -l lista as configurações do Git. Pegamos o retorno e passamos ao comando $ grep, que serve para fazer busca de textos. Como queremos os atalhos, que vimos que começa com “alias”, mandamos o grep buscar por tudo que começa com alias.. Para termos uma lista mais limpa, usamos o comando cut para remover a parte “alias.” do nome dos atalhos. Por fim, usamos o comando sort para ordenar nossos atalhos em ordem alfabética.

10 – Trabalhando em mais de uma coisa sem fazer commit

Pode haver momentos em que você precisa parar o que está fazendo e começar a trabalhar em outra tarefa. Porém, pode não ser bom fazer o commit de algo que ainda não foi finalizado para depois voltar nele, resultando em um commit que ficará no histórico mas que possui um código que não funciona. Nós podemos salvar essas alterações feitas mesmo sem precisar realizar um commit para depois voltar a trabalhar nela, o que é chamado de Stash (algo como “esconder” ou “acumular”).

Ao fazer isso, seu repositório voltará ao estado do último commit, e as alterações feitas anteriormente estarão “escondidas”.

10.1 – Salvando modificações em um Stash

Simplesmente execute o comando stash

$ git stash

Você ainda pode colocar um nome nesse stash:

$ git stash push -m meu-novo-stash

10.2 – Listando Stashes

Você pode fazer vários stashes. Para listá-los, execute o comando:

$ git stash list

10.3 – Recuperando modificações

Se algo foi salvo no stash, basta executar o seguinte comando para recuperar as alterações que foram jogadas lá:

$ git stash apply

Isso vai recuperar o código do stash mais recente. Se quiser recuperar um stash mais antigo, basta ver o número do stash que aparece quando o listamos e passar para o seguinte comando:

$ git stash apply stash@{2}

10.4 – Removendo Stashes

Quando nós recuperamos alterações de um stash, ele continua guardado. Para apagá-lo da pilha, execute o comando drop junto ao nome do stash que você quer remover:

$ git stash drop stash@{5}

Se você quiser recuperar o código de um stash e já apagá-lo, pode usar o comando pop no lugar do apply.

11 – Juntando alguns pedaços do trabalho

Pode ser que você esteja trabalhando em uma branch e queira fazer o merge do código dela com outra branch, mas não quer juntar o trabalho inteiro, apenas um commit específico. Isso é possível com o Cherry Pick.

git cherry-pick id-do-commit
Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

Como usar domínio personalizado no Github Pages

Já vimos aqui no blog um post sobre a utilização do Github Pages para criação de portfólio. Esse recurso por si só já é muito bom, pois evita a necessidade de um servidor pago para ter um site, mas ele fica ainda mais atraente com a utilização de domínios personalizados nessas páginas.

Por padrão, quando criamos um site no Github Pages o endereço utilizado para acessar a página possui o padrão: https://nome_do_usuario.github.io/nome_do_repositorio fica muito mais interessante se ao invés disso, usarmos por exemplo, para uma página pessoal o domínio relacionado ao seu perfil de desenvolvedor https://seunome.dev, no meu caso utilizo https://eltonfonseca.dev

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

Serviço de DNS

Quando compramos um domínio, precisamos de um serviço de DNS onde vamos criar as zonas. Alguns vendedores de domínio já possuem por padrão o serviço de DNS também, como é o caso do Google Domínio, dono dos domínios .dev, mas a maioria dos vendedores de domínio não possuem.

Primeiramente vamos ver como realizamos a configuração do domínio onde o vendedor não possui o serviço de DNS (como é o caso do registro.br, por exemplo). Nesse caso podemos usar a Cloudflare que possui plano gratuito. Acesse o link https://dash.cloudflare.com/sign-up para realizar o cadastro.

Depois de logado precisamos adicionar um novo site:

Informe o domínio do seu site:

Basta seguir os passos para terminar a adição, única coisa que precisa se atentar é o tipo de plano para selecionar gratuito.

Apontar o DNS no domínio

Agora precisa informar na empresa onde comprou o domínio qual é o servidor que será responsável pelos DNS. Acesse a página de Overview do seu site na Cloudflare, ele te apresentará quais nameservers deve usar:

Se o domínio foi comprado no registro.br, após logar basta clicar sobre ele e clicar no botão Alterar Servidores DNS. A configuração deve ficar conforme a imagem abaixo:

Se tiver comprado o domínio em outra empresa precisará verificar qual é o procedimento específico no sistema dela, geralmente isso é bem simples.

Adicionar zona de DNS na Cloudflare

Agora precisamos criar uma zona no Cloudflare que aponta para o IP do Github Pages, com isso toda vez que o usuário acessar no navegador https://eltonfonseca.dev ele retornará o caminho para a página. Vamos usar no nosso exemplo uma zona tipo A, mas poderíamos usar um ALIAS ou ANAME.

Acesse o menu DNS no painel do site no Cloudflare e em seguida adicione o seguinte registro:

Esse endereço de IP foi retirado da página da documentação do Github Pages. Ele ainda possui outros ips alternativos:

  • 185.199.108.153
  • 185.199.109.153
  • 185.199.110.153
  • 185.199.111.153

Basicamente terminamos a nossa configuração de DNS. Se a empresa onde comprou o domínio já possuir o gerenciador de DNS basta realizar esse último passo.

Veja no Google Domains como isso é feito:

Configurando o Github Pages

Precisamos configurar o Github para responder ao domínio personalizado que criamos. Depois de já ter o site funcionando com o endereço padrão (mostrado no post do início).

Acesse as configurações do repositório onde está o site:

Em seguida em GitHub Pages informe o seu domínio personalizado:

Depois de clicar em Save marque também a opção Enforce HTTPS para que os acessos aconteçam via HTTPS.

Podemos testar o site no navegador com o novo domínio:

Prontinho já temos o nosso site funcionando com domínio personalizado no Github Pages. Isso nos permite hospedar sites estáticos de forma extremamente simples sem ter que pagar um servidor de hospedagem ou realizar configurações complexas. O Github Pages possui algumas limitações e politicas de uso, antes de iniciar o seu uso pode ser interessante ler a documentação.

Hospedando o Portfólio criado com o Pingendo

No artigo anterior, Criando um Portfólio com o Pingendo, utilizamos a ferramenta para criar um Portfólio simples e rápido, para que você possa utilizá-lo para compartilhar suas experiências de maneira mais organizada na web.

Neste artigo estaremos hospedando este Portfólio de maneira gratuita.

Ferramenta utilizada

Utilizaremos o GitHub Pages para realizar esta hospedagem do nosso Portfólio.

O GitHub Pages é um website para que você possa hospedar seus projetos diretamente do seu repositório do GitHub.

Criando o repositório

O primeiro passo após logar em sua conta do GitHub é criar o repositório. Para isso, vamos até a página https://github.com/new e configuramos as preferências do repositório (nome, descrição e privacidade), como mostra a imagem abaixo:

Subindo a página

Neste passo será obrigatório o uso do Git instalado em sua máquina. Caso não o possua, você pode ver o processo de instalação e primeiros passos no seguinte artigo: Primeiros passos com Git.

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

Com o Git instalado e configurado, precisamos commitar o código-fonte da nossa página. Para isso, no GitBash e dentro da pasta do Portfólio, utilizamos os seguintes comandos:

git init
git remote add origin https://github.com/nome_do_usuario/nome_do_repositorio.git
git add .
git config --global user.email “seuemail@dominio.com”
git commit -m “Commit inicial”
git push -u origin master

Lembrando que você terá que alterar o nome do usuário e nome do repositório com base nas informações que foram obtidas no momento da criação do repositório, como mostra a imagem abaixo.

Ativando o GitHub Pages

Após commitar o código-fonte do Portfólio, vamos até a aba “Settings” e ao, final dela, ativaremos o GitHub Pages. Para isso, selecionamos a “Branch Master” como mostra as imagens abaixo:

Com isso, o Portfólio já está hospedado e disponível no seguinte endereço: https://nome_do_usuario.github.io/nome_do_repositorio/

Concluindo

Nesta série de artigos, vimos o quão fácil pode ser a criação e hospedagem de um Portfólio totalmente gratuito utilizando o GitHub Pages e Pingendo.

Git e GitHub: quais as diferenças?

Muitas pessoas pensam que Git e GitHub são a mesma coisa. Isso é uma dúvida comum principalmente de quem está começando. Entender cada um deles e como eles funcionam é importante, pois se não agora, uma hora você vai precisar.

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

O que é o Git?

O Git é um sistema de controle de versão de arquivos. É um software livre e muito utilizado no desenvolvimento de software onde diversas pessoas estão contribuindo simultaneamente, podendo criar e editar arquivos. Sempre quando alguém disponibiliza sua parte do projeto no Git, ele gerencia as alterações feitas e guarda um histórico. Isso é importante pois se houver algum problema você pode desfazer as alterações e voltar para a versão que estava estável.

O Git foi projetado e desenvolvido pelo Linus Torvalds para o desenvolvimento do Linux e foi adotado por muitos outros projetos.

Existem sites que provêm hospedagem gratuita de código fonte para repositório Git, um deles é o GitHub.

O que é o GitHub?

O GitHub é uma plataforma onde você pode armazenar seus projetos. É como se fosse uma rede social, só que de códigos, onde seus desenvolvedores podem disponibilizá-los para outras pessoas verem.

Quando seu projeto está no GitHub, você pode facilmente baixar uma cópia em outro computador. É uma plataforma gratuita e armazena milhões de projetos, tanto open source, pessoais e até mesmo comerciais. Alguns projetos bem conhecidos são o WordPress e o Linux. Hoje o GitHub pertence a Microsoft, que o adquiriu no ano de 2018.

Muitas pessoas utilizam o GitHub como portfólio de seu trabalho para que empresas possam vê-lo. Se você ainda não possui um GitHub e quer fazer parte, basta criar uma conta e um repositório.

O GitHub só suporta o Git, então para você subir seus projetos deve utilizá-lo, mas a integração entre eles é bem fácil. Agora caso queira utilizar somente o Git, não tem problema. Ao contrário do GitHub, o Git não depende do GitHub para ser utilizado.

Se você quiser aprofundar seus conhecimentos no Git e GitHub, conhecer os comandos e tudo mais, dá uma conferida no nosso curso 😊

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

Até mais!

As principais plataformas para armazenamento de código-fonte

Três grandes plataformas de controle de versão de código-fonte tem caído no gosto popular dos desenvolvedores. O GitHub, GitLab e BitBucket ganharam espaço com o passar do tempo e se tornaram aliados indispensáveis aos desenvolvedores para hospedarem seus códigos-fonte e disponibilizar seus projetos de forma simplificada.

Sendo assim, neste artigo veremos sobre cada um deles e suas características.

GitHub

O GitHub foi um dos pioneiros em hospedagem de repositórios Git, onde qualquer usuário que possua cadastro na plataforma pode contribuir com projetos privados ou Open Source. Possui grandes projetos hospedados, como por exemplo, WordPress, Atom, GNU/Linux, entre outros. Assim como consta em sua página inicial, todo desenvolvedor poderá hospedar, analisar, gerenciar projetos e construir softwares ao lado de 31 milhões de outros desenvolvedores e mais de 2,1 milhões de empresas e organizações que também utilizam o GitHub.

Em 4 de Julho de 2018 foi comprado pela Microsoft com valores estimados em cerca de US$ 7,5 bilhões.

Aqui no blog, possuímos um artigo bem legal sobre esta compra, que você pode conferir através do link:

https://www.treinaweb.com.br/blog/microsoft-compra-o-github-e-agora/

Mas, quais as maiores vantagens em se utilizar o GitHub?

A primeira delas é que a maioria dos projetos Open Source estão hospedados por lá, assim os desenvolvedores possuem uma grande quantidade de projetos para contribuir. Além disso, muitas empresas analisam seu histórico de contribuição em projetos, utilizando a ferramenta como meio de análise de perfil profissional.

Por seus quase 11 anos de existência e por ter sido o primeiro site de hospedagem de repositórios Git é, sem dúvida, o maior de todos eles, com diversos usuários e seus milhões de repositórios.

Além disso, caso você seja estudante, poderá usufruir de uma conta PRO do GitHub e ainda contar com diversas outras vantagens, como citado no artigo “Como obter uma licença para estudante no GitHub” que você pode conferir acessando o link abaixo:

https://www.treinaweb.com.br/blog/como-obter-uma-licenca-para-estudante-no-github/

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

GitLab

O GitLab, assim como o GitHub, também é uma plataforma para gerência e hospedagem de código fonte.

Possui uma interface simples e intuitiva e permite que qualquer usuário da plataforma possa criar repositórios privados e públicos de forma gratuita. Porém, os repositórios privados só podem ser contribuídos por uma quantidade limitada de usuários.

Diferente do GitHub, o GitLab é um projeto Open Source, mantido por toda comunidade. Além disso, permite que os desenvolvedores armazenem seus projetos em seus próprios servidores.

Possui múltiplos níveis de permissão (Convidado, Repórter, Desenvolvedor, Mestre e Dono), que serve para determinar os papéis de cada profissional no projeto, como podemos ver acessando o link abaixo:

https://docs.gitlab.com/ee/user/permissions.html

Possui também todo um conjunto de software para gerenciar seu projeto do início ao fim que, como eles se autodenominam, “A full DevOps tool”.

Aqui no blog, possuímos um artigo muito interessante sobre “O que é Devops” que você poderá conferir no link abaixo:

https://www.treinaweb.com.br/blog/afinal-o-que-e-devops/

Por fim, o GitLab permite que você desenvolva seus códigos online, utilizando um ambiente de desenvolvimento integrado (IDE) acoplado na ferramenta, fornecendo ao usuário colorização de sintaxe básica para uma variedade de linguagens de programação.

Além disso, possui IntelliSense e suporte de validação e formatação para as principais linguagens de script e marcação do mercado, como: TypeScript, JavaScript, CSS, LESS, SCSS, JSON e HTML.

BitBucket

O BitBucket, assim como o GitHub e o GitLab, é uma plataforma para hospedagem e gerência de código-fonte de projetos. Escrito em Python, o BitBucket é indicado para pequenas equipes com orçamento limitado, já que é uma opção mais barata e permite que sejam criados repositórios privados para até 5 desenvolvedores de forma gratuita.

Os preços do BitBucket são os mais acessíveis, se comparado ao GitHub e GitLab, possuindo três tipos de planos (Free, Standard e Premium) com os seguintes preços:

Possui integração com o Jira e o Trello, permitindo que os repositórios possam ser gerenciados a partir destas ferramentas.

O BitBucket possui suporte a integração contínua utilizando Pipelines, uma ferramenta que permite implantar, monitorar e confirmar seu código, para posteriormente, começar a planejar o próximo conjunto de modificações sem sair do BitBucket.

Concluindo

Vimos neste artigo, as três principais plataformas para gerenciamento e armazenamento de código-fonte, desta forma, cabe ao desenvolvedor escolher a que mais o agrada, levando em consideração suas características e particularidades.

Escolher um armazenador de código-fonte é uma forma simples e eficaz para que seus projetos sejam armazenados de forma organizada e que possam ser contribuídos por qualquer desenvolvedor, independente de sua localização.

Como obter uma licença para estudante no GitHub

O GitHub possui uma licença para estudantes que provê diversos recursos a alunos a partir dos 13 anos de idade que estejam devidamente matriculados em instituições de ensino. O Student Developer Pack tem como objetivo fornecer aos alunos o acesso gratuito às melhores ferramentas de desenvolvimento e neste artigo veremos como obter esta licença e quais as suas vantagens.

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

Criando uma conta

A partir do link https://education.github.com/pack é possível realizar seu cadastro sobre os seguintes passos:

Através do link do GitHub Education, você encontra uma breve descrição sobre o Student Developer Pack e motivos de sobra para concluir sua inscrição, como os serviços que serão disponibilizados para quem possuir esta licença. Ao clicar em “Get your Pack”, você será direcionado para a seguinte página:

É necessário para o GitHub saber se de fato você é estudante, já que a licença do Student Developer Pack é destinada exclusivamente para esta classe. Ao clicar no botão “Yes, I’m a student’, o próximo passo é preencher as informações, conforme cadastro mostrado abaixo.

O formulário acima possui dois tipos de cadastro: a partir do e-mail institucional e a partir de um comprovante de matrícula. Veremos abaixo como proceder em cada um dos casos.

E-mail institucional

Caso sua instituição de ensino forneça e-mail institucional clique no botão “Add an email address” e insira o endereço deste e-mail, informando o ano de sua graduação e como deseja utilizar o GitHub. Após isso, submeta as informações.

Algumas instituições de ensino fornecem de forma gratuita este tipo de e-mail, verifique se sua universidade se encaixa no fornecimento deste serviço, caso contrário, há uma segunda alternativa, na qual falaremos logo abaixo.

Comprovante de matrícula

A segunda opção é o upload do comprovante escolar atualizado ou qualquer documento que sua universidade/escola utiliza para comprovar sua matrícula ativa.

Ao clicar em “Upload proof of your academic status”, você poderá carregar o arquivo de comprovação escolar (o tipo de arquivo deverá ser gif, jpeg ou png), selecionar o e-mail da sua conta do GitHub, inserir o nome de sua escola, ano de graduação, como deseja utilizar GitHub e submeter seu pedido para análise.

Após envio, o GitHub fará uma análise das informações enviadas. O prazo estabelecido é de até 5 dias úteis, conforme exibido na página abaixo.

Vantagens

No total, 25 ferramentas fazem parte das vantagens oferecidas a partir da licença do Student Developer Pack.

Dentre as ferramentas temos: DigitalOcean, Heroku, Travis CI, Transifex, dentre outros. No link https://education.github.com/pack é possível visualizar todas estas ferramentas e o tipo do benefício, que poderá ser de 1 ano, 2 anos ou até o final do prazo da licença.

Após o prazo de 5 dias, você receberá um e-mail informando sobre o resultado do processo, conforme imagem abaixo.

Se este for positivo, sua conta já possuirá todos os privilégios de uma conta PRO do Github, com permissão para criar repositórios privados, além de todas as ferramentas disponíveis por seus parceiros.

Criando páginas para repositórios com o GitHub Pages

O GitHub é uma das maiores ferramentas para armazenamento e gestão dos nossos projetos. Ele possui um recurso bem interessante que facilita a divulgação e apresentação dos projetos lá hospedados. Este recurso é o GitHub Pages, que permite que criemos uma página web para nossos repositórios totalmente gratuita. Legal né? Então fica ligado que neste artigo veremos como criar uma página de apresentação para um repositório.

Git e GitHub - Controle de versão
Curso de Git e GitHub - Controle de versão
CONHEÇA O CURSO

Criando o repositório:

A primeira coisa a se fazer é criar um repositório no GitHub para que consigamos gerar a página web para ele. Para isso, vamos até a rota https://github.com/new e configuramos todas as suas preferências:

Nesta página vamos informar o nome do repositório, sua descrição e o tipo de visibilidade (público ou privado). Feito isso, clicamos no botão verde “Create repository”.

Ativando o GitHub Pages:

Após isso, o repositório será criado e seremos redirecionados para sua tela inicial. Lá, clicamos no botão “Settings” no menu superior da tela. A partir disso, seremos redirecionados para a tela de configurações do repositório que, dentre diversas configurações, existe uma seção chamada “GitHub Pages”, conforme podemos ver abaixo:

Nesta seção há duas opções. Podemos criar uma página a partir de um código presente no próprio repositório ou por meio de um modelo disponibilizado pelo próprio GitHub. Caso você queira desenvolver sua própria página, selecione a branch que você quer salvar seu arquivo index.html e clique no botão save (primeira parte da seção).

Selecionando o tema

Para este artigo, vamos selecionar um modelo disponibilizado pelo próprio GitHub. Sendo assim, clicamos no botão “Choose a theme”. Feito isso, uma nova página será aberta onde podemos ver a lista de todos os temas disponíveis para uso:

Agora é só selecionar o que você prefere e clicar no botão verde “Select Theme”. Feito isso, uma janela para que possamos customizar a página do nosso repositório será aberta. Vale lembrar que as informações são escritas em Markdown, por isso precisamos seguir este formato.

Após editar o conteúdo da nossa página, vamos até o final da mesma e clicamos em “Commit Changes”. Isso irá gerar um novo commit com as mudanças feitas.

Finalmente, após todos estes passos, já podemos acessar a página do repositório através da rota:

https://treinaweb.github.io/repositorio_teste_github_pages/

Concluindo:

Com isso, notamos o quão fácil é criar uma página de apresentação para nossos repositórios de forma totalmente gratuita. Podemos, também, utilizar projetos um pouco mais complexos utilizando HTML, CSS e JavaScript, mas isso fica para um próximo artigo, ok? 🙂

Um abraço e até lá!