Fork e Pull Requests ou contribuição direta dentro do repositório?

[lazarofl]

Fala galera,

Aqui na empresa temos os repositórios privados onde os times trabalharam diretamente numa mesma versão, fazem o clone e podem subir diretamente pra master ou para a sua respectiva branch com a feature em desenvolvimento.

Como temos uma boa comunicação e deixamos bem definido o formato de trabalho sempre com branchs, commits curtos e definition of done bem claras a quantidade de problemas são baixas mas uma vez ou outra vai pra master algo que efetivamente não esta pronto.

Como vocês trabalham essa questão dentro dos repositórios privados? Vale a pena usar o mesmo formato de contribuição dos projetos opensource com forks + pull requests?

Qual a experiência de vocês nessa questão?

[brunobertolini]

Aqui na Contentools usamos o mesmo repo, com acesso full, porém sempre criamos um branch, e fazemos pull request, pra que outro membro da equipe faça review e merge

[felipefialho]

Cara, a gente costuma criar branchs só quando são modificações que vão demorar ou mudanças muito grandes. Se for coisa simples a gente altera direto na master mesmo.

Acho que depende muito do tamanho da equipe e quantas pessoas estão desenvolvendo o projeto simultaneamente.

[willycamargo]

Trabalho sozinho no front do projeto e existem mais dois devs trabalhando no backend.

• Criamos issues no birbucket para cada atividade.
• Criamos um branch para referenciar a issue (mais de uma quando viável).
• Desenvolvemos a freature ou corrigimos os bugs dentro dos respectivos branchs (com commits curtos)
• Fazemos um pull request
• Sentamos os três juntos para revisar e fazer o merge no master.

Além disso utilizamos o codeship para rodar os testes e fazer o build para o ambiente de homologação.

É um processo um pouco trabalhoso e pode parecer lento, mas na prática se mostra muito vantajoso já que dificilmente vai algum bug para o master e estamos sempre aprendendo um com o outro.

[felipefialho]

Para quem usa o Bitbucket como a gente, recomendo fortemente o Jira para organizar as tarefas. Os serviços da Atlassian são fodas.

[kazzkiq]

Eu sempre usei o mesmo esquema do @lfeh, correções e alterações pequenas direto no repositório e se é algo muito cabeludo, fork e pull request.

Mas acho que depende do caso também. Se o seu projeto é open-source e existem pessoas dependentes da estabilidade dele (imagine um jQuery da vida), o ideal é sempre trabalhar em branches e dar merge apenas na hora de soltar novas versões. É um processo moroso, mas traz segurança para quem usa seu código.

[lazarofl]

O repositório é privado, não é um projeto open-source. Dentro dos projetos open-source cada commit é bem avaliado dentro do pull request pois existe a possibilidade do time ter centenas ou milhares de contribuidores, seria o caos total deixar push indiscriminado e a coisa funciona muito bem assim 👍

A abordagem que estou pensando é trazer isso para o ambiente de um time pequeno e de repositório privado, não liberar push dentro do projeto sem passar por um pull request documentado. Parece burocracia demais, eu sei, mas faz sentido pra alguém aqui? Alguém usa essa abordagem? Existe algum ganho de qualidade, perda de performance comprovada, etc.?

Hoje a config do repositório está assim.

Como podem ver, todos os 6 integrantes tem acesso write, ao mudar para read eles terão que fazer fork e subir via pull request (estou certo?). Existe algum ganho nisso?

[eduardojmatos]

Aqui na BankFacil fazemos branches e PR's do branch pra master, sempre revisado por mais 2 devs.

Até então tudo rola de boas.

---

@lazarofl o grande problema dessa abordagem é centralizar a aprovação pra uma só pessoa. Pessoalmente não gosto de deixar essa responsabilidade pra alguns. O time precisa se auto-avaliar.

[juniorconte]

Em nosso caso, temos duas abordagens:

1 - Novas features são tratadas em branchs separados, sempre a partir de master
2 - Bugfixes são aplicados diretamente no branch originário do bug (geralmente master).

Nós utilizamos o Trello para organizar o fluxo da Sprint, e nosso antepenúltimo processo é o de code-review. Acho que neste ponto, pull-requests ou branch-features teriam praticamente o mesmo impacto, desde que se adote o code-review, e que o review seja levado a sério. Seja por pull-request ou feature-branchs, os prós e contras, ao meu ver, seriam os mesmos. Pois em ambas situações leva-se um pouco mais de tempo para determinada feature entrar em prod, porém, a chance de algum bug passar é reduzida, e ainda cria-se um ambiente de auto-avaliação como dito pelo @eduardojmatos.

Acabamos optando por utilizar apenas branch-features, por se tratar de um processo um pouco menos burocrático que pull-requests "ritualmente falando".

[vitorbritto]

Faço o mesmo esquema que o @juniorconte. Mas utilizo sempre o Travis ou Wercker.

[lazarofl]

Vou começar a fazer o pull request da branch para a master e fazer o code-review com a galera, como o @eduardojmatos comentou no processo deles. Vou avaliar e futuramente comento algo por aqui, fiz uns testes e não achei o processo burocrático em nada. Acho que serão muitos PR, vocês deixam pra fazer o code-review e merge mais pro final de uma sprint, em dias específicos ou revisam o mais rapidamente possível?

[danielGalvao]

Na empresa que trabalho JustDigital, cada task tem um código gerado pelo Jira, pois usamos o bitbucket. E com isso criamos a branch com o nome (código da task). pois assim conseguimos definir melhor um fluxo de desenvolvimento, review e deploy de tasks. O flow é assim: Terminou a task faz merge na branch de stage, outro dev testa e se tudo tiver ok, o dev que testou faz merge da branch da task em master. Forçando assim os devs estarem com todas as branches atualizadas.
Acredito ser muito arriscado em equipes com mais de 2 devs se trabalhar direto em master pois a quantidade de conflito é muito mais desgastante do que criar uma nova branch.
Lembrando que toda branch deve ser criada a partir de master que no caso do projeto deve ser a branch com tudo perfeito e funcionando...

[dionarodrigues]

Na empresa que eu trabalho migramos tudo para o bitbucket e ainda estamos encontramos uma maneira interessante para esse processo. Aqui a equipe de desenvolvimento é pequena.

Assim, estamos fazendo da seguinte maneira: sempre que uma tarefa dependerá da continuação de outro desenvolvedor - ou quando é uma tarefa extensa, que corre o risco de não ser finalizada rapidamente (porque às vezes o projeto oficial precisa ser atualizado de repente) - criamos uma branch nova.

Para correções de bugs, ou caso a tarefa seja rápida e não dependa de outro desenvolvedor, fazemos um push diretamente na master.

Ainda não implementamos um processo de teste, mas os comentários de vocês me ajudaram a sugerir melhorias aqui no nosso processo. Valeu!

[victorserpac]

Gosto da dinâmica do git-glow, atualmente utilizo dessa maneira.