Definições conceituais: Branch e Fork

No meu ponto de vista só reforçaria que a branch pode também ser utilizada para separar os commits e acessos de cada area de desenvolvimento, ou seja :

• Branch para front-end.
• Branch para back-end
• Branch para dba, etc..

Do mais tenho o mesmo entendimento que você.

Opa, Fernando,

Concordo com você, porém tenho a experiência também de utilizarmos a branch para times, assim como o Matheus comentou.

Também utilizo o fork como uma maneira dos desenvolvedores não terem permissão de commit direto no repositório original, assim eles se forçam a fazer o fork do projeto para suas contas, modificar e abrir pull request's, o merge desse pull request fica por responsabilidade de alguém com permissão ou por alguma ferramenta como jenkins ou um bot* .

Abraços, espero ter ajudado!

Ah, esqueci de mencionar branchs diferentes para o ambiente de sandbox e o ambiente de produção. Talvez não seja vista como a melhor das práticas, mas utilizo com o código de infra-estrutura (puppet) e funciona legal!

Matheus Castiglioni

Eu não tinha pensando em fazer dessa maneira, o que eu faço com o SVN, e também que eu ia fazer (até conhecer essa abordagem) com o Git, é separar cada time/tipo de desenvolvimento em repositórios separados. Então back-end fica num repositório separado, front em outro e assim por diante.

Mas foi muito interessante saber que você e o Jonathan Beber fazem dessa forma e provavelmente outras pessoas também fazem. A princípio desse jeito parece até ficar melhor para organizar o projeto, pois centraliza todos os artefatos.A centralização dos artefatos, seria essa a ideia de trabalhar nessa abordagem, certo?

Só tenho uma dúvida, como vocês separam a geração das tags? Até onde vi não é possível separar tags por branches, pois a área de tags fica num contexto geral. Vocês adotam uma nomenclatura para as tags? Ex:

front-end-v1.0, front-end-v1.5 ...

back-end-v1.0, back-end-v1.5 ...

Abraços!

Não tinha pensado na questão que o Jonathan falou sobre os forks, é muito interessante também.

Eu apenas criaria as branch com seus respectivos nomes(references a cada area de desenvolvimento).

Evitando a redundância de projetos como você iria fazer, o problema pode ser resolvido tudo no mesmo projeto assim você centraliza a manutenção e acompanhamento no mesmo repositório.