pull requests e conflitos

[Marcelo Jo]

  Pessoal, uma dúvida

  Como vcs fazem qdo alguém faz um pull request que tem conflitos? Vcs deixam pro desenvolvedor resolver os conflitos e fazer outro pull request ou o responsável do projeto resolve os conflitos e faz um merge?

  Não sei se fui claro! =D

  Valeu

  Marcelo

[Francesco]

Usa um open-colector que tu não terá problemas com os pull-ups.
Hahahahhahahaaha...

Estou brincando.
Tu tá falando de SVN? CVS?

--
Você recebeu essa mensagem porque está inscrito no grupo "sis_embarcados" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para sis_embarcado...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para sis_emb...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/sis_embarcados.
Para mais opções, acesse https://groups.google.com/d/optout.

[Marcelo Jo]

  git! =D

[Diego Sueiro]

Marcelo,

Independe de quem deve resolver a bucha é sempre importante colocar no workflow que antes de se fazer commit e push o camarada atualize a sua cópia local do repositório.

Abraços,

--
*dS
Diego Sueiro

Administrador do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/

[Josenivaldo Benito Junior]

2015-06-10 14:54 GMT-03:00 Diego Sueiro <diego....@gmail.com>:

Independe de quem deve resolver a bucha é sempre importante colocar no workflow que antes de se fazer commit e push o camarada atualize a sua cópia local do repositório.

Eu sou dessa linha também. O camarada faz o fork, fica 6 meses desenvolvendo algo e faz um PR depois disso sem "upmerge"? Fica difícil.

Agora se mesmo depois de atualizar dois PRs conflitam eu acho que valem duas opções:

-se é trivial o integrador (você) resolve

-se é bucha o dev que submeteu por último resolve afinal, ele que entende daquela feature, ele que sabe o que fazer com ela.

Trabalhei em um lugar que era assim e de certa forma bem rígido. Trabalhei em outro lugar que não era definido um workflow. Nesse segundo local era uma loucura, o dev fazia o PR e achava que o trabalho dele estava concluido, o dono do projeto que rebolasse para enviar aquilo no código. Sinceramente? O primeiro local funcionava bem melhor em termos de gerência de configuração e versionamento de código. No segundo o repositório funcionava mais como uma prateleira de código e o coitado do líder de projeto escolhia entre os ingredientes (commits) o que entraria no binário. Consegue ver o caos?

[Victor Augusto Furtado Leite]

Pra mim, se o cara faz um pull request sem dar um fetch e merge com o repo original, é quase como se no SVN você conseguisse dar um ci sem up... =/

--

Você recebeu essa mensagem porque está inscrito no grupo "sis_embarcados" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para sis_embarcado...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para sis_emb...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/sis_embarcados.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Victor Augusto Furtado Leite

[Felipe Neves]

Aqui costumamos fazer em equipe todo o processo, porém como o Diego disse ai em cima, um requisito obrigatório é primeiro atualizar a cópia local do repo que o desenvolvedor está trabalhando, depois disso manda o bom senso, usamos a prática de fazer merges tanto pequenos quanto possível para facilitar resolução em caso de conflito.

Abs.

Felipe

[Marcelo Jo]

  Valeu gente!

--
Você está recebendo esta mensagem porque se inscreveu no grupo "sis_embarcados" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para sis_embarcado...@googlegroups.com.

Para postar neste grupo, envie um e-mail para sis_emb...@googlegroups.com.
Visite este grupo em http://groups.google.com/group/sis_embarcados.
Para obter mais opções, acesse https://groups.google.com/d/optout.

[Felipe de Andrade Neves Lavratti]

Pô! O Puller que faça o Pull Request sem conflitos! No mínimo né! Código mais antigo ganha precedência.

[Marcelo Jo]

  Meu medo é que o desenvolvedor ao resolver o conflito faça cagada.. ele conhece o próprio código mas não necessariamente conhece o código do colega!  Aí fica a minha dúvida...

  Por outro lado o responsável do projeto não conhece ainda o código do puller, mas acabaria tendo que conhecer!  E aí José?

  Marcelo

--
Você recebeu essa mensagem porque está inscrito no grupo "sis_embarcados" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para sis_embarcado...@googlegroups.com.

Para postar nesse grupo, envie um e-mail para sis_emb...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/sis_embarcados.
Para mais opções, acesse https://groups.google.com/d/optout.

[Josenivaldo Benito Junior]

2015-06-10 17:29 GMT-03:00 Marcelo Jo <marc...@gmail.com>:

ele conhece o próprio código mas não necessariamente conhece o código do colega! 

ele pode não conhecer o código do colega mas sabe o que aquele módulo faz (ou deveria saber pelo menos já que está desenvolvendo ali). Ninguém melhor que ele para saber como o código dele se integra ao código já existente.

O responsável pela integração,  por outro lado, conhece o sistema como um todo, mas não sabe o que o dev estava tentando fazer naquele PR específico. 

Para mim, a responsabilidade é do dev.

--
Josenivaldo Benito Jr.

[Alain Mouette]

a maneira recomendada para esse tipo de coisa seria fazer primeiro uma alteração para APENAS inserir o novo hook/parametro/etc.. mantendo o mASTER funcional.
A partir daí, o desenvolvedor pode trabalhar na sua parte sem criar conflitos no futuro!!!

Alain Mouette
=== Projetos especiais: <http://lnkd.in/dEu8cNq> ===

[Leonel Inocencio]

Boa noite

O bom é ir fazendo merge para cada alteração, usamos umas versão unstable para isto.

Se aparecer conflitos, verifica qual modulo é conflitante e quem alterou por ultimo e tarefa relacionada e adotar:

- módulos conflitantes não afetam o seu, atualiza os módulos da sua maquina sem medo.

- conflitantes afetam o seu, chama o ultimo que alterou o modulo para discutir as mudanças a fim de não haver problemas maiores no futuros, senão pode sobrar pra ti a culpa do estrago, kkkk

- mudanças geradas pelos conflitos são muito grande, e acredite, isto pode acontecer, chama o gerente e dependendo, gera novo branch e discute depois com a equipe numa nova reunião do projeto, vai que este pepino vira uma novo modelo de salada.

Atenciosamente

Leonel B. Inocêncio

Celular: +55 46 9917-1856

skype: leonel inocencio

Leonel B. Inocêncio

Celular: +55 46 9917-1856

skype: leonel inocencio

[Leonel Inocencio]

[Euripedes Rocha Filho]

Somente acrescentando a discussão, no caso de uso do git um modelo que me agrada muito é o git flow:
http://nvie.com/posts/a-successful-git-branching-model/

Há uma extensão do git que entrega o fluxo pronto.

No caso de conflito o ideal como dito é o dev resolver antes de enviar pro master. Em caso de dúvidas o gerente está no máximo a um email de distância geralmente.

[Marcelo Jo]

  Sim, a gente usa git flow por aqui.. mas o problema de conflito vai sempre existir! =D

  Valeu pessoal pelas dicas!