Mudanças entre as edições de "Modelo de branches no GitLab"
| Linha 7: | Linha 7: | ||
== Descentralizado, mas centralizado == | == Descentralizado, mas centralizado == | ||
O modelo de repositório utilizado para o gerenciamento de ''branches'' considera que temos apenas um único, e verdadeiro, repositório central. Note que este repositório é apenas considerado central (pois como o git é uma ferramenta de controle descentralizado, não existe um repositório central a nível técnico). Vamos nos referir a este repositório principal como '''origin''', pois é um nome familiar a todos os usuários do git. | O modelo de repositório utilizado para o gerenciamento de ''branches'' considera que temos apenas um único, e verdadeiro, repositório central. Note que este repositório é apenas considerado central (pois como o git é uma ferramenta de controle descentralizado, não existe um repositório central a nível técnico). Vamos nos referir a este repositório principal como '''origin''', pois é um nome familiar a todos os usuários do git. | ||
| + | [[Arquivo:Centr-decentr.png]] | ||
| − | Cada desenvolvedor | + | Cada desenvolvedor efetua ''pull'' e ''pushes'' no ''origin''. Mas, além dessa relação centralizada comum, cada desenvolvedor deve também efetuar um ''pull'' das modificações realizadas por outros desenvolvedores de outras equipes. Por exemplo, isto pode ser útil quando um ou mais desenvolvedores estão trabalhando em uma nova grande funcionalidade, antes de enviar as alterações em progresso diretamente para o repositório ''origin'' prematuramente. Na figura acima, existem equipes de Alice e Bob, Alice e David, e Clair e David. |
Tecnicamente isto significa nada mais que Alice definiu um ''git remote'' (chamado bob) apontando para o repositório da equipe de Bob, e vice-versa. | Tecnicamente isto significa nada mais que Alice definiu um ''git remote'' (chamado bob) apontando para o repositório da equipe de Bob, e vice-versa. | ||
== O ''branch'' principal == | == O ''branch'' principal == | ||
| − | No núcleo, o | + | No núcleo, o padrão de desenvolvimento é muito inspirado por modelos existentes no mercado. O repositório central detém dois ''branches'' principais, com uma vida útil infinita: |
| + | * '''master''' | ||
| + | * '''develop''' | ||
| + | O ''brach'' '''master''' no ''origin'' deve ser familiar para todo usuário git. Paralelamente ao ''branch'' '''master''' outro ''branch'' existe, chamado '''develop'''. | ||
| + | Consideraremos o ''origin/'''master''''' como ''main branch'', onde o seu conteúdo sempre reflete o status de '''pronto para produção'''. | ||
| + | Consideraremos o ''origin/'''develop''''' como o principal ''branch'' onde o código fonte sempre reflete um estado com as mudanças de desenvolvimento mais recente entregues para a próxima ''sprint''. Podemos chama-lo também de ''integration branch''. É neste ''branch'' onde qualquer rotina noturna automática de ''build'' é executada. | ||
Edição das 14h29min de 31 de maio de 2016
O git mudou a forma com a qual os desenvolvedores pensam a respeito de merges e branches. No mundo de código centralizado, merges e branches sempre foram considerados assustadores (cuidados com os conflitos do merge) e algo que era feito apenas uma vez em um longo tempo. Porém com o git essas ações são extremamente baratas e simples, e são consideradas o cerne do dia-a-dia de trabalho, de verdade. Como uma consequência de sua simplicidade e natureza repetitiva, criar branches e merges não é algo que se deva ter medo. As ferramentas de versionamento dispõem de toda a assistência necessária para realizar as tarefas de criação de branches e merges. Mais informações sobre o git e ferramentas de controle de código podem ser facilmente encontradas na web.
Após essa breve introdução sobre a ferramenta, vamos entrar de cabeça no modelo de desenvolvimento. O modelo aqui apresentado é essencialmente nada mais que um conjunto de procedimentos que cada membro da equipe tem que seguir a fim de chegar a um processo de desenvolvimento de software gerenciado.
Descentralizado, mas centralizado
O modelo de repositório utilizado para o gerenciamento de branches considera que temos apenas um único, e verdadeiro, repositório central. Note que este repositório é apenas considerado central (pois como o git é uma ferramenta de controle descentralizado, não existe um repositório central a nível técnico). Vamos nos referir a este repositório principal como origin, pois é um nome familiar a todos os usuários do git.
Cada desenvolvedor efetua pull e pushes no origin. Mas, além dessa relação centralizada comum, cada desenvolvedor deve também efetuar um pull das modificações realizadas por outros desenvolvedores de outras equipes. Por exemplo, isto pode ser útil quando um ou mais desenvolvedores estão trabalhando em uma nova grande funcionalidade, antes de enviar as alterações em progresso diretamente para o repositório origin prematuramente. Na figura acima, existem equipes de Alice e Bob, Alice e David, e Clair e David. Tecnicamente isto significa nada mais que Alice definiu um git remote (chamado bob) apontando para o repositório da equipe de Bob, e vice-versa.
O branch principal
No núcleo, o padrão de desenvolvimento é muito inspirado por modelos existentes no mercado. O repositório central detém dois branches principais, com uma vida útil infinita:
- master
- develop
O brach master no origin deve ser familiar para todo usuário git. Paralelamente ao branch master outro branch existe, chamado develop. Consideraremos o origin/master como main branch, onde o seu conteúdo sempre reflete o status de pronto para produção. Consideraremos o origin/develop como o principal branch onde o código fonte sempre reflete um estado com as mudanças de desenvolvimento mais recente entregues para a próxima sprint. Podemos chama-lo também de integration branch. É neste branch onde qualquer rotina noturna automática de build é executada.
