======Estratégia GIT para trabalhar em nossos projetos======
\\
----

**Existem três branches principais e uma variedade de branches-names que refletem diretamente a necessidade de organização de seus desenvolvedores:**

  * **master** - esse branch roda a versão do ambiente de produção - sempre estará em uma versão mais conservadora ou no máximo idêntica às versões que tiverem sendo usadas nos outros branches.
  * **teste** - esse branch é criado a partir de uma cópia do Master - e ele alimenta tanto o ambiente de Cooperação quanto o de Homologação. É neste branch que as alterações dos desenvolvedores vão parar depois que eles avisam ao Gestor de Mudanças que o seu branch encontra-se pronto para teste.
  * **development** - esse branch é para nivelar a versão que todo o mundo vai trabalhar - ele não deverá alimentar nenhum ambiente, nem mesmo o ambiente local do desenvolvedor e não deverá sofrer commits por parte dos desenvolvedores.
  * **branch-name** - cabe ao desenvolvedor escolher um nome que seja representativo do que esteja fazendo no código, por exemplo: orcamento, patrimonio, controle_tela_login, emails_geracao, etc. Esses branches serão clonados a partir da versão do development e eles irão rodar o ambiente local na máquina de cada desenvolvedor. Os nomes de branches devem ser em letras minusculas e conter "_" entre as palavras, na eventualidade de haver mais de uma.
\\
----

**Forma de trabalhar do desenvolvedor:**

  - O desenvolvedor que precisar trabalhar em algum aspecto do código deverá primeiramente clonar o development para um branch de nome de sua preferência, fazendo assim:
    - git checkout development (mudar para o branch development)
    - git pull (atualizar a sua cópia local com a cópia do remoto)
    - git push origin HEAD:branch-name --> criar um branch no repositório remoto com o mesmo nome do local que se queira trabalhar. 
    - git checkout -b branch-name origin/branch-name --> criar um branch no repositório local com o mesmo nome do remoto, conectá-los um ao outro e sinalizar ao GIT que se vai trabalhar neste branch.
  - Assim que o desenvolvedor começar a mexer no código ele procederá da seguinte forma para persistir suas alterações no git:
    - git add --> joga as alterações na área de transferência (staging area) para permitir dar commit
    - git commit -m "mensagem de commit entra aqui" (o passo 5 e 6 se repete até o desenvolvedor sentir que o código está pronto para ser compartilhado).
    - ele faz um rebase no código para compactar todos os commits feitos em apenas um.
    - git pull
    - git push
    - avisa ao gestor de mudanças que o seu trabalho terminou e que no branch XYZ encontra-se sua contribuição.
\\
----

**Forma de trabalhar do Gestor de Mudanças:**

  - Ele entra no GitHub e cria um novo pull request com o branch novo recebido do desenvolvedor.
  - Ele dá um merge no branch teste com esse novo branch. O Gestor de Mudanças sempre irá trabalhar preferívelmente com a ferramenta GitHub.
  - Ele resolve qualquer conflito que possa ter impedido esse merge e tenta novamente.
  - Ele gera o sipac.ear dessa nova atualização do código e disponibiliza-a para o ambiente de Cooperação para o usuário validar essas alterações. Ver [[gerando_ear]] para entender como gerar o sipac.ear.
  - Assim que o ambiente de teste for validado o sipac.ear será disponibilizado para os ambientes de Homologação e Produção.
  - Neste momento ele deverá fazer merge do branch teste para o branch master.
  - Em tempo oportuno ele deverá deixar o branch development na mesma versão do branch master. Não há pressa em fazer isso, vai depender de outros desenvolvedores estarem trabalhando no código com a mesma versão do development e ser preferível aguardar eles commitarem suas contribuições no Git, para aí sim, fazer a atualização do branch development.
  - Assim que o branch development for atualizado ele pode avisar a equipe para dar o git pull, cada um em sua máquina estando neste branch, para atualizar o branch. Por padrão o desenvolvedor sempre irá dar git pull antes de criar um branch novo a partir deste, então o gestor de mudanças pode ou não avisar a equipe sobre essa atualização.
//OBS<sub>1</sub> - Todos os desenvolvedores terão como ponto de partida o mesmo clone do Development (estarão na mesma versão). Nenhum desenvolvedor poderá commitar diretamente nesse branch.//\\
//OBS<sub>2</sub> - Iremos pensar numa forma de versionar esses ambientes sempre que disponibilizarmos um novo .ear para eles.//\\
//OBS<sub>3</sub> - Esse processo pode se repetir para uma outra contribuição vinda de outro desenvolvedor, sem prejuizo de nenhum dos participantes. Mas é importante colocar a contribuição de cada um de forma seriada no branch teste. Colocar a contribuição no branch teste e deixá-la ser testada e validada para só então dar merge no branch teste com o branch do outro desenvolvedor.//
\\
----

**O Gestor de Mudanças e o branch development.**

A ligação de todos os trabalhos se darão através do branch development para manter uma mesma versão inicial entre os desenvolvedores para evitar ao máximo a possibilidade de conflitos de código. Para isso iremos adotar a seguinte estratégia:
  - Assim que o Gestor de Mudanças sinalizar que o branch development mudou para uma versão mais recente todos os desenvolvedores que estiverem trabalhando em código, deverão dar os comandos abaixo para trazer as mudanças do repositório remoto do development para dentro de seu repositório local.
    - git checkout development
    - git pull (não vai dar conflito aqui pois o desenvolvedor não commitou nele em momento algum)
    - A partir desse momento pode-se optar por:
      - faz um novo branch a partir do clone desse branch development e refaz o trabalho que estava fazendo no branch que foi clonado com a versão anterior do development
      - faz o merge do development para dentro do branch que se estava trabalhando e tenta resolver os conflitos que ocorrerem. Na dúvida as alterações do development deverão ter prioridade em permanecer no código.
\\
----

**Para deletar os branches locais e remotos:**
  - git checkout master --> mudar para um outro branch (neste caso mudamos para o master, para poder deletar o branch que estávamos trabalhando)
  - git push origin :branch-name --> para deletar o branch no repositório remoto 
  - git branch -d branch-name --> para deletar o branch no repositório local