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. | ||
| + | |||
| + | Cada desenvolvedor clona e salva no origin. Mas, além dessa relação centralizada comum, cada desenvolvedor deve também clonar as 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 == | ||
Edição das 14h08min 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 clona e salva no origin. Mas, além dessa relação centralizada comum, cada desenvolvedor deve também clonar as 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.
