Please enable JavaScript.
Coggle requires JavaScript to display documents.
Maneiras de Trabalhar com o Git (Utilizando branches por etapa de…
Maneiras de Trabalhar com o Git
Modelos de distribuição de repositórios e de branchs
Modelos de distribuição de repositórios
Apenas um repositório remoto, central, para onde os repositórios locais apontam
Cada desenvolvedor tem seu fork, um repositório remoto que é uma cópia do projeto, utilizando um repositório central para integração
Uma hierarquia de repositórios para integração
Modelos de organização de branchs
Utilizar apenas a branch master
Ter uma branch para cada nova funcionalidade, deixando a master para código pronto para ser entregue
Ter algumas branches por etapa de desenvolvimento, como uma branch de longo prazo para código ainda em construção e uma de curto prazo para correções de bugs urgentes
Utilizando só a branch master com um repositório central
Um dos fluxos de trabalho mais simples, onde se utiliza somente um repositório remoto central e tudo é commitado diretamente na branch master
Para enviar commits locais, todos os desenvolvedores do projeto faz um push para o repositório central
Para quem é?
Para equipes pequenas ou na adoção do git
Vantagens
É simples, sendo mais fácil de entrar pra quem tá começando e não sabe de nada
É mais fácil para integração continua, onde o código deve ser integrado frequentemente, disparando builds e testes automatizados e detectando erros de integração o mais rápido possível
Desvantagens
Ao corrigir bugs críticos, código de novas funcionalidades podem já estar inseridas no repositório, dificultando a descoberta dos bugs
Como todo o código só tá em uma branch, não dá para entregar apenas uma parte das funcionalidades e depois o resto
Todos os desenvolvedores tem que ter acesso a
push
no repositório, o que pode ser foda para equipes grandes e impossível para projetos open-source
Utilizando branches por funcionalidade
com um repositório central
Esse fluxo utiliza branches para isolar o código de novas funcionalidades ou alteração nas já existentes, a banch master irá ficar estável por todo o tempo, com as funcionalidades já prontas para ser entregues e estáveis
Se surgir bugs que precisam ser resolvidos urgentemente, podemos fazer os commits diretamente na master
(Só um adendo, esse fluxo de trabalho também é chamado de
feature branching
ou
topic branching
)
Para quem é?
Para equipes medianas, principalmente se o projeto já estiver em andamento, é importante que a equipe conheça um pouco o Git
Vantagens
Podemos isolar código mais estável na branch master , facilitando a realização de melhorias e correções imediatas
Revisões da qualidade do novo código que implementa uma funcionalidade podem ser feitas analisando os commits da branch da funcionalidade
Pode ser entregue apenas parte das funcionalidades que estão sendo desenvolvidas, possibilitando mudanças mais tranquilas na estratégia de negócio do nosso cliente
Desvantagens
Como a equipe precisa dominar o Git razoavelmente bem, o uso desse fluxo no início da adoção do Git fica dificultado
Como trabalhamos com um repositório central, ainda há a necessidade de permissão de push para todos os membros da equipe. Por isso, esse fluxo pode ser problemático para grandes equipes e torna-se inviável para projetos open source.
O código de uma funcionalidade só é efetivamente integrado com outras mudanças no momento do merge final com a branch master. Com outras funcionalidades em desenvolvimento, possíveis conflitos entre o código das funcionalidades só serão descobertos tardiamente, ao mesclarmos todas as branches.
Realizar integração contínua, descobrindo problemas no código e nas funcionalidades rapidamente, fica mais difícil.
Utilizando branches por etapa de desenvolvimento com um repositório central
A ideia desse fluxo é evitar uma integração de código tardia, a branch master vai continuar estável, porém teremos também uma branch para código em desenvolvimento, que seria uma branch de longo prazo, quando essa branch ficar estável, fazemos um merge na master
As branches de desenvolvimento continuariam, mas agora com base na branch de desenvolvimento e não mais na master, poderíamos também ter branches de release, onde commitamos código prontos para a entrega e seria feita a partir da branch de desenvolvimento, depois de tudo legal e ok, faríamos o merge dessa branch na master e na branch de desenvolvimento
As correções urgentes iriam continuar sendo feitas em branchs separadas a partir da master, depois de finalizados seria feito um merge na master :)
Para quem é?
Em projetos complexos, que já têm várias entregas e com diversas novas funcionalidades em desenvolvimento. A equipe já deve ter um bom domínio do Git.
Vantagens
A branch master fica bem estável, podendo ser utilizada até para disparar implantações automáticas do software
Conseguimos descobrir conflitos ou erros entre códigos das novas funcionalidades mais cedo se mesclarmos as branchs das funcionalidades na branch desenvolvimento periodicamente
Como utilizamos branches por funcionalidade, revisões do código das funcionalidade são fáceis de fazer.
Podemos entregar apenas parte das funcionalidades, bastando deixar o código isolado na branch da funcionalidade que não entrará na nova versão. Porém, se fizermos integrações periódicas em desenv , isso pode ser um desafio.
Correções urgentes têm um lugar definido nesse fluxo: as branches de hotfix
Trabalho relacionado com a preparação de uma nova versão e ajustes finos antes da liberação podem ser feitos em uma branch de release.
Desvantagens
A equipe precisa de um bom domínio do Git
É um fluxo complexo. Por isso, é melhor utilizar esse fluxo em projetos grandes e/ou quando o projeto está a todo vapor. Aí, a organização do trabalho compensa a complexidade
Todos os membros da nossa equipe precisam de permissão de push no repositório central, inviabilizando o uso em projetos open source e em equipes grandes.
Mesmo com a branch desenvolvimento , que serve como uma branch de integração, só integraremos efetivamente o código nos momentos em que fizermos o merge das branchs de funcionalidades na branch de desenvolvimento. Por isso, especialistas em integração contínua ainda criticam o uso desse fluxo, argumentando que essa integração ainda é feita tarde demais.
Colaborando com projetos open source
com Fork e Pull Request
A treta dos projetos open-source é que tem muita gente e ficar dando autorização de push pra geral é uma merda
Felizmente o github deixa os colaboradores fazer um fork no projeto e fazer os seus commits no seu fork, quando ele já tiver acabado, só fazer um pull request e esperar o mantenedor do projeto aceitar :)
É interessante que o colaborador faça seus commits em uma branch de funcionalidade, e não diretamente na master pra não dar treta pro mantenedor
Pra quem é?
Em projetos open source de pequeno ou médio porte.
Vantagens
Não é necessário dar permissões de push para todos os colaboradores do projeto.
É um bom modelo para projetos open source de pequeno ou médio porte.
Desvantagens
A integração das mudanças dos forks é feita de maneira bem tardia. Possíveis conflitos e/ou erros seriam descobertos apenas na hora de aplicarmos o pull request.
Como só há um repositório original com, provavelmente apenas um mantenedor, o número de pull requests poderia ir acumulando. Para projetos open source muito grandes é necessária uma outra abordagem.
Organizando projetos open source gigan-
tescos com Ditador e Tenentes
Para projetos open source enormes, é mais lucro usar o fluxo Ditador-Tenente, onde o mantenedor do projeto original será o ditador, ele escolherá pessoas para que sejam as tenentes e que ficarão responsáveis por um módulo do projeto e olharão os pull requests dos coloboradores em seu módulo de domínio.
Um coloborador terá que fazer forks e pull request no módulo que lhe interessa para o tenente responsável pelo módulo, depois de acumulado melhorias daoras para o módulo, o tenente faz um pull request para o ditador e ele sempre que dará a ultima palavra
Pra quem é?
Para projetos open source grandes, com milhares de colaboradores.
Vantagens
Assim como no fluxo anterior, não são necessárias permissões de push para o repositório original, do ditador, nem dos tenentes.
É um fluxo que funciona bem em projetos open source de grande porte.
Desvantagens
É um fluxo de trabalho extremamente complicado, que requer muita familiaridade com o Git.
A integração é feita de maneira tardia, só quando for aplicado o pull request (ou os patches recebidos por e-mail).