GitHub

Github: Pare com as senhas e utilize Tokens de Acesso

Olá Web Developers! Já tem alguns anos que o Github incentiva a troca das senhas por Tokens de Acesso, mas ainda é muito comum que as pessoas utilizem suas senhas. Aqui veremos por que usar os tokens e como é simples começar a utilizá-los.

O que é esse Token de Acesso?

Um token de acesso, de forma simplificada, seria uma chave em um formato como e962e591092e9830f8ec6c2a4166e8655b768e88 que te permite ter acesso a algo. No caso do Github você usaria uma chave assim no lugar da senha da sua conta ao executar operações pela linha de comando ou na API.

Qual a vantagem em relação à minha senha?

A sua senha dá acesso a tudo em sua conta. Quem tiver sua senha pode apagar seus repositórios, alterar seus dados, fazer commits para qualquer repositório privado onde você possui permissões, apagar sua conta, etc. Concorda que se sua senha vazar ou se alguém tiver acesso a uma máquina onde sua senha está salva, esta pessoa terá muito poder?

Já os Tokens de Acesso te dão mais controle. Você pode criar vários e configurar as permissões que cada um vai ter. Se por algum motivo ele vazar, a sua conta continua salva. Se alguém tiver acesso a uma máquina onde seu token está salvo, a pessoa estará limitada a fazer apenas as ações que você liberou para aquele token. E com apenas um clique você pode apagar o token que quiser.

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

O Token de Acesso é algo simples que pode melhorar na sua segurança. Além disso, já faz um tempo que o Github vem avisando que logo desabilitará a autenticação por senha ao utilizar a linha de comando ou a API.

Como criar e usar um Token de Acesso?

Primeiro você precisa que o email da sua conta já tenha sido verificado. Depois, em https://github.com clique na sua foto do perfil e vá em Settings. No lado esquerdo você verá Developer settings. Clique nessa opção e depois em Personal access tokens.

Na parte superior da página você terá um botão para criar seus tokens, Generate new token. Ao clicar nele você pode dar um nome para o novo token, como Trabalho, Projeto da Faculdade, etc.

No restante da página você poderá selecionar as permissões que quer dar para esse token. Para selecionar seus repositórios pela linha de comando, selecione o repo.

No final da página, ao clicar em Generate token, seu token será gerado e exibido para você. Copie agora e guarde em um lugar seguro. Por motivos de segurança, assim que sair dessa página, você nunca mais verá esse token novamente. Se perder, basta criar outro.

Agora, quando for usar a linha de comando para fazer operações de Git ou quando for criar uma aplicação que usa a API do Github, basta usar esse token no lugar da sua senha.

O Token de Acesso funciona apenas para operações HTTPS, não servindo para SSH.

Como criar um Project Board utilizando o GitHub

No artigo anterior, listamos 5 utilidades do GitHub que provavelmente alguns usuários desconhecem e em um dos nossos tópicos abordamos a criação de Project Board.

Caso você não saiba, os project boards ou “quadros de projetos” são uma excelente forma de acompanhar todo o passo a passo das atividades que serão desenvolvidas ao decorrer de todo projeto. É uma forma visual de listar todas as atividades e inseri-las em cards, como por exemplo, listando as que foram feitas e as que ainda estão em pendência.

O Trello é a plataforma mais famosa para realizar este tipo de atividade onde, através de quadros, listas ou cartões, você consegue organizar e priorizar seus projetos de maneira mais flexível.

Mas o GitHub também detém desta ferramenta, o que permite ainda mais facilidade no decorrer de todo projeto, pois, por já se encontrar na plataforma para compartilhamento de seus códigos, você já consegue definir as atividades que serão desenvolvidas ao longo do seu projeto e acompanhar toda a sua evolução na mesma ferramenta.

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

Vamos ao passo a passo?

O primeiro passo é a criação do seu projeto no GitHub. Após criado, iremos clicar sobre o repositório, onde aparecerá as seguintes opções:

Basta clicar sobre “Projects” e logo após em “Create a project”.

Utilizei um projeto fictício de um “APP Pet”. Desta forma, diversas tarefas a serem implementadas ao decorrer do projeto podem ser utilizadas como exemplo na criação dos nossos projects boards.

O segundo passo após clicar sobre “create project”, é inserir o nome do nosso Project board, a descrição e o modelo do projeto. Não utilizarei nenhum, pois criaremos nossas próprias tabelas, conforme a necessidade do projeto em questão.

Desta forma, basta clicar em “create project” para que seja criado.

Após criar o nosso project board, basta inserirmos as colunas necessárias. Neste projeto, utilizarei 3 delas: A fazer, fazendo e feito, mas você poderá defini-las conforme a sua necessidade.

Lembrando que todo o processo relatado neste artigo, é feito de forma manual, porém, o próprio GitHub provê features para automatizar o processo de novos cards, como por exemplo, a criação de um card para cada issues do projeto. 🙂

Após criadas todas as tabelas conforme imagem abaixo, iremos inserir nossas atividades que serão desempenhadas ao decorrer do projeto. Basta clicar sobre a coluna para inserir as atividades a serem desempenhadas.

Pronto! Após criadas, basta apenas mover os cards entre as tabelas e ao decorrer de todo andamento do projeto, acompanhar toda a evolução do mesmo de maneira rápida e simples, sem ter a necessidade de utilizar uma segunda ferramenta para isto.

Lembrando que utilizamos o método manual e mais simples para criação dos nossos cards, mas conforme dito acima, existe a forma ainda mais prática que é definir nas configurações das nossas colunas, métodos de automatizar todo processo.

E você? Utiliza esta opção no GitHub? Conte pra gente e até o próximo artigo! 🙂

5 utilidades do GitHub

O GitHub é uma das mais conhecidas plataformas de hospedagem de código-fonte com controle de versão utilizando o Git. É mundialmente utilizado por diversos programadores cadastrados na plataforma que contribuem diariamente com seus projetos privados ou Open Source.

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

Possui grandes projetos hospedados, como, por exemplo, WordPress, Atom, GNU/Linux, entre outros. 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.

Porém, além do GitHub fornecer um serviço para hospedagem de código fonte, a plataforma possui ainda diversos outros recursos que provavelmente muitos usuários desconhecem. Neste artigo falaremos de 5 dos principais.

Edição de código

Ao acessar o GitHub, é possível editar os seus códigos de maneira simples e rápida.

Isso facilita quando o desenvolvedor precisa fazer uma alteração rápida em um projeto. Para isto, basta clicar sobre o arquivo que deseja editar, conforme a imagem abaixo:

Após o arquivo aberto, clique sobre a “canetinha” à esquerda, conforme imagem abaixo:

Realize a alteração necessária em seu código:

Por fim, realize o commit das alterações, adicionando a descrição e seu código será alterado no repositório.

GitHub Wiki

Com o GitHub Wiki é possível criar uma “documentação” do seu projeto, fornecendo informações diversas sobre seu repositório.

Para criar o Wiki do seu projeto, basta clicar sobre a aba “wiki”, conforme a imagem abaixo, e clicar sobre o botão “Create the first page”:

Na página seguinte, insira o conteúdo desejado e clique sobre o botão “Save Page”. Vale observar que o próprio GitHub já possui formas de editar o texto, adicionando estilos e assim melhorando a forma da visualização dos dados.

Este recurso é muito utilizado para descrição geral de um projeto, lista de versões e suas alterações, passos para instalação do projeto, lista de contribuidores, etc.

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

Criar listas de tarefas

Uma outra funcionalidade provida pelo GitHub é a criação de lista de tarefas para descrever as funcionalidades a serem desenvolvidas no projeto. Estas listas auxiliam o desenvolvedor a gerenciar as novas funcionalidades ou correções que devem ser implementadas.

Para criar uma lista de tarefas, clique sobre a aba “Issues” do repositório e selecione a opção “New issue”, conforme a imagem abaixo:

Feito isso, você poderá descrever sua lista de tarefas para o projeto. Para criar uma lista com checkbox, clique sobre o botão marcado na imagem abaixo e informe a descrição desta tarefa.

Feito isso, clique sobre o botão “Submit new issue” e a lista de tarefas estará pronta. Ao realizar a tarefa, basta marcar o checkbox que o GitHub salvará as alterações automaticamente.

GitHub Pages

O GitHub Pages é um recurso que permite criarmos uma página web estática para nossos repositórios totalmente gratuita.

Temos aqui no blog um artigo de como criar páginas para repositórios com o GitHub Pages, e caso esteja interessado, recomendo a leitura e o passo a passo.

Criar project boards

Sim! Esta é uma outra funcionalidade do GitHub.

Com ela podemos gerenciar de maneira mais fácil nossos projetos no próprio repositório, fazendo com que o mesmo funcione similar ao que fazemos quando utilizamos o Trello.

Desta forma, torna-se algo extremamente útil na hora de desenvolver, como podemos ver na imagem abaixo:

No próximo artigo, falarei a respeito desta funcionalidade e demonstrarei como criar seus project boards. 🙂

Extra: Obtendo licença de estudante no GitHub

Caso você esteja matriculado em alguma instituição de ensino e tenha idade maior que 13 anos, o GitHub disponibiliza a licença para estudantes que provê diversos recursos.

No total, dezenas de 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, e o benefício poderá ser de 1 ano, 2 anos ou até o final do prazo da licença.

O artigo “Como obter uma licença para estudante no GitHub” te auxilia em como obter esta licença e as vantagens em tê-la.

Criando release no GitHub

Uma das mais conhecidas plataformas de hospedagem de código-fonte com controle de versão utilizando o Git, o GitHub, hoje pertencente à Microsoft, é mundialmente utilizado por diversos programadores cadastrados na plataforma que contribuem diariamente com seus projetos privados ou Open Source.

Dentro da plataforma há diversos recursos para gerenciar nossos projetos. Um destes recursos é a criação de releases de um software.

Neste artigo veremos o que são e como criar releases no GitHub.

O que são Release?

Release são versões de um software. Quando estamos desenvolvendo uma aplicação, é comum que a disponibilizamos entre versões. Essas versões, no GitHub, são chamadas de Releases.

Por exemplo, imagine que você está desenvolvendo um software clínico e programou todas as funcionalidades necessárias para lançar a versão 1.0 da sua aplicação. Neste momento, você geraria um release com a versão 1.0 do software que conteria todo o código-fonte.

Depois de um tempo, com a inclusão de novas funcionalidades, chegou o momento de lançar a versão 2.0 da aplicação. Agora, você geraria um release da versão 2.0 do software contendo a inclusão das novas funcionalidades.

Sendo assim, sempre que você quiser lançar uma nova versão contendo alterações ou inclusões de novas funcionalidades em um software, novas releases serão lançadas.

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

Gerando Releases

O primeiro passo é abrir o repositório do projeto no GitHub e clicar sobre o botão “RELEASES” como mostrado abaixo:

Após isso, na página a seguir, clicaremos sobre o botão “CREATE A NEW RELEASE”. É nesta página que todos os releases do projeto serão listados.

Agora basta apenas informar o número da versão que a release representará, qual branch será utilizada como base para criação da release, um título para esta release e um texto descrevendo esta nova versão do software.

Após informar todos os dados, basta clicar sobre o botão “PUBLISH RELEASE”.

Feito isso, a release estará disponível e pronta para ser baixada.

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.

Testando localmente as suas actions

Você pode usar a ferramenta act para localmente testar as suas actions. Incrível, não?

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.