O novo desenvolvedor não consegue acompanhar as fusões de filiais

214

Eu sou o novo desenvolvedor - esta é minha primeira posição de programação.

Meu problema é o seguinte: Usamos git - eu cortei uma ramificação de nossa ramificação develop e comecei a trabalhar na tarefa secundária que me foi atribuída. É muito lento, porque sou inexperiente. No momento em que estou pronto para mesclar minha ramificação novamente em develop , os outros fizeram tantas alterações que a resolução dos conflitos é esmagadora (na verdade, parece mais fácil desfazer meu trabalho e recomeçar a tarefa, o que obviamente não é uma solução sustentável).

Como eu supero isso? Existe uma tática que eu possa usar além de "ser melhor em codificação"? Eu pretendo trazer isso com meu supervisor na próxima semana.

    
por daisy 17.08.2018 / 14:37
fonte

13 respostas

282

Eu suponho que você esteja usando o git. Em caso afirmativo, use git rebase -i (o -i significa interativo). Faça disso uma tarefa diária (ainda mais frequentemente, se necessário) para rebase seu ramo contra o ramo em desenvolvimento. Isso traz mudanças incrementalmente todos os dias (pelo menos) para manter o ramo de recursos atualizado. Se houver conflitos durante seu rebase diário, você precisa conversar com sua equipe sobre quem está trabalhando em quê.

Se você executá-lo diariamente, provavelmente não precisará da parte interativa. Apenas deixe que ele faça o seu trabalho.

Sou um desenvolvedor bastante experiente e ainda preciso de um pouco de tempo para acelerar um novo projeto. No seu caso, parece que você tem várias pessoas trabalhando no mesmo projeto simultaneamente, então é um projeto muito grande ou um novo projeto que está evoluindo rapidamente. Em ambos os casos, não se preocupe se você levar vários meses para entrar no fluxo. Se eu mudar de projeto por 2 ou 3 semanas e depois voltar, pode levar algumas horas (ou até mesmo um ou dois dias) para entrar de novo em "um projeto que eu escrevi 100% sozinho!

Em suma, não se preocupe em ser lento agora. A maneira de melhorar é apenas continuar praticando. Não tenha medo de perguntar a outros desenvolvedores sobre aspectos dos projetos que você não entende.

    
por 17.08.2018 / 15:23
fonte
129

Isso pode ser um sinal de má engenharia de software por parte da empresa. Muitas inter dependências, problemas diferentes com recursos sobrepostos, tentativas de resolver problemas na ordem errada etc. podem causar a situação que você está descrevendo. Sugiro que você mescle develop regularmente em sua filial durante o desenvolvimento

    
por 17.08.2018 / 14:49
fonte
94

As respostas aceitas que eu acho que são mais técnicas "como usar o Git melhor", eu acho que isso é mais um problema de equipe do que um problema de engenharia ou ferramental.

Se você encontrar muitos conflitos de mesclagem, isso significa que você e outra pessoa da equipe estão pisando nos dedos uns dos outros.
Você ou eles devem procurar desenvolver espaço pessoal durante a codificação e evitar trabalhar em áreas que já estão ocupadas.

Na minha equipe, tendemos a um alto grau de propriedade de tarefas.
Em geral, tomo posse total e completa de dois ou três arquivos por vez e trabalho neles em um ramo por um dia ou dois no máximo.
Normalmente, se alguém tocar nesses arquivos, é apenas necessário para suas próprias tarefas, mas geralmente não trabalhamos juntos no mesmo bloco de tarefas!

Se você acha que precisa mesclar muito, então o código de todas as equipes está em um só lugar (que é algo a ser evitado por si só) ou todas as suas tarefas.

Tudo isso dito, como um novo desenvolvedor, você provavelmente não está em posição de impor, solicitar ou mesmo sugerir qualquer tipo de reestruturação.
O que eu espero é que as suas tarefas tenham sido designadas como "aprender as coisas" que devem ser razoavelmente acessíveis ao seu nível de habilidade, a fim de facilitar a entrada na equipe. Eles provavelmente foram selecionados das tarefas de um colega de trabalho que ainda está trabalhando na mesma área, daí seus conflitos de fusão. A solução para isso, então, é se livrar dele, resolver os problemas, lidar com os conflitos de mesclagem da melhor maneira possível e não se preocupar muito, contanto que você esteja fazendo o melhor possível. seu progresso.
Você ficará mais rápido e mais confiante à medida que avança, e seus colegas de trabalho lhe darão mais autonomia e prejudicarão menos suas conseqüências.

    
por 17.08.2018 / 16:54
fonte
25

A coisa mais importante sobre a fusão é que quanto mais você espera, mais doloroso fica. E o problema cresce mais que linear. Três vezes mais conflitos são nove vezes mais trabalhos. Existem algumas estratégias:

Combine com o ramo de desenvolvimento sempre que ele mudar, assim você estará sempre perto dele e nunca terá um grande número de conflitos.

Se você demorar muito, talvez seja porque você gasta a maior parte do tempo tentando descobrir quais são as alterações e, em seguida, uma pequena quantidade de tempo para implementar as alterações. Se for esse o caso, mescle-se com o ramo de desenvolvimento antes de iniciar as alterações reais do código.

Converse com seus colegas sobre estratégias para evitar conflitos. Você começa conflitos se duas pessoas editarem o mesmo código. Não apenas o mesmo arquivo, mas o mesmo código. Então, eu preciso de uma nova função functionA e você precisa de uma nova função functionB, e nós dois a adicionamos no final do mesmo arquivo, nós temos um conflito. Se adicionarmos em lugares diferentes, não há conflito. Se nós os adicionarmos em um lugar no arquivo em que ele logicamente pertence, provavelmente não teremos conflitos.

Se você tiver conflitos, obtenha uma boa ferramenta de comparação, para poder comparar a ramificação de desenvolvimento antes de sua mesclagem, seu código antes da mesclagem, seu código original e o código mesclado e mesclar por mão.

Pior caso: você não joga fora seu trabalho, mas usa uma boa ferramenta de comparação para descobrir exatamente quais alterações você fez, ramificar novamente a partir do desenvolvimento e aplicar todas as alterações feitas manualmente em vez de redigitá-las.

    
por 17.08.2018 / 23:06
fonte
15

By the time I'm ready to merge my branch back into develop (emphasis mine)

O gerenciamento de conflitos em git merge costuma ser mais simples do que em git rebase . No Git merge você pode ver toda a lista de arquivos que foram modificados de uma só vez. Não importa quantos commits tenham sido feitos por outros colegas de trabalho, você precisará mesclar uma vez . Com o fluxo de trabalho de rebase, você pode acabar recebendo os mesmos conflitos várias vezes e ter que revisá-los manualmente. Você pode acabar consertando o 13º commit e sentir que você não consegue ver a luz do túnel .

Pela minha experiência, quando tentei ingenuamente resolver conflitos repetidos de rebase, acabei perdendo as modificações de alguém ou com uma aplicação que nem sequer compilaria. Muitas vezes eu e meus colegas de trabalho trabalhavam muito, mas ficávamos tão impressionados com a complexidade de repetir conflitos que tivemos que abortar e perder nosso trabalho anterior depois de alguns commits de rebase.

Vou sugerir algumas técnicas, mas elas só podem ajudar a união a se tornar mais fácil do que automatizar a tarefa.

  • Arquivos de recursos / idiomas . Se você tiver alterações aditivas em um arquivo de recursos, lembre-se de movê-las sempre para o final do arquivo para poder lembrar facilmente suas alterações em relação a outras
  • faça. Não. ABSOLUTAMENTE. RE-format . Nem você nem seus colegas desenvolvedores devem executar uma "reformatação maciça de código" durante o trabalho diário. Reformatação de código adiciona um número excessivo de falsos positivos no gerenciamento de conflitos. Reformatação de código pode ser feita
    • Incrementalmente, por exemplo por cada desenvolvedor em cada commit, assim que eles usam uma ferramenta automatizada (por exemplo, o Eclipse tem uma opção para reformatar quando salvo, o Visual Studio não tem nenhum). Absolutamente todo desenvolvedor deve usar os mesmos padrões de formatação de código, codificados em um arquivo de formato que é comido pelo seu IDE. Para se ter uma ideia, se são 4 espaços ou 2 guias, isso não importa, mas realmente importa se todos usam o mesmo.
    • Pouco antes do lançamento, por um líder de equipe. Se um commit de "reformatar código" ocorrer quando as pessoas não estiverem trabalhando em filiais, ou seja, antes de se ramificarem, as coisas tornarão mais fácil
  • Revise o trabalho dividido entre colegas de trabalho. Essa é a parte em que a maior parte da engenharia vem. Como apontado por outras respostas, é o cheiro do design se vários desenvolvedores que executam tarefas diferentes precisarem tocar nos mesmos recursos. Você pode ter que discutir com o líder de sua equipe sobre qual parte deve ser modificada por cada desenvolvedor concorrente.

Eu também tenho visto alguns maus hábitos nos fluxos de trabalho do Git nas minhas equipes. Muitas vezes as pessoas supercomprometem seus galhos. Eu pessoalmente testemunhei um desenvolvedor adicionando de 10 a 20 commits com o rótulo "fix", cada um comprometendo uma ou duas linhas. Nossa política é que os commits são rotulados com tickets do JIRA para que você tenha uma ideia.

@JacobRobbins sugere tornar git rebase uma tarefa diária. Eu gostaria de empurrar sua abordagem para frente.

Primeiro, use rebase apenas para reduzir o número de commits para um punhado. E rebase apenas para o ramo de desenvolvimento original , que é o commit do qual você se ramificou. Quando eu digo punhado, eu poderia significar 3 ou 4 (por exemplo, todos os front-end, todos os back-end, todos os patches do banco de dados) ou qualquer valor humanamente razoável. Depois de consolidá-los, use fetch e trabalhe seu rebase na ramificação upstream. Isso não irá salvá-lo do conflito, a menos que sua equipe revise sua própria abordagem, mas tornará sua vida menos dolorosa.

Se você tiver perguntas adicionais sobre as tarefas específicas, sinta-se à vontade para pesquisar e perguntar no Stackoverflow.

[Editar] sobre a regra de não-reformatação e escoteiro. Reformulei um pouco o RE-format para destacar que o que estou querendo dizer é a tarefa de formatar do zero todo o arquivo de origem, incluindo o código que não foi tocado por você. Ao contrário de sempre formatar seu próprio código, o que é perfeitamente boy-scouty, vários desenvolvedores, inclusive eu, são usados para reformatar o arquivo inteiro com os recursos do IDE. Quando o arquivo é tocado por outros, mesmo que as linhas afetadas não sejam alteradas em seus conteúdos e semânticas, o Git o verá como um conflito. Apenas um editor de linguagem sensível muito poderoso pode sugerir que o conflito está relacionado apenas à formatação e à mesclagem automática do fragmento formatado melhor. Mas eu não tenho provas de tal ferramenta.

Afinal, a regra do escoteiro não obriga você a limpar a bagunça de outras pessoas. Apenas o seu.

    
por 19.08.2018 / 13:22
fonte
5

Você recebe conflitos de mesclagem se as alterações feitas em sua ramificação estiverem próximas às alterações que seus colegas fizeram na ramificação develop nesse meio tempo, ou seja, se você e seus colegas alteraram as mesmas linhas de código ou linhas adjacentes o mesmo arquivo.

Para reduzir a probabilidade de conflitos de mesclagem, você pode tentar mesclar mais cedo para que seus colegas alterem menos linhas nesse meio tempo, ou você mesmo pode tentar alterar menos linhas.

Para alterar menos linhas, certifique-se de fazer apenas alterações relacionadas à sua tarefa.

Se você precisa experimentar diferentes maneiras de atingir sua meta, talvez algumas de suas experiências tenham alterado as linhas que realmente não precisam ser alteradas? Anule estas alterações antes de se fundir.

Existem também alguns comandos do Git que podem ajudá-lo a alterar o menor número possível de linhas:

  • git diff e git diff --staged para ver quais linhas você alterou.
  • git add -p para adicionar apenas algumas das suas alterações em um arquivo.
  • git commit --amend e git rebase -i para ajustar os commits que você já fez no seu branch local antes de enviá-los para outros repositórios Git.

(Alterar o menor número de linhas possível também facilita a revisão de seu trabalho ou o uso de ferramentas que funcionam nas diferenças entre confirmações, como git cherry-pick , git rebase , git bisect e git blame .)

Mas mesmo que você reduza a probabilidade de conflitos de mesclagem, você ainda terá conflitos de mesclagem às vezes. Portanto, não tenha medo deles, mas aprenda a resolver os conflitos.

    
por 18.08.2018 / 13:19
fonte
5

Primeiro, não pense em descartar suas alterações. Você perderá oportunidades de aprender o processo de mesclagem.

Em segundo lugar, encontre uma pessoa que tenha trabalhado nos arquivos causando conflitos. Você pode ver o histórico. Converse com a pessoa e resolva os conflitos nesses arquivos. Faça o mesmo para outros conflitos.

Se houver muitos conflitos, sua tarefa pode ser menor, mas repetitiva. Tente encontrar um padrão. Isso ajudaria na resolução de conflitos pelas ferramentas do cliente Git UI. Eu uso o TortoiseGit. Isso ajuda na mesclagem.

E para evitar no futuro,

  • É uma prática muito boa mesclar o ramo de desenvolvimento regularmente ao seu ramo de recursos.

  • Se você tiver o IC ativado, veja se a ferramenta de IC fornece uma criação de ramificação. Isso deve ser feito a partir de todas as verificações feitas em sua ramificação de recursos, mas depois da ramificação de desenvolvimento de mesclagem.

por 17.08.2018 / 22:07
fonte
1

Você deve executar regularmente (diariamente) o comando 'git fetch' (não git pull) do seu branch de desenvolvimento. Isso fará com que outras pessoas comprometam as alterações e as coloquem em seu ramo de recursos sem tentar integrar as mudanças em seu ramo.

Isso é algo com o qual você deve conversar com o desenvolvedor líder (não necessariamente com seu gerente), porque sua empresa pode ter seus próprios padrões ou maneiras recomendadas de lidar com esse problema; é muito comum Não espere até a próxima semana - descubra o processo agora e pergunte se você pode realizar algum trabalho trivial (como formatação de código ou adicionar comentários) para testar o processo.

    
por 17.08.2018 / 15:03
fonte
1
Obviamente, a primeira coisa é evitar que várias pessoas trabalhem nos mesmos arquivos, pelo menos de uma forma que leve a conflitos difíceis. Adicionar coisas em enumerações não é problema, desde que seja usado um bom formato de código. Alterar o fluxo de controle de diferentes maneiras e mover o código é muito mais complicado. Às vezes isso é inevitável, no entanto. Você precisará fazer perguntas ao resolver conflitos que sejam realmente complexos.

Dito isso, vejo muitas respostas recomendando a fusão / rebase para desenvolver regularmente. Eu ficaria muito menos entusiasmado com esse tipo de conselho. Seu objetivo neste momento é tornar o processo de solução de conflitos o mais fácil e seguro possível. Uma coisa que vai ajudar tremendamente nesse processo é ter tantos testes de regressão imediatamente disponíveis, incluindo os novos que fazem parte do seu novo recurso. Se você sincronizar sua filial regularmente com o desenvolvimento, você invariavelmente acabará tendo que resolver os conflitos enquanto estiver na metade da implementação do seu recurso. E isso significa que será muito mais difícil tentar descobrir o que o código deve fazer, já que você não terminou com isso. Antes de tentar mesclar, certifique-se de que sua ramificação seja uma unidade coerente de mudança. Melhor ainda, faça o rebase em um único commit antes de mesclar.

Eu tentei não entrar nos méritos de rebase sobre mesclagem, o que provavelmente é para outra questão. Neste contexto, as ferramentas realmente não importam.

    
por 20.08.2018 / 18:23
fonte
1

By the time I'm ready to merge my branch back into develop the others have made so many changes that resolving the conflicts is overwhelming

Isso parece um cenário ideal para programação em pares !

Mais informações sobre os benefícios e abordagens básicas:

Você naturalmente acelerará com o tempo de trabalhar sozinho, mas pode ser assustador até que chegue a hora, e às vezes é um longo caminho também. Além disso, enquanto as pessoas podem aprender rapidamente em um ambiente estressante, sempre pressionadas para acompanhar, outras que não aprendem bem sob pressão constante serão prejudicadas.

Em vez de trabalhar em uma ramificação por conta própria e tentar acompanhar outros desenvolvedores que são obviamente muito mais rápidos do que você, você deveria trabalhar diretamente (mesmo PC) com outro desenvolvedor. Desta forma, você obtém conselhos instantâneos e provavelmente irá obter dicas sobre como acelerar, etc.

Você teria descoberto a melhor abordagem para o código específico em seu projeto, já que a programação em pares nem sempre faz sentido para alguns projetos - embora, sem dúvida, sempre faça sentido aprender, mesmo se você simplesmente sentar e assistir a alguém mais mais experiente do que você (desde que seja um bom desenvolvedor, a experiência não significa necessariamente que eles usem boas práticas).

Estar com um desenvolvedor mais rápido e experiente tem o potencial de ajudar:

  • Provavelmente reduzirá os conflitos de mesclagem, já que trabalhar com alguém mais experiente aumentará o tempo de conclusão, em vez de trabalhar sozinho
  • Como eles vão te ensinar, é provável que sejam mais lentos do que se estivessem trabalhando sozinhos, então ainda pode haver alguns conflitos de mesclagem e, assim, trabalhar com alguém experiente e, assim, talvez pegar algumas dicas sobre como economizar tempo etc
  • Ajudar você a ver possíveis truques e maneiras de ser mais rápido (embora ser lento às vezes seja simplesmente uma falta de experiência em vez de uma falta de boas práticas)
  • Pode fazer perguntas imediatamente quando algo não faz sentido ou não é 100% claro
  • O trabalho 1: 1 é valioso para o aprendizado porque a pessoa a quem você pedir ajuda já entende o código e o cenário exatos enquanto trabalha, sem programação em pares você precisa explicar o código e o cenário, que geralmente acaba um problema e assim você perde seu tempo / atenção na obtenção de conselhos muito necessários
  • Conheça o processo de pensamento de alguém mais experiente e experiente e, com boas comunicações, você certamente aprenderá coisas novas

Is there a tactic I can use other than 'be better at coding'? I intend to bring this up with my supervisor next week.

Meu conselho é discutir a programação em pares com os outros desenvolvedores e depois abordar seu supervisor. Se forem decentes, apreciarão sua iniciativa, que tem mais chances de você lançar as vantagens da programação em pares (se precisarem, a maioria das pessoas sabe disso e é de conhecimento geral por que isso ajuda).

    
por 22.08.2018 / 12:30
fonte
1

Existem alguns problemas subjacentes aqui. Seus problemas de fusão provavelmente não são culpa sua e são mais comumente um sintoma de más práticas.

1) Idealmente você iria mesclar seu ramo para desenvolver todos os dias. Tente ter um código de trabalho pelo menos uma vez por dia que passe em todos os testes para que você possa se fundir no desenvolvimento.

2) Se você não tem código de trabalho a qualquer momento durante o seu dia de trabalho normal, você provavelmente tem pedaços de código muito grandes para trabalhar. Você precisa dividir sua tarefa em tarefas menores que podem ser concluídas (idealmente independentemente umas das outras) mais rapidamente, para que você possa mesclar.

3) Seus arquivos de projetos provavelmente são muito grandes. Se houver muitos conflitos de mesclagem para um arquivo, há muitas pessoas trabalhando em um arquivo. Idealmente, algo em que uma pessoa está trabalhando deve estar separado do que todo mundo está trabalhando.

4) Sua equipe pode ser muito grande. Se você achar mais fácil descartar um recurso inteiro e começar de novo, é provável que haja muitas pessoas comprometendo o código com o mesmo repositório.

5) Você pode não ter padrões consistentes de formatação de código. Se nem todos usarem consistentemente a mesma formatação de código, você terá muitos conflitos diferentes para o mesmo código. Dependendo de como o seu git é configurado, eles podem até chegar a conflitos de espaço em branco (terminações de linha, recuo, tabulações versus espaços).

6) As pessoas podem estar empurrando suas mudanças diretamente para o ramo de desenvolvimento.

Veja o que você pode fazer: 1) Se você não pode se fundir em desenvolver todos os dias, mesclar / rebase desenvolver em sua filial todos os dias (ou com mais freqüência). 2) Tente ter seu código separado do código de qualquer outra pessoa.
3) Converse com o restante da equipe sobre recursos menores, padrões de codificação consistentes e melhor organização do código (arquivos menores, funções menores).

    
por 22.08.2018 / 18:42
fonte
1

It actually seems easier to scrap my work and start over on the task, which of course is not a sustainable solution)

Na maioria das vezes, isso é o que eu faço, na primeira vez que eu corrijo um bug ou faço uma alteração no sistema, estou aprendendo sobre como fazer isso. Da próxima vez que eu corrigir o mesmo bug, isso levará apenas 1% do tempo, já que agora entendi o problema.

Eu também acho que quando refaz um pouco de trabalho, escrevo melhor código .....

Portanto, não há nada de errado em criar um novo branch a partir do master, refazendo seu trabalho nele, enquanto usa seu "private branch" para lembrar o que você precisa fazer.

Também é possível que você tenha descoberto uma maneira de dividir sua alteração em partes lógicas e corretas, cada uma que seja mesclada na ramificação principal depois de concluída. Por exemplo, os testes de unidade e as alterações no código de backend podem ser feitos e mesclados. Em uma operação separada, você pode fazer as alterações de interface do usuário que fazem uso deles e, portanto, tem menos risco de alguém editar o mesmo arquivo de interface do usuário.

    
por 23.08.2018 / 20:46
fonte
1

Se você não quiser mesclar a ramificação de desenvolvimento em sua ramificação com muita freqüência, poderá obter um fluxo de trabalho mais parecido com o svn usando git pull --rebase . Isto irá puxar os novos commits e rebase seus commits neles. Isso significa que, quando você mescla sua ramificação em desenvolvimento, ela será uma mesclagem rápida (como se você tivesse adicionado todos os seus commits passados ao mesmo tempo, um após o outro) e não tivesse nenhum conflito de mesclagem, porque você resolveu todos eles durante %código%.

Mas quanto mais commits você fizer antes de fundir sua ramificação em desenvolvimento ou desenvolvimento em sua ramificação, mais complicado será o próximo rebase e isso subverterá um pouco o sentido de ramificações de recursos, já que sua ramificação só existe enquanto está desimpedida.

    
por 24.08.2018 / 14:51
fonte