cara desenvolvedor tem que saber usar git. simples assim.
vc esta simplificando um pouco o problema.
primeiro vc precisa definir um ciclo de desenvolvimento.
por exemplo, eu trabalho com branch master e branch devel. cada feature é desenvolvida em um branch a partir de devel ( cujo nome tem o id da task no redmine via https://github.com/celogeek/git-redmine-suite ).
a cada push para o repositorio central ( gitlab ) é executada a suite de testes via gitlab-ci
terminada a tarefa cria-se um pull request para ser revisada por outro desenvolvedor. estando ok a feature é incluida (merge) em devel.
em um dado momento faz-se uma nova release, nesse caso rola um merge no master com uma tag relativa a versão.
eu gosto bastante dessa abordagem quando pessoas podem trabalhar em tasks individuais ou em dupla sem muito grilo. mais gente trabalhando no mesmo problema fica dificil.
vc não precisa seguir este modelo. existem prós e contras. outros modelos possiveis:
-
todo mundo trabalha em devel. a cada commit rola um hook que executa todos os testes e caso falhe todo mundo recebe um email dizendo “DEVEL ESTA QUEBRADO POR CONTA DO COMMIT XXX FEITO POR FULANO”. isso pode se chamar continuous development. vantagens: força a suite de testes ser eficiente, todo mundo tem que atualizar o repositorio local com frequencia.
-
todo mundo trabalha no mesmo projetão que tem todos os diretorios de todos os projetos. define-se quem pode fazer commit em devel em determinados diretorios após o review. isso é chamado monorepository. vantagens: vc faz git pull e tem TUDO que precisa. contras: eu nunca trabalhei assim e já odeio.
resumo:
- defina o ciclo de desenvolvimento
- cada programador tem que respeitar o ciclo
- não sabe usar git? treinamento
- usou errado? manda desfazer
- desrespeitou o ciclo? demite