|
|
|
|[Home](home)|[Sprints](sprints)|[Requisitos](Requisitos)|[Arquitetura](Arquitetura)|[Configuração](configuracao)|[Endpoints](endpoints)|[Mockups](mockups)|[Problemas](problemas)
|
|
|
|
|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
|
|
|
|
|
|
|
|
# Visão Geral
|
|
|
|
O projeto é divido em 3 repositórios:
|
|
|
|
|
|
|
|
* [Wiki](http://www.tools.ages.pucrs.br/dietoterapia/wiki): repositório da wiki deste projeto (você está aqui 😄);
|
|
|
|
* [Front](http://www.tools.ages.pucrs.br/dietoterapia/front): desenvolvimento do front end;
|
|
|
|
* [Back](http://www.tools.ages.pucrs.br/dietoterapia/back): desenvolvimento da REST API;
|
|
|
|
<br ><br >
|
|
|
|
|
|
|
|
# Setup do git
|
|
|
|
|
|
|
|
- Notebook da AGES
|
|
|
|
|
|
|
|
Os computadores da AGES já vem com git instalado, portanto, basta [clonar](#clonar) o repositório desejado.
|
|
|
|
|
|
|
|
- Notebook pessoal
|
|
|
|
|
|
|
|
Se você estiver com seu computador pessoal, instale o [GitBash](https://git-scm.com/download/win) e tudo ~~deve~~ vai funcionar.
|
|
|
|
<br ><br >
|
|
|
|
|
|
|
|
# Tutorial de Git (Got 15 minutes and want to learn Git?)
|
|
|
|
Mini tutorial do GitHub ensinando os básicos para a utilização do Git Bash ou terminal do linux, tutorial direto no browser.
|
|
|
|
https://try.github.io/levels/1/challenges/1
|
|
|
|
<br ><br >
|
|
|
|
|
|
|
|
# [A simple git branching model](https://gist.github.com/jbenet/ee6c9ac48068889b0912)
|
|
|
|
|
|
|
|
Neste projeto usaremos "A simple git branching model" como gitflow, como o nome indica é um flow bastente simples, entretanto funciona muito bem.
|
|
|
|
|
|
|
|
O nosso gitflow consiste em criar branchs de features para desenvolver novas features e branchs de fix. Estar branchs serão eventualmente combinadas à branch dev. <br >
|
|
|
|
Todos nossos merges serão feitos na branch _dev_ e a cada entrega os arquitetos da equipe a integrarão à branch _homo_.
|
|
|
|
|
|
|
|
Passos detalhados do nosso fluxo utilizando o GIT bash:
|
|
|
|
|
|
|
|
<a name="clonar"></a>
|
|
|
|
Antes de qualquer coisa precisamos clonar o repositório para isso vamos ao repositório que queremos clonar, pegamos o endereço deles e utilizamos o comando<br >
|
|
|
|
|
|
|
|
>`git clone <REP_URL>`
|
|
|
|
|
|
|
|
Para clonar o repositório do front-end, por exemplo, utilizamos o seguinte comando:
|
|
|
|
>`git clone -b dev http://www.tools.ages.pucrs.br/dietoterapia/front` <br >
|
|
|
|
(Note que utilizamos "-b dev", este parâmetro faz com que clonemos o projeto na branch _dev_)
|
|
|
|
|
|
|
|
## Começando a desenvolver uma task
|
|
|
|
|
|
|
|
Bom, agora temos nosso repositório, antes de começarmos a trabalhar precisamos garantir que estamos na branch correta e estamos com a versão mais atual do projeto. Para isso usaremos os seguintes comandos:
|
|
|
|
|
|
|
|
>`git fetch` <br >
|
|
|
|
(Este comando irá atualizar o remoto)
|
|
|
|
|
|
|
|
>`git checkout dev` <br >
|
|
|
|
(Este comando vai fazer com que mudemos para a branch dev)
|
|
|
|
|
|
|
|
>`git pull` <br >
|
|
|
|
(Caso a versão local da _branch_ esteja desatualizada este comando irá aplicar as alterações novas)
|
|
|
|
|
|
|
|
|
|
|
|
Neste momento temos o repositório atualizado então vamos começar a trabalhar em uma nova feature, para isso criaremos uma branch de feature com este comando:
|
|
|
|
|
|
|
|
>`git checkout -b feature/<TASK_NAME>` <br>
|
|
|
|
(Note que TASK_NAME seria o nome da feature que você irá desenvolver)
|
|
|
|
|
|
|
|
Agora estamos prontos para começar a _codar_. Yay! 🤓
|
|
|
|
Para que nosso flow funcione muito bem usaremos [commits atômicos](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_Commit_Convention) e incrementais, ou seja, criaremos um commit para cada vez que tenhamos uma mudança funcional no código.
|
|
|
|
|
|
|
|
## Salvando suas alterações
|
|
|
|
O fluxo para criar commits é o seguinte:
|
|
|
|
|
|
|
|
>`git status` <br >
|
|
|
|
(Para visualizar quais arquivos foram alterados)
|
|
|
|
|
|
|
|
Agora podemos adicionar apenas os arquivos que desejamos ao commit, ou adicionar todos.
|
|
|
|
|
|
|
|
>`git add <FILE_PATH>` <br >
|
|
|
|
(Para adicionar um arquivo específico)
|
|
|
|
|
|
|
|
>`git add .` <br >
|
|
|
|
(Para adicionar todos os arquivos alterados)
|
|
|
|
|
|
|
|
Criar um commit com as suas alterações
|
|
|
|
>`git commit -m "<COMMIT_MESSAGE>"`
|
|
|
|
|
|
|
|
Ufa! Terminamos nosso trabalho de desenvolvimento, mas e agora?! No nosso projeto utilizamos <strike>pull</strike> merge request para com a branch de desenvolvimento, isto significa que todos nós não somos responsáveis por lidar com merges, então iremos pegar nossa branch e criar um merge request para a branch de desenvolvimento.
|
|
|
|
|
|
|
|
*/ TODO: Merge Request */
|
|
|
|
|
|
|
|
Se não usássemos pull requests utilizaríamos os seguintes passos:
|
|
|
|
|
|
|
|
Primeiramente enviamos pro remoto a nossa branch:
|
|
|
|
>`git push origin feature/<TASK_NAME>`
|
|
|
|
|
|
|
|
Agora que temos a branch no remoto iremos passar para a branch de dev e garantir que ela está atualizada, pois como existem outras pessoas no projeto existe a possibilidade da nossa dev já ter novos *commits*.
|
|
|
|
|
|
|
|
>`git checkout dev` <br >
|
|
|
|
(Troca para a branch dev)
|
|
|
|
|
|
|
|
>`git fetch` <br >
|
|
|
|
(Atualiza o remoto)
|
|
|
|
|
|
|
|
>`git pull` <br >
|
|
|
|
(Aplica as novas atualizações na dev)
|
|
|
|
|
|
|
|
|
|
|
|
Neste momento estamos com nossa dev atualizada, o próximo passo é aplicar os novos commits da dev na nossa branch antes de realizar o merge para a dev:
|
|
|
|
|
|
|
|
>`git checkout feature/<TASK_NAME>` <br >
|
|
|
|
(Para voltar à nossa branch de feature)
|
|
|
|
|
|
|
|
>`git rebase dev` <br >
|
|
|
|
(Este comando aplica as alterações novas na nossa branch)
|
|
|
|
|
|
|
|
Com o rebase, podem ser que existam problemas de merge, então você deve terminar resolver os [conflitos](conflito) e aplicar utilizando *git rebase --continue*
|
|
|
|
|
|
|
|
Se tudo der certo com o rebase estamos prontos para aplicar o merge na branch de dev.
|
|
|
|
|
|
|
|
>`git checkout dev` <br >
|
|
|
|
>`git merge feature/<TASK_NAME> --no-ff` <br >
|
|
|
|
(Note que usamos o parâmetro --no-ff ele serve para que o merge mantenha o tracking da branch que foi unida com a dev)
|
|
|
|
|
|
|
|
Feito isso, *idealmente* testamos todo o sistema pra ver se nada foi quebrado nos merges e se tudo estiver ok iremos subir a nova versão para o remoto com o seguinte comando:
|
|
|
|
|
|
|
|
>`git push origin dev`
|
|
|
|
|
|
|
|
<a name="conflito"></a>
|
|
|
|
Se houverem conflitos:
|
|
|
|
>Resolver conflitos usando o Visual Studio Code ou sua ferramenta de preferência.
|
|
|
|
>Adicionar arquivos conflitantes corrigidos
|
|
|
|
>`git add <FILE_PATH>`
|
|
|
|
>Dar git rebase --continue
|
|
|
|
>Repetir esses passos até que todos os conflitos sejam resolvidos
|
|
|
|
|
|
|
|
|
|
|
|
Não tenha medo de usar o git e também não hesite em pedir ajuda à algum colega de projeto, lembre que todos já passamos por alguns <strike>vários</strike> problemas de git e todos aqui estamos trabalhando por um propósito em comum, o [autor desta página](https://www.facebook.com/ghpaul) se coloca a disposição para qualquer dúvida. Caso você tenha dúvidas sobre o funcionamento de algum comando do git ou algum parâmetro, existe [esta documentação](https://git-scm.com/docs) onde explica detalhadamente os comandos.
|
|
|
|
|
|
|
|
|
|
|
|
original hosted by Gabriel Henrique Paul [https://www.facebook.com/ghpaul] |
