Capítulo 4A - GITFLOW Linha de Comando

Prévia do material em texto

GIT FLOW 
 
Linhas de comando 
https://github.com/nvie/gitflow/wiki/Command-Line-Arguments 
 
 
 
I - DEFINIÇÕES 
 
Git Flow: 
Um modelo de fluxo de trabalho para desenvolvimento de software com uma ou mais equipes 
distintas contribuindo com a mesma base de código que visa normalizar o controle de versões. o Git 
Flow estabelece algumas regras de nomenclaturas para tipos de branches enquanto, ao mesmo tempo, 
define o que cada tipo de branch faz. 
 O modelo é composto por branchs de vida infinita (develop e master) que contém o código em 
desenvolvimento e produção basicamente, e branchs de suporte (feature, bugfix, hotfix e release) que 
auxiliam no processo de desenvolvimento do sistema. Estas últimas possuem regras que estabelecem 
onde são iniciadas e onde são mescladas. 
 O git flow possui a vantagem de uma menor curva de aprendizagem por usar um padrão já 
documentado e amplamente utilizado. 
 
Tipos de Branchs: 
- Branch master (Principal – Branch de vida infinita) 
 Branch que contém código em nível de produção, ou seja, o código mais maduro existente na sua 
aplicação. Todo o código novo produzido eventualmente é juntado com a branch master em algum 
momento do desenvolvimento. Possui ciclo de vida eterno; 
 
- Branch develop (Desenvolvimento – Branch de vida infinita) 
 É a branch que contém o código (estável) em nível preparatório para o próximo deploy. Ou seja, 
quando features são terminadas, elas são juntadas com a branch DEVELOP, testadas (em conjunto, no 
caso de mais de uma FEATURE), e somente depois, as atualizações da branch develop passam por mais 
um processo para então ser juntadas com a branch master. Também Possui ciclo de vida eterno; 
 
- Branches feature/* (Desenvolvimento de novas Funcionalidades – Branch de suporte) 
 São branches no qual são desenvolvidos recursos novos para o projeto em questão. Essas branches 
tem por convenção nome começando com feature/ (exemplo: feature/newLayout) e são criadas a partir 
da branch develop (pois um recurso pode depender diretamente de outro recurso em algumas 
situações), e, ao final, são juntadas com a branch develop. Na literatura muitos autores não referenciam 
https://github.com/nvie/gitflow/wiki/Command-Line-Arguments
as branchs bugfix, interpretando essas branchs como melhorias. Assim os bugs do sistema são corrigidos 
por meio das branchs features. Este tipo de branch não altera a versão do software, atualizando apenas 
a branch develop; 
 
- Branches bugfix/* (Correção de erros não urgentes – Branch de suporte) 
 São branches com o fluxo de trabalho semelhante à branch feature, com a peculiaridade de separar as 
features exclusivas de correção de erros que podem esperar correção para entrar em uma próxima 
versão. Possui a convenção de nome começando com bugfix/ (exemplo: 
bugfix/correcaoEntradaCampoNome). São criadas a partir da branch develop, e, ao término da correção, 
juntadas na branch develop. Este tipo de branch não altera a versão do software, atualizando apenas a 
branch develop; 
 
- Branches hotfix/* (Correção de Bugs críticos – Branch de suporte) 
 São branches no qual são realizadas correções de bugs críticos encontrados em ambiente de 
produção, que não podem esperar o lançamento de uma nova versão. Por esse motivo são criadas a 
partir da branch master. Após a correção, são juntadas diretamente com a branch master e com a 
branch develop (pois os próximos deploys também devem receber correções de bugs críticos). Por 
convenção, essas branches tem o nome começando com hotfix/ e terminando com o próximo sub-
número de versão (exemplo: hotfix/2.31.1) seguindo as regras de padrão de versionamento adotado 
pela equipe. Esse tipo de branch gera um marcador (tag) de versão indicando a nova versão do sistema 
que irá para produção; 
 
- Branches release/* (Empacotamento de versão estável para produção – Branch de suporte) 
 São branches com um nível de confiança maior do que a branch develop, e que se encontram em nível 
de preparação para ser juntada com a branch master e com a branch develop (Pois pode haver 
pequenas correções e/ou atualizações, inclusive bump de versão na branch release/* em questão). 
Nessas branches, bugs encontrados durante os testes das features que vão para produção podem ser 
corrigidos mais tranquilamente, antes de irem efetivamente para produção. Por convenção, essas 
branches tem o nome começando com release/ e terminando com o número da próxima versão do 
software (seguindo o exemplo do hotfix, dado acima, seria algo como release/2.32.0) devendo seguir as 
regras de padrão de versionamento adotado pela equipe. Assim, esse tipo de branch também gera um 
marcador (tag) de versão indicando a nova versão do sistema que irá para produção; 
 
Um aspecto interessante do Git Flow é que, quando você mescla uma branch release/ ou hotfix/ com a 
branch master, ele automaticamente cria git tags correspondentes aos merge commits da mesclagem, 
facilitando o trabalho de, por exemplo, mudar para uma versão mais antiga, e organizando todo o 
trabalho. 
 
As git tags são como “atalhos” que possuem um nome mais amigável definido pelo programador para 
um commit específico no repositório, e que podem ser acessadas facilmente usando git checkout. Cada 
commit assume um hash único, como por exemplo: 82a3a450df62812d518ca72400b6d3a3d64c61cf. 
Com as git tags, esses commits são etiquetados com nomes legíveis para a localização de uma branch 
específica no fluxo de trabalho, como por exemplo uma versão de sistema. Tais informações podem ser 
vistas na interface visual do git: gitk. 
II - FLUXO DE TRABALHO 
 
Este capítulo mostra o fluxo de trabalho de desenvolvimento utilizando o git flow. 
 
1 – CLONE DO PROJETO 
Para clonar o projeto no repositório git: 
$ git clone git@horus.ssp.df.gov.br:profilepage/nome-projeto.git 
 Outra forma com nome de usuário e senha 
$ git clone http://<nome.usuario>:<senha>@horus.ssp.df.gov.br/profilepage/nome-
projeto.git 
 
2 – VERIFICAÇÃO DE INSTALAÇÃO DO GIT FLOW 
Após cada clone realizado, o git flow SEMPRE deve ser inicializado no repositório local para 
configurar a organização das branchs localmente, então: 
 
2.1 - Primeiramente, verificar se o git flow está instalado: 
$ git flow version (Retorna a versão) 
Ou 
$ git flow (Retorna os comandos disponíveis) 
 
Obs.: Caso não esteja instalado, verificar o método de instalação de acordo com o sistema 
operacional em: https://github.com/petervanderdoes/gitflow-avh/wiki/Installation 
 
2.2 – Inicializar o git flow. 
$ git flow init -d 
 
Obs.: O parâmetro -d faz a configuração default para os nomes de branchs. Se não for utilizado, 
o usuário terá que responder perguntas para fazer a configuração, podendo aceitar a sugestão de nome 
ou fazer a alteração desejada. 
 
Agora, já existe um projeto com o git apontando para o repositório remoto repositório remoto e já com o 
framework git-flow instalado e inicializado no projeto. 
 
 
 
3 – BRANCH FEATURE 
A branch feature será o processo mais utilizado pelos desenvolvedores, pois é por meio de várias 
features que as melhorias do código vão sendo mescladas na develop. O pacote de várias features 
enviadas por vários desenvolvedores para a develop que irão definir o um pacote estável para testes em 
ambiente de homologação e posterior versionamento pra deploy em produção. 
 
3.1 - Inicializando uma branch feature: 
 $ git flow feature start 1-nomeFeatureCammelCase 
 
Resumo das Ações: 
- Uma nova branch 'feature/1-nomeFeatureCammelCase' foi criada com base na 'develop' 
- Checkout da branch 'feature/1-nomeFeatureCammelCase' 
 
3.2 – [Opcional] – Publicando a branch feature no repositório remoto 
 Há a possibilidade de fazer a publicação da branch no repositório remoto, para que possa haver 
o acompanhamento de outros membros da equipe ou simplesmente armazenamento da branch, por 
exemplo. Para isso basta fazer a publicaçãoda branch: 
 $ git flow feature publish 1-nomeFeatureCammelCase 
 
Resumo das Ações: 
- Branch 'feature/1- nomeFeatureCammelCase' remota foi criada ou atualizada 
- A branch local 'feature/1- nomeFeatureCammelCase' foi configurada para rastrear a branch 
remota 
- Checkout da branch 'feature/1-criarProjetoInicial' 
 
 Para recuperar os dados da branch feature remota, deve ser feito um pull na branch desejada: 
 $ git flow feature pull 1-nomeFeatureCammelCase 
 
3.3 – Alterações na branch feature 
 O processo de desenvolvimento das branchs é idêntico ao desenvolvimento com git. À medida 
que novos códigos são criados, estes podem ser enviados para os repositórios. 
As alterações são enviadas para o repositório local pelos comandos do git add e commit: 
 $ git add <arquivo/*> 
$ git commit -m "Mensagem do que foi feito para o commit" 
 
 Após cada ciclo de desenvolvimento, as alterações podem, também, ser enviadas ao repositório 
remoto pelo método publish, após o commit, conforme comando mostrado no item 3.2. 
$ git flow feature publish 1-nomeFeatureCammelCase 
 
Para recuperar os dados da branch feature remota, deve ser feito um pull na branch desejada: 
$ git flow feature pull 1-nomeFeatureCammelCase 
 
3.4 – Finalizando a branch feature 
Após o desenvolvimento das alterações/melhorias e testes locais, a branch feature deve ser 
finalizada, para testes em ambiente de homologação. Ao finalizar, o git flow irá fazer o merge das 
alterações para a branch develop, excluir a branch feature localmente e remotamente, se for o caso, e 
apontar o repositório local para a banch develop, devidamente atualizada. 
$ git flow feature finish 1-nomeFeatureCammelCase 
 
Resumo das Ações: 
- Branch 'feature/1- nomeFeatureCammelCase' foi mesclada com 'develop' 
- A branch 'feature/1- nomeFeatureCammelCase' foi excluída localmente; Foi excluída 
remotamente de 'origin' 
- Checkout da branch 'develop' 
 
3.5 – Enviando alterações para repositório remoto 
 Neste ponto é necessário o envio das alterações para o repositório remoto. A branch develop 
local será mesclada na branch develop remota para que possa ser feito o deploy em ambiente de 
homologação. Para isso, basta enviar as alterações para a branch remota com o comando push: 
$ git push origin develop 
 
Observação: Neste ponto pode haver possíveis conflitos 
com a branch remota, uma vez que outros desenvolvedores 
também enviarão suas alterações para a branch develop. Assim, 
caso ocorram, os conflitos devem ser resolvidos antes do envio por 
push. 
 
 
 
 
4 – BRANCH BUGFIX 
 A branch bugfix é muito pouco utilizada, ao ponto de várias fontes fazer menção à esta. O 
processo é idêntico ao da branch feature. O uso desta branch é opcional, cabendo à equipe adotar ou 
não seu uso visando organização na separação de atividades de correção de erros ou de melhorias no 
sistema. Caso não seja adotada, toda a correção de erros não críticos no sistema pode ser feito durante 
o desenvolvimento por meio da branch feature. 
 
4.1 - Inicializando uma branch bugfix: 
 $ git flow bugfix start myFirstBugfix 
 
Resumo das Ações: 
- Uma nova branch 'bugfix/myFirstBugfix' foi criada com base na 'develop' 
- Checkout da branch 'bugfix/myFirstBugfix' 
 
4.2 – [Opcional] – Publicando a branch bugfix no repositório remoto 
 Assim com uma branch feature, opcionalmente, a branch bugfix pode ser publicada no 
repositório remoto com o comando publish: 
$ git flow bugfix publish myFirstBugfix 
 
Resumo das Ações: 
- Branch 'bugfix/myFirstBugfix' remota foi criada ou atualizada 
- A branch local 'bugfix/myFirstBugfix' foi configurada para rastrear a branch remota 
- Checkout da branch 'bugfix/myFirstBugfix' 
 
 Para recuperar os dados da branch bugfix remota, deve ser feito um pull na branch desejada: 
$ git flow bugfix pull myFirstBugfix 
 
4.3 – Alterações na branch bugfix 
 As alterações são enviadas para o repositório local pelos comandos do git add e commit: 
 $ git add <arquivo/*> 
$ git commit -m "Mensagem do que foi feito para o commit" 
 
 E, após cada ciclo de desenvolvimento, as alterações podem, também, ser enviadas ao 
repositório remoto pelo método publish, após o commit. 
$ git flow bugfix publish myFirstBugfix 
 
Resumo das Ações: 
- Branch 'bugfix/myFirstBugfix' remota foi criada ou atualizada 
- A branch local 'bugfix/myFirstBugfix' foi configurada para rastrear a branch remota 
- Checkout da branch 'bugfix/myFirstBugfix' 
 
 Para recuperar os dados da branch bugfix remota, deve ser feito um pull na branch desejada: 
 $ git flow bugfix pull myFirstBugfix 
 
4.4 – Finalizando a branch bugfix 
Após a correção do bug, a branch deve ser finalizada. Ao finalizar, o git flow irá mesclar a 
correção com a branch develop, para testes, irá excluir a branch bugfix localmente e remotamente, se for 
o caso, e apontar o repositório local para a banch develop, devidamente atualizada. 
$ git flow bugfix finish myFirstBugfix 
 
Resumo das Ações: 
- Branch 'bugfix/myFirstBugfix' foi mesclada com 'develop' 
- A branch 'bugfix/myFirstBugfix' foi excluída localmente; Foi excluída remotamente de 'origin' 
- Checkout da branch 'develop' 
 
4.5 – Enviando alterações para repositório remoto 
 Neste ponto é necessário o envio da correção para o repositório remoto. A branch develop local 
será mesclada com a remota para o deploy em ambiente de homologação. O envio deve ser feito com o 
comando push: 
$ git push origin develop 
 
Caso ocorram conflitos, estes devem ser resolvidos antes 
do push. 
 
5 – BRANCH RELEASE 
 Neste ponto, já foram criadas várias branchs features pela equipe de desenvolvimento que 
incorporadas à branch develop gerando uma versão funcional e estável do sistema, pronta para deploy 
em produção. Assim, deve-se gerar uma branch do tipo release para ser testada em um ambiente pré-
produção e fazer o deploy para produção. Essa branch irá atualizar as branchs master e develop com a 
versão mais atual do código, além de marcar a versão do software por meio de uma tag, ou seja, irá 
alterar a versão do sistema em produção. 
 
5.1 - Inicializando uma branch release: 
 $ git flow release start 1.0.0 
 
Resumo das Ações: 
- Uma nova branch 'release/1.0.0' foi criada com base na 'develop' 
- Checkout da branch 'release/1.0.0' 
 
5.2 – [Opcional] – Publicando a branch release no repositório remoto 
 Apesar de ser opcional a publicação da branch release no repositório remoto, é sensato que seja 
feito pois com isso os outros desenvolvedores da equipe tomam conhecimento que temos uma release 
candidate, além de possibilitar novos commits pela equipe, integrando alguma melhoria ao código. 
 A publicação é feita com o comando publish: 
 $ git flow release publish 1.0.0 
 
Resumo das Ações: 
- Branch 'release/1.0.0' remota foi criada ou atualizada 
- A branch local 'release/1.0.0' foi configurada para rastrear a branch remota 
- Checkout da branch 'release/1.0.0' 
 
 Para recuperar os dados da branch release remota, deve ser feito um pull na branch desejada: 
$ git flow release pull 1.0.0 
 
5.3 – Alterações na branch release 
 Apesar desta branch já ser um código estável e funcional, é permitido a alteração do código da 
branch, uma vez que podem aparecer correções de última hora, ou pequenos erros. Além disso deve ser 
feito o bump da versão, ou seja, atualizar os arquivos que contém o número da versão do sistema que 
será colocado em produção, que no caso do exemplo, é a versão 1.0.0. 
 As alterações são enviadas para o repositório local pelos comandos do git add e commit: 
$ git add <arquivo/*> 
$ git commit -m "Mensagem do que foi feito para o commit" 
 
 E, após atualizada a versão e possíveis correções, as alterações podem, também, ser enviadas ao 
repositório remoto pelo método publish, após o commit. 
$ git flow release publish 1.0.0 
 
Resumo das Ações: 
- Branch 'release/1.0.0' remota foi criada ou atualizada- A branch local 'release/1.0.0' foi configurada para rastrear a branch remota 
- Checkout da branch 'release/1.0.0' 
 
 Para recuperar os dados da branch release remota, deve ser feito um pull na branch desejada: 
 $ git flow release pull 1.0.0 
 
5.4 – Finalizando a branch release 
Feito todas as alterações, inclusive a atualização da versão, a branch release pode ser finalizada. 
É hora de fazer o merge com a master e develop, excluir a branch release localmente e remotamente, se 
for o caso, e ainda criar a tag correspondente à versão, que no caso é a 1.0.0. Vale lembrar que o git flow 
faz isso automaticamente. Para finalizar digite o comando: 
$ git flow release finish -p 1.0.0 
 
Neste ponto, o processo é um pouco diferente. O git flow irá abrir na sequência 3 editores de 
texto (editor vi). 
- Primeiro: Referente ao merge da branch release 1.0.0 com a master. Pode ser deixado a 
mensagem padrão. 
- Segundo: Referente à tag 1.0.0 criada para facilitar a mudança e identificação. Entre com a 
mensagem para o commit desta tag, com uma descrição da versão, o que contempla esta release. 
- Terceiro: Referente ao merge da branch release 1.0.0 com a develop. Pode ser deixado a 
mensagem padrão. 
 
Resumo das Ações: 
- Branch 'release/1.0.0' foi mesclada com 'master' 
- A release foi marcada com a tag '1.0.0' 
- Tag '1.0.0' foi mesclada com 'develop' 
- A branch 'release/1.0.0' foi excluída localmente; Foi excluída remotamente de 'origin' 
- As branch 'develop', 'develop' e tags foram enviadas para 'origin' 
- Checkout da branch 'develop' 
 
Observação: O parâmetro -p faz a publicação dos repositórios, fazendo merge na master, 
develop e subindo a tag. Se a processo de desenvolvimento da equipe não for essa, o parâmetro -p deve 
ser desconsiderado no fechamento da release para que o repositório remoto possa ser atualizado 
manualmente. 
Observação: Caso ocorram conflitos, estes devem ser resolvidos antes do envio ao servidor 
remoto na publicação (parâmetro -p). 
Nota: 
 As mensagens de mesclagem abrem ne editor vi. Assim, para concluir a finalização, se faz 
necessário o conhecimento de alguns comandos básicos. 
 i – Inicia edição de texto (insert) 
 esc – finaliza edição de texto 
:wq! Salva as alterações (write) e sai (quit) do editor 
 :q! – sai (quit) do aplicativo sem salvar 
 
5.5 – Enviando alterações para repositório remoto 
 Este item acaba tornando-se opcional, pois caso o desenvolvedor tenha usado o parâmetro -p no 
comando de finalização da release, mostrado no item 5.4, a atualização das branchs remotas já foi feito 
automaticamente. Porém, se por algum motivo esse parâmetro não foi utilizado, as alterações de 
versionamento devem ser enviadas para o repositório remoto manualmente para atualização da branch 
master, develop e envio da tag. O envio deve ser feito conforme processo de deploy definido pela equipe. 
Caso for necessário, os repositórios e tag podem ser enviados um por vez. 
Enviando alterações das branchs master e develop para o repositório remoto 
$ git push origin develop 
$ git push origin master 
 
Listando tags no repositório local 
$ git tag 
 
Enviando tag desejada para o repositório remoto 
 $ git push origin 1.0.0 
 
Observação: Caso ocorram conflitos, estes devem ser resolvidos antes do push. 
 
 
 
5.6 – Esquema da branch release 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
6 – BRANCH HOTFIX 
 A branch do tipo hotfix é utilizada para uma correção emergencial do código em produção. É 
utilizada para resolver um problema crítico que não pode esperar a próxima versão e que pode ser 
corrigido em pouco tempo, e por isso, após a correção será atualizada a versão do sistema. Por 
exemplo, uma branch hotfix 1.0.1 irá corrigir uma falha na release 1.0.0. Outra característica pecukioar 
da branch hotfix é que esta se origina da branch master, uma vez que visa a correção de um bug em 
produção. Como a branch hotfix altera a versão do sistema, o nome deve ser baseado no sistema de 
versionamento adotado pela equipe. O mesmo utilizado na branch release. 
 
6.1 - Inicializando uma branch hotfix: 
 $ git flow hotfix start 1.0.1 
 
Resumo das Ações: 
- Uma nova branch 'hotfix/1.0.1' foi criada com base na 'master' 
- Checkout da branch 'hotfix/1.0.1' 
 
6.2 – [Opcional] – Publicando a branch release no repositório remoto 
 A publicação da branch hotfix no repositório remoto é opcional, uma vez que é uma correção de 
urgência, que durará pouco tempo, porém, este procedimento pode ser adotado para informar aos 
outros desenvolvedores que está em curso uma correção, e consequentemente uma nova release 
candidate. 
 A publicação é feita com o comando publish: 
 $ git flow hotfix publish 1.0.1 
 
Resumo das Ações: 
- Branch 'hotfix/1.0.1' remota foi criada ou atualizada 
- A branch local 'hotfix/1.0.1' foi configurada para rastrear a branch remota 
- Checkout da branch 'hotfix/1.0.1' 
 
 Para recuperar os dados da branch release remota, deve ser feito um pull na branch desejada: 
$ git flow hotfix pull 1.0.1 
 
6.3 – Alterações na branch hotfix 
 Após a correção do bug apresentado e atualização da versão do código as alterações podem ser 
enviadas ao repositório local e, se for o caso, também para o repositório remoto. 
 As alterações são enviadas para o repositório local pelos comandos do git add e commit: 
 $ git add <arquivo/*> 
$ git commit -m "Mensagem do que foi feito para o commit" 
 
 E, após atualizada a versão e possíveis correções, as alterações podem, também, ser enviadas ao 
repositório remoto pelo método publish, após o commit. 
$ git flow hotfix publish 1.0.1 
 
Resumo das Ações: 
- Branch 'hotfix/1.0.1' remota foi criada ou atualizada 
- A branch local 'hotfix/1.0.1' foi configurada para rastrear a branch remota 
- Checkout da branch 'hotfix/1.0.1' 
 
 Para recuperar os dados da branch hugfix remota, deve ser feito um pull na branch desejada: 
 $ git flow hotfix pull 1.0.0 
 
6.4 – Finalizando a branch hotfix 
Feito todas as correções, inclusive a atualização da versão, a branch hotfix pode ser finalizada. 
Esta também fará o merge com a master e develop, além de excluir a branch hotfiz localmente e 
remotamente, e, se for o caso, criar a tag correspondente à versão de atualização, que no exemplo é 
1.0.1, automaticamente. 
Para finalizar digite o comando: 
$ git flow hoftix finish -p 1.0.1 
 
Neste ponto, o processo é idêntico à branch release onde o git flow irá abrir na sequência 3 
editores de texto (editor vi). 
- Primeiro: Referente ao merge da branch hotfix 1.0.1 com a master. Pode ser deixado a 
mensagem padrão. 
- Segundo: Referente à tag 1.0.1 criada para facilitar a mudança e identificação. Entre com a 
mensagem para o commit desta tag, com uma descrição da versão, o que contempla este hotfix. 
- Terceiro: Referente ao merge da branch hotfix 1.0.1 com a develop. Pode ser deixado a 
mensagem padrão. 
 
Resumo das Ações: 
- Branch 'release/1.0.0' foi mesclada com 'master' 
- A release foi marcada com a tag '1.0.0' 
- Tag '1.0.0' foi mesclada com 'develop' 
- A branch 'release/1.0.0' foi excluída localmente; Foi excluída remotamente de 'origin' 
- As branch 'develop', 'develop' e tags foram enviadas para 'origin' 
- Checkout da branch 'develop' 
 
Observação: O parâmetro -p tem a mesma função do fechamento da branch release. 
Observação: Caso ocorram conflitos, estes devem ser resolvidos antes do envio ao servidor 
remoto na publicação (parâmetro -p). 
 
6.5 – Enviando alterações para repositório remoto 
 Caso seja necessário, o desenvolvedor pode fazer o envio por push das correções e tag para o 
repositório remoto. 
Enviando alterações das branchs master e develop para o repositório remoto 
$ git push origin develop 
$ git push origin master 
 
Listando tags no repositório local 
$ git tag 
 
Enviando tag desejada para o repositório remoto 
 $ git push origin 1.0.1Observação: Caso ocorram conflitos, estes devem ser resolvidos antes do push. 
 
6.6 – Esquema da branch hotfix 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
6 – ESQUEMA GERAL