Pular para o conteúdo
Athena

Como utilizamos o Github?

Documento Padrão GitHub versão 1.0 - COMP JÚNIOR

Índice
  1. Introdução
  2. O que é o GIT e GITHUB
  3. Como instalar o GIT
  4. Glossário
  5. README.md
  6. Branches
  7. Mensagens de Commit
  8. Comandos Git
  9. GITIGNORE

Introdução

    Essa é a documentação oficial para a padronização do GitHub na Comp Júnior. Aqui você irá encontrar conceitos iniciais como comandos, bom uso de branches e mensagens, uso do .gitignore adequadamente e por fim a criação de um bom README.

    O intuito deste documento é ser um sucessor espiritual do Git4Comp encontrado no repositório docs. Neste documento reunimos tudo que é necessário em um só lugar.

O que é o GIT e GITHUB

Git e github são essenciais para o desenvolvimento colaborativo, mas afinal, o que são?

Git

  • De forma simples o Git é um sistema para controle de versão, ele é o sistema responsável por mapear toda alteração em arquivos. Logo quando existem várias pessoas alterando o mesmo projeto, é o git que fica responsável por verificar tudo o que está ocorrendo. Para isso, o git necessita da criação de branches, ou seja, ambientes de um mesmo código isolados para uma alteração responsável sem o risco de informações serem sobrescritas.

GitHub

  • Assim como está no nome o GitHub é responsável por agregar todo o sistema Git em um só lugar, hospedando repositórios online, permitindo às pessoas e organizações, assim como a Comp Júnior, conectar todos os colaboradores sem a necessidade de um servidor próprio.

Lembrando que isso é apenas um resumo, sendo altamente recomendado ler a documentação oficial e buscar cursos online.

Como instalar o GIT

Windows:

  • Vá até o site Git SCM, faça download da versão mais atualizada e siga os passos do instalador. Ao terminar o download você terá o app Git Bash instalado no seu Windows pronto para uso.

Linux:

  • Debian / Ubuntu: 
    sudo apt install git
  • Archlinux: 
    sudo pacman -S git
  • Fedora: 
    sudo dnf install git-
  • openSuse: 
    zypper addrepo https://download.opensuse.org/repositories/openSUSE:Factory/standard/openSUSE:Factory.repo
    zypper refresh
    zypper install git

Glossário

  • fork - Cópia de um repositório para a sua própria conta no GitHub. Isso cria um novo repositório em sua conta que é independente do original, permitindo que você faça alterações sem afetar o repositório original.

  • issues - Ferramenta usada para gerenciar tarefas, pedidos de novos recursos e correções de bugs em projetos de código aberto. As issues devem ser descritas e listadas, permitindo aos colaboradores discutirem e rastrearem o progresso das mesmas.

  • pull request - Mecanismo usado para submeter alterações propostas ao repositório original. Um pull request é uma solicitação para que os mantenedores do projeto revisem e potencialmente incorporem as alterações. O pull request passará por um processo de avaliação e pode ser aceito ou rejeitado.

  • gist - Ferramenta que permite o compartilhamento de trechos de código sem a necessidade de criar um repositório completo. Gists podem ser compartilhados publicamente ou de forma privada.

README.md

Todo projeto feito na Comp Júnior deve apresentar um README bem estruturado. Para isso é de extrema importancia os seguintes requisitos:

  • SEMPRE apresentar índice no início;

  • SEMPRE manter informado os seguintes links no início do README:

    • Documento de requisitos;
    • Protótipo de alta e baixa fidelidade;
    • Backlog do produto;
    • Roadmap do produto.

  • O README deve SEMPRE conter as seguintes mensagens:

    • “Esse repositório está usando o [Padrão GitHub versão X.X] (LINK)”;
    • “Esse repositório está usando o [Padrão de desenvolvimento versão X.X] (LINK)”;

  • Sempre conter os Pré-requisitos especificados;

    • Ex.: Node.js com instruções de como instalar no linux/windows

  • Etapas de instalação do projeto;

    • Exemplo: 
       node install
         node app.js

  • Dependendo do tamanho do projeto será necessário demonstrar a Modelagem de Dados. A modelagem de dados é essencial para garantir a integridade e consistência dos dados da aplicação, bem como para facilitar a interação entre os diferentes componentes do sistema.

    • Diagrama de Entidade;
      • Pode ser feito em qualquer ferramenta, porém recomendamos dbdiagram.io

Branches

   O Seguinte padrão de branches foi baseado em duas documentações:

   O repositório sempre irá fazer uso contínuo de 2 ou 3 branches dependendo do projeto e de como o squad escolher lidar.

MAIN / MASTER
FRONT
BACK

   A branch MAIN / MASTER é atualizada somente por meio de pull requests vindo das branches fixas de desenvolvimento. Nunca deverá ser atualizada diretamente pelo desenvolvedor.

   A(s) outra(s) branch(es) fixas servirá como um ambiente de desenvolvimento, ou seja, sempre que houver as chamadas branches de auxilio será realizado o MERGE para esse ambiente.

   Antes de ser realizado o MERGE do PULL REQUEST será necessário a avaliação do que foi feito por outro membro do squad ( ressalva somente quando for algum aspecto pequeno como alteração de cor em uma div ).

   O desenvolvedor do projeto deverá necessariamente criar branches de auxilio para a inclusão de uma FEATURE / BUGFIX / HOTFIX / REFACTOR.

A nomeclatura da branch deverá seguir o seguinte padrão:

 feature/feature-name <br />
 feature/feature-area/feature-name <br />
 hotfix/description <br />
refactor/description <br />

Feature Branch

As Feature Branch são utilizadas quando se está desenvolvendo uma MELHORIA ou FUNCIONALIDADE nova para o projeto.

BUGFIX Branch

As Bugfix Branch são utilizadas quando se é necessario solucionar um bug, por está razão normalmente é uma branch mais rápida de ser implementada no codigo central. O uso dessa branch é similar ao da feature.

HOTFIX Branch

As Hotfix Branch são utilizadas somente quando se há a necessidade de uma solução rápida diretamente na main branch.

REFACTOR Branch

As Refactor Branch são utilizadas quando se há o intuito de alterar o codigo/estrutura buscando melhoria de qualidade. Somente usada quando NÃO se tem necessidade de alteração das FUNCIONALIDADES do projeto

Mensagens de commit

Levaremos como base o Conventional Commits utilizando o texto da documentação detalhada em iuricode/padroes-de-commits

Padrões de commits 📜

De acordo com a documentação do Conventional Commits, commits semânticos são uma convenção simples para ser utilizada nas mensagens de commit. Essa convenção define um conjunto de regras para criar um histórico de commit explícito, o que facilita a criação de ferramentas automatizadas.

Esses commits auxiliarão você e sua equipe a entenderem de forma facilitada quais alterações foram realizadas no trecho de código que foi commitado.

Essa identificação ocorre por meio de uma palavra e emoji que identifica se aquele commit realizado se trata de uma alteração de código, atualização de pacotes, documentação, alteração de visual, teste…

Tipo e descrição 🦄

O commit semântico possui os elementos estruturais abaixo (tipos), que informam a intenção do seu commit ao utilizador(a) de seu código.

  • feat- Commits do tipo feat indicam que seu trecho de código está incluindo um novo recurso (se relaciona com o MINOR do versionamento semântico).

  • fix - Commits do tipo fix indicam que seu trecho de código commitado está solucionando um problema (bug fix), (se relaciona com o PATCH do versionamento semântico).

  • docs - Commits do tipo docs indicam que houveram mudanças na documentação, como por exemplo no Readme do seu repositório. (Não inclui alterações em código).

  • test - Commits do tipo test são utilizados quando são realizadas alterações em testes, seja criando, alterando ou excluindo testes unitários. (Não inclui alterações em código)

  • build - Commits do tipo build são utilizados quando são realizadas modificações em arquivos de build e dependências.

  • perf - Commits do tipo perf servem para identificar quaisquer alterações de código que estejam relacionadas a performance.

  • style - Commits do tipo style indicam que houveram alterações referentes a formatações de código, semicolons, trailing spaces, lint… (Não inclui alterações em código).

  • refactor - Commits do tipo refactor referem-se a mudanças devido a refatorações que não alterem sua funcionalidade, como por exemplo, uma alteração no formato como é processada determinada parte da tela, mas que manteve a mesma funcionalidade, ou melhorias de performance devido a um code review.

  • chore - Commits do tipo chore indicam atualizações de tarefas de build, configurações de administrador, pacotes… como por exemplo adicionar um pacote no gitignore. (Não inclui alterações em código)

  • ci - Commits do tipo ci indicam mudanças relacionadas a integração contínua (continuous integration).

  • raw - Commits to tipo raw indicam mudanças relacionadas a arquivos de configurações, dados, features, parametros.

  • cleanup - Commits do tipo cleanup são utilizados para remover código comentado, trechos desnecessários ou qualquer outra forma de limpeza do código-fonte, visando aprimorar sua legibilidade e manutenibilidade.

  • remove - Commits do tipo remove indicam a exclusão de arquivos, diretórios ou funcionalidades obsoletas ou não utilizadas, reduzindo o tamanho e a complexidade do projeto e mantendo-o mais organizado.

Recomendações 🎉

  • Adicione um tipo consistente com o título do conteúdo.
  • Recomendamos que na primeira linha deve ter no máximo 4 palavras.
  • Para descrever com detalhes, usar a descrição do commit.
  • Usar um emoji no início da mensagem de commit representando sobre o commit.
  • Os links precisam ser adicionados em sua forma mais autêntica, ou seja: sem encurtadores de link e links afiliados.

Complementos de commits 💻

  • Rodapé: informação sobre o revisor e número do card no Trello ou Jira. Exemplo: Reviewed-by: Elisandro Mello Refs #133
  • Corpo: descrições mais precisas do que está contido no commit, apresentando impactos e os motivos pelos quais foram empregadas as alterações no código, como também instruções essenciais para intervenções futuras. Exemplo: see the issue for details on typos fixed.
  • Descrições: uma descrição sucinta da mudança. Exemplo: correct minor typos in code

Padrões de emojis 💈

Tipo do commitEmojiPalavra-chave
Acessibilidade♿ :wheelchair:
Adicionando um teste✅ :white_check_mark:test
Atualizando a versão de um submódulo⬆️ :arrow_up:
Retrocedendo a versão de um submódulo⬇️ :arrow_down:
Adicionando uma dependência➕ :heavy_plus_sign:build
Alterações de revisão de código👌 :ok_hand:style
Animações e transições💫 :dizzy:
Bugfix🐛 :bug:fix
Comentários💡 :bulb:docs
Commit inicial🎉 :tada:init
Configuração🔧 :wrench:chore
Deploy🚀 :rocket:
Documentação📚 :books:docs
Em progresso🚧 :construction:
Estilização de interface💄 :lipstick:feat
Infraestrutura🧱 :bricks:ci
Lista de ideias (tasks)🔜 :soon:
Mover/Renomear🚚 :truck:chore
Novo recurso✨ :sparkles:feat
Package.json em JS📦 :package:build
Performance⚡ :zap:perf
Refatoração♻️ :recycle:refactor
Limpeza de Código🧹 :broom:cleanup
Removendo um arquivo🗑️ :wastebasket:remove
Removendo uma dependência➖ :heavy_minus_sign:build
Responsividade📱 :iphone:
Revertendo mudanças💥 :boom:fix
Segurança🔒️ :lock:
SEO🔍️ :mag:
Tag de versão🔖 :bookmark:
Teste de aprovação✔️ :heavy_check_mark:test
Testes🧪 :test_tube:test
Texto📝 :pencil:
Tipagem🏷️ :label:
Tratamento de erros🥅 :goal_net:
Dados🗃️ :card_file_box:raw

💻 Exemplos

Comando GitResultado no GitHub
git commit -m “:tada: Commit inicial”🎉 Commit inicial
git commit -m “:books: docs: Atualização do README”📚 docs: Atualização do README
git commit -m “:bug: fix: Loop infinito na linha 50”🐛 fix: Loop infinito na linha 50
git commit -m “:sparkles: feat: Página de login”✨ feat: Página de login
git commit -m “:bricks: ci: Modificação no Dockerfile”🧱 ci: Modificação no Dockerfile
git commit -m “:recycle: refactor: Passando para arrow functions”♻️ refactor: Passando para arrow functions
git commit -m “:zap: perf: Melhoria no tempo de resposta”⚡ perf: Melhoria no tempo de resposta
git commit -m “:boom: fix: Revertendo mudanças ineficientes”💥 fix: Revertendo mudanças ineficientes
git commit -m “:lipstick: feat: Estilização CSS do formulário”💄 feat: Estilização CSS do formulário
git commit -m “:test_tube: test: Criando novo teste”🧪 test: Criando novo teste
git commit -m “:bulb: docs: Comentários sobre a função LoremIpsum( )”💡 docs: Comentários sobre a função LoremIpsum( )
git commit -m “:card_file_box: raw: RAW Data do ano aaaa”🗃️ raw: RAW Data do ano aaaa
git commit -m “:broom: cleanup: Eliminando blocos de código comentados e variáveis não utilizadas na função de validação de formulário”🧹 cleanup: Eliminando blocos de código comentados e variáveis não utilizadas na função de validação de formulário
git commit -m “:wastebasket: remove: Removendo arquivos não utilizados do projeto para manter a organização e atualização contínua”🗑️ remove: Removendo arquivos não utilizados do projeto para manter a organização e atualização contínua

Comandos GIT

Os seguintes comandos foram retirados do repositório Git-Commands

Obtendo e Criação de Projetos

ComandoDescrição
git initInicializa um repositório Git local
git clone ssh://git@github.com/[usuario]/[nome-repositorio].gitCria uma cópia local de um repositório remoto

Básicos

ComandoDescrição
git statusCheca o status
git add [nome-arquivo.txt]Adiciona um arquivo para área de stage
git add -AAdiciona todos os arquivos novos ou modificados para a área de stage
git commit -m "[Mensagem de Commit]"Comita as alterações
git rm -r [nome-arquivo.txt]Remove um arquivo (ou pasta)

Branching e Merging

ComandoDescrição
git branchLista as branches (o asterisco denota a branch atual)
git branch -aLista todas as branches (local e remoto)
git branch [nome da branch]Cria uma nova branch
git branch -d [nome da branch]Deleta uma branch
git push origin --delete [nome da branch]Deleta uma branch remota
git checkout -b [nome da branch]Cria uma nova branch e muda para ela
git checkout -b [nome da branch] origin/[nome da branch]Clona uma branch remota e muda para ela
git checkout [nome da branch]Seleciona uma branch
git checkout -Muda para a última branch
git checkout -- [nome-arquivo.txt]Descarta modificações de um arquivo
git merge [nome da branch]Faz um merge de uma branch na branch atual
git merge [source branch] [branch alvo]Faz um merge de uma branch em outra branch
git stashTirar o estado sujo do seu diretório de trabalho
git stash clearRemove todas as entradas ‘stash’

Compartilhando e Atualizando Projetos

ComandoDescrição
git push origin [nome da branch]Enviar uma branch para seu repositório remoto
git push -u origin [nome da branch]Envia as alterações da branch informada para um repositório remoto (and selecionar a branch)
git pushEnvia as alterações para o repositório remoto (branch atual)
git push origin --delete [nome da branch]Deletar uma branch remota
git pullAtualiza o repositório local para o último commit
git pull origin [nome da branch]Recebe alterações do repositório remoto
git remote add origin ssh://git@github.com/[usuario]/[nome-repositorio].gitAdicionar um repositório remoto
git remote set-url origin ssh://git@github.com/[usuario]/[nome-repositorio].gitSeta um repositório da origin branch para o SSH

Inspeção e Comparação

ComandoDescrição
git logVer modificações
git log --summaryVer modificações (detalhadas)
git diff [branch original] [branch alvo]Visualizar alterações antes de mesclar

GITIGNORE

O arquivo .gitignore é usado para especificar arquivos e pastas das quais o desenvolvedor não quer que seja rastreadas pelo git.

  • Um exemplo de uso comum seria o node_modules. Sabendo que envia-la para o git causa apenas um gasto desnecessário

Para um melhor entendimento sobre isso é recomendado ler a documentação oficial.

  • Entidades;
    • Explicação de todos os componentes do diagrama de entidade
  • Relacionamentos
    • Explicação de todos os relacionamentos dos componentes