Novo desenvolvedor não consegue acompanhar as mesclagens de filiais

223

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

Meu problema é o seguinte: Usamos git- cortei uma ramificação de nossa developramificação e depois comecei a trabalhar na tarefa menor que me foi atribuída. É muito lento, porque sou inexperiente. No momento em que estou pronto para mesclar meu ramo com developos outros, fizemos tantas mudanças que a solução dos conflitos é esmagadora (na verdade, parece mais fácil descartar meu trabalho e começar de novo a tarefa, o que, obviamente, não é uma solução sustentável )

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

— margarida
fonte

165

você não precisa mesclar apenas sua ramificação para desenvolver apenas quando terminar. você pode mesclar o desenvolvimento em sua ramificação de recursos de forma incremental sempre que quiser, para diminuir a mesclagem final.

— DavidB

16

Certifique-se de estar fazendo o processo de fusão corretamente. Apenas seus arquivos devem ser afetados e apenas suas alterações devem ser aplicadas ao ramo de desenvolvimento. Se você estiver tendo conflitos aleatórios, é provável que você tenha feito a mesclagem errada ou outras pessoas estejam atrapalhando a ordem da revisão. É uma boa chance de educar a si mesmo e, possivelmente, outros a se fundir corretamente. Algumas pessoas têm dificuldade em entender suas alterações, não os arquivos que estão sendo mesclados. Portanto, as revisões ordenadas fora de sincronia causariam conflitos nos arquivos que você nunca tocou.

16

Verifique também se o seu editor está definido corretamente. Às vezes, os editores "corrigem" guias e espaços; portanto, quando você edita um arquivo e tenta confirmar, ele altera o arquivo inteiro. Antes de confirmar, certifique-se de que apenas suas alterações estão sendo confirmadas na ramificação e corrija seu editor.

32

Há uma coisa estranha aqui: "Começo a trabalhar em uma tarefa menor" e toneladas de conflitos de mesclagem normalmente não coincidem. Acabei de mesclar um ramo de atualização importante de duas semanas em um desenvolvimento experimental e tivemos 10 (!) Conflitos que não eram resolvíveis automaticamente. Você não recebe muitos conflitos, a menos que sua tarefa seja "alterar nomes de variáveis em todos os arquivos". Não para tarefas MENORES.

— TomTom

50

Xkcd

— ED

5

Você obtém conflitos de mesclagem se as alterações feitas em sua ramificação estiverem próximas das alterações feitas por seus colegas na developramificação, ou seja, se você e seus colegas alteraram as mesmas linhas de código ou linhas adjacentes no mesmo arquivo.

Portanto, para reduzir a probabilidade de conflitos de mesclagem, tente mesclar mais cedo para que seus colegas alterem menos linhas nesse meio tempo ou tente alterar menos linhas por conta própria.

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

Se você precisar experimentar maneiras diferentes de atingir seu objetivo, talvez algumas de suas experiências tenham mudado de linha que realmente não precisam ser alteradas? Desfazer essas alterações antes de mesclar.

Existem também alguns comandos Git que podem ajudá-lo a alterar o mínimo de linhas possível:

git diffe git diff --stagedpara ver quais linhas você mudou.
git add -p para adicionar apenas algumas de suas alterações em um arquivo.
git commit --amende git rebase -iajustar os commit que você já fez no seu ramo de recursos local antes de enviá-los para outros repositórios Git.

(Mudar o menor número de linhas possível também pode tornar mais fácil para rever o seu trabalho ou de usar ferramentas que trabalham sobre as diferenças entre comete tais como git cherry-pick, git rebase, git bisect, e git blame.)

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

— Toxaris
fonte

11

Também antes de se fundir, uma git fetche git diff origin/developvai mostrar uma prévia do seu merge (tipo de). Dá a você a chance de limpar suas alterações antes de obter uma tonelada de conflitos sem sentido.

— Max

288

Presumo que você esteja usando o git. Nesse caso, use git rebase -i(o -imeio interativo). Faça uma tarefa diária (ainda mais frequentemente, se necessário) refazer sua ramificação contra a ramificação revelada. Isso traz as alterações de forma incremental todos os dias (pelo menos) para manter sua ramificação de recursos atualizada. Se houver conflitos durante o rebase diário, você precisará conversar com sua equipe sobre quem está trabalhando no quê.

Se você executá-lo diariamente, provavelmente não precisará da parte interativa. Apenas deixe fazer o que quiser.

Sou um desenvolvedor bastante experiente e ainda me leva um pouco de tempo para me atualizar sobre um novo projeto. No seu caso, parece que você tem várias pessoas trabalhando no mesmo projeto simultaneamente; portanto, é 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 alternar projetos por 2 ou 3 semanas e depois voltar, pode levar algumas horas (ou até um dia ou dois) para voltar totalmente a um projeto que escrevi 100% sozinho!

Em suma, não se preocupe em ser lento no momento. 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.

EDITAR:

Ou use merge. Essa também é uma opção. Portanto, o acima seria: "use git rebase -i(os -imeios interativos) ou git merge". Quanto a qual usar, converse com o resto de sua equipe. Eles podem (ou não) ter fortes preferências de qualquer maneira. É claro que algumas pessoas não têm preferências fortes.

— Jacob Robbins
fonte

22

Eu acho que essa é a resposta correta, mas, na IMO, apenas mais um exemplo de design e terminologia ruins do Git. Apenas o que você está "rebatizando"? Isso não deveria ser chamado de "atualização" ou "checkout" ou "mesclagem" ou algo parecido ??? (Uma resposta abaixo argumenta por "buscar") Qual é o sentido do controle do código-fonte se todos os dias você é forçado a atualizar ???

— user949300

95

Não está atualizando ou fazendo check-out. É pegar o que estiver exclusivamente em sua ramificação e adicionar suas alterações como se você as tivesse feito agora na outra ramificação. Ou seja, suas alterações agora são "baseadas" no outro ramo. Além disso, não existe nenhum sistema mágico de controle de origem que conheça seu código e saiba como mesclar alterações quando várias pessoas modificam os mesmos arquivos. Você atualiza todos os dias para manter os conflitos pequenos e gerenciáveis, e as mudanças frescas na mente de todos, para que eles saibam como lidar com eles.

— Vectorjohn

54

O rebasing do @ user949300 é diferente da fusão, é muito mais matizado e requer uma melhor compreensão do Git do que um simples fluxo de trabalho de mesclagem. É por isso que eu nunca recomendo um fluxo de trabalho que envolva rebaseamento para um iniciante no Git, porque leva à suposição de que rebasear é a única maneira / padrão de atualizar um branch e leva a muitas armadilhas e problemas desnecessários. Nesse caso, a mesclagem resolverá o problema da mesma maneira e também não resolverá o problema de conflitos de mesclagem em dois ramos de recurso paralelo de longa duração.

— Ant

14

@ user949300, git pullque é apenas uma combinação de git fetche git merge(ou você pode adicionar --rebasepara fazer uma rebase em vez de mesclar). Supondo que você esteja com apenas um dia de atraso e, em uma LAN, isso provavelmente será concluído em menos de segundo, poderá demorar alguns segundos na Internet. Mesmo na Internet e com pequenos conflitos de mesclagem, você pode estar atualizado e mesclado corretamente em menos de um minuto. Passar cinco minutos espalhados por toda a semana é muito melhor do que passar uma hora no final da semana lidando com um conflito de fusão.

— Derek Elkins

66

Nenhum voto positivo de minha parte, porque esta resposta está totalmente fixada no rebasamento. O rebaseamento pode ser uma ferramenta útil, mas nunca deve ser usada sem pensar. Para a atualização diária, é melhor mesclar. Por quê? Porque toda rebase é uma mentira . Você está contando a história de uma maneira que nunca aconteceu. Isso pode ferrar ferramentas poderosas como git bisect: O material rebasado pode nem ser compilado, por isso git bisecté inútil nos commits quebrados resultantes. @maaartinus: Eu, por exemplo, prefiro a história verdadeira ao invés da história linear. Se você se recuperar, é absolutamente necessário verificar cada novo comprometimento quanto à sanidade para evitar mentiras prejudiciais.

— Cmaster 18/08/19

131

Isso pode ser um sinal de engenharia de software ruim por parte da empresa. Muitas interdependências, problemas diferentes com recursos sobrepostos, tentar resolver problemas na ordem errada etc. podem causar a situação que você está descrevendo. Sugiro mesclar regularmente developem seu ramo durante o desenvolvimento

— Ivan Anatolievich
fonte

9

Isso está codificando 101 coisas como você mencionou. Não é necessariamente uma reflexão precisa sobre o novo funcionário.

— Mister Positive

2

@Ivan Anatolievich OP diz que eles estão ramificou-se de desenvolver, não dominar, FYI

— Matthew FitzGerald-Chamberlain

6

Essa resposta mostra exatamente por que eu não gosto do GIT: é outra ferramenta para as equipes evitarem um gerenciamento adequado e um planejamento decente. A resposta para tudo é "quem se importa, você sempre pode usar esse comando mais tarde", em vez de evitar problemas antes que eles aconteçam.

— motoDrizzt

7

meu primeiro pensamento também foi um sinal de práticas inadequadas, os desenvolvedores não deveriam estar trabalhando nos mesmos arquivos em sua maior parte. Se um projeto pequeno está tendo tantos conflitos, todos os outros devem apenas resolver conflitos o dia inteiro sem fazer nenhum trabalho!

— Aequitas

14

@motoDrizzt What? Eu nunca ouvi alguém fazer esse argumento.

— precisa saber é

95

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

Se você estiver enfrentando muitos conflitos de mesclagem, significa que você e outra pessoa da equipe estão pisando nos dedos uns dos outros.
Você ou eles devem ter como objetivo 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 da tarefa.
Normalmente, tomarei a propriedade total e completa de dois ou três arquivos de cada vez e trabalhei neles em uma filial por um dia ou dois.
Normalmente, se alguém tocar nesses arquivos, é apenas se for absolutamente necessário para suas próprias tarefas, geralmente não trabalhamos juntos no mesmo bloco de tarefas!

Se você achar que precisa mesclar bastante, o código de todas as equipes está em um único lugar (o 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 até mesmo sugerir qualquer tipo de reestruturação.
O que eu esperaria é que suas tarefas tenham sido designadas como material "aprenda as cordas" que devem ser razoavelmente acessíveis no seu nível de habilidade para 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 mesclagem.
A solução para isso é resolvê-lo, resolver os problemas, lidar com os conflitos de mesclagem da melhor maneira possível e não se preocupar muito, desde que você esteja fazendo o possível, cabe ao seu gerente se preocupar com seu progresso.
Você ficará mais rápido e mais confiante à medida que avança,

— Rowan
fonte

4

Eu acho que você acertou na cabeça com o conflito de colegas de trabalho. Conflitos de mesclagem são comuns, mas geralmente são limitados a um punhado de arquivos.

— Matthieu M.

10

Isso soa como um corolário da Lei de Conway e do princípio da responsabilidade única - ou seja, se as pessoas estão trabalhando em problemas diferentes, o ideal é que elas editem partes separadas do código-fonte.

— ChrisW

7

Embora eu concorde que um processo ruim ou um design ruim possa levar a uma grande quantidade de conflitos, estou bastante confiante de que a questão é simplesmente que o OP não está se mesclando na linha principal regularmente. Não concordo que "tomar posse total e completa" dos arquivos seja apropriado, como é óbvio. Não quero que minha equipe tenha uma sobrecarga constante de controlar quem "possui" o que agora, pedindo "permissão" para fazer alterações ou adivinhando quais arquivos eles devem "reivindicar". Apenas raramente, ao reescrever significativamente um componente, pedi aos membros da equipe que me informassem se eles iam alterar determinados arquivos.

— Derek Elkins

11

ChrisW tem a idéia certa com o que eu estava dirigindo. De um modo geral, a propriedade da minha empresa assume a forma de funcionalidade do aplicativo, como propriedade de toda a organização do sistema Filtro de Pesquisa e, como acontece, ninguém precisa tocar nos arquivos relacionados na maioria das circunstâncias. Meu sentimento é que é muito provável que o OP já que um novo iniciante receba pequenas partes de tarefas estreitamente relacionadas a um conjunto de tarefas em andamento por outro desenvolvedor. Isso significa que o outro desenvolvedor está trabalhando na mesma parte da base de código e está se metendo no caminho um do outro.

— Rowan

11

@Rowan Cool sim, eu pensei isso. A separação de funcionalidade também pode ajudar na separação de arquivos (conjuntos de funções em arquivos diferentes, etc.) e este IMO ajuda na mesclagem.

— precisa saber é o seguinte

28

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 trabalho. Existem algumas estratégias:

Mesclar com o ramo de desenvolvimento sempre que ele muda, para que você esteja sempre próximo e nunca tenha um grande número de conflitos.

Se você demorar muito, pode ser porque você passa a maior parte do tempo descobrindo quais são as alterações e, em seguida, uma pequena quantidade de tempo implementando as alterações. Se for esse o caso, mescle com a ramificação de desenvolvimento antes de iniciar as alterações reais do código.

Converse com seus colegas sobre estratégias para evitar conflitos. Você terá 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 a adicionamos no final do mesmo arquivo, temos um conflito. Se o adicionarmos em lugares diferentes, não haverá conflito. Se nós dois o adicionarmos em um local no arquivo em que ele pertence logicamente, é provável que não tenhamos conflito.

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

Na pior das hipóteses: você não joga fora o seu trabalho, mas use uma boa ferramenta de diferenças para descobrir exatamente quais alterações você fez, desvie novamente do desenvolvimento e aplique todas as alterações feitas manualmente em vez de digitá-las novamente.

— gnasher729
fonte

As ramificações de recursos se apresentam como outra forma de dívida tecnológica, em que as mudanças de upstream do ramo pai são como refatoração.

— Dan Lyons

Só que você tem que pagar essa dívida. Agora mesmo.

— gnasher729

15

Quando eu estiver pronto para mesclar meu ramo de volta ao desenvolvimento (grifo meu)

Lidar com conflitos git mergegeralmente é mais simples que em git rebase. No Git merge, você pode ver toda a lista de arquivos que foram modificados ao mesmo tempo. Não importa quantas confirmações foram feitas por outros colegas de trabalho, você precisará mesclar uma vez . Com o rebase do fluxo de trabalho, você pode acabar enfrentando os mesmos conflitos várias vezes e precisar revê-los manualmente. Você pode corrigir o 13º commit e sentir que não pode ver a luz saindo do túnel .

Pela minha experiência, quando tentei resolver ingenuamente conflitos repetidos de rebase, acabei perdendo as modificações de alguém ou com um aplicativo que nem sequer foi compilado. Frequentemente, eu e colegas de trabalho realizamos muito trabalho, mas ficamos tão sobrecarregados com a complexidade de repetir conflitos que tivemos que abortar e perder nosso trabalho anterior depois de algumas punições de rebase.

Vou sugerir algumas técnicas, mas elas só podem ajudar a mesclar a ficar mais fácil do que automatizar a tarefa.

Arquivos de recurso / idioma . Se você tem aditivos alterações em um arquivo de recurso, certifique-se sempre movê-los para o fim do arquivo para que você possa facilmente recordar as suas alterações contra outras mudanças '. Você pode copiar e colar suas alterações na parte inferior ou apenas remover os marcadores de conflito
Faz. Não. ABSOLUTAMENTE. Formato RE . Nem você nem seus colegas desenvolvedores devem executar uma "reformatação maciça de código" durante o trabalho diário. A reformatação de código adiciona um número excessivo de falsos positivos no gerenciamento de conflitos. A reformatação de código pode ser feita
- Incrementalmente, por exemplo, por todos os desenvolvedores em todas as confirmações, assim que eles usam uma ferramenta automatizada (por exemplo, o Eclipse tem a opção de reformatar ao salvar, o Visual Studio da baunilha não possui). Absolutamente todo desenvolvedor deve usar os mesmos padrões de formatação de código, codificados em um arquivo de formato que é consumido pelo seu IDE. Para se ter uma idéia, se são 4 espaços ou 2 guias, não importa, mas realmente importa se todos usam o mesmo.
- Pouco antes do lançamento, por um líder de equipe. Se uma confirmação de "reformatação de código" ocorrer quando as pessoas não estiverem trabalhando em ramificações, ou seja, antes de ramificar, as coisas ficarão mais fáceis
Analise a divisão do trabalho entre colegas de trabalho. Essa é a parte em que a maior parte da engenharia vem. Como apontado por outras respostas, é cheiro de design se vários desenvolvedores que executam tarefas diferentes precisam tocar nos mesmos recursos. Pode ser necessário discutir com o líder da equipe qual parte será modificada por cada desenvolvedor simultâneo.

Também vi alguns maus hábitos nos fluxos de trabalho do Git em minhas equipes. Muitas vezes, as pessoas se comprometem demais com seus ramos. Eu pessoalmente testemunhei um desenvolvedor adicionando de 10 a 20 confirmados rotulados como "correção", cada um comprometendo uma ou duas linhas. Nossa política é que os commits sejam rotulados com tickets JIRA para que você tenha uma idéia.

@JacobRobbins sugere fazer git rebaseuma tarefa diária. Eu gostaria de levar sua abordagem adiante.

Primeiro, use rebase uma vez apenas para reduzir o número de confirmações para um punhado. E rebase apenas no ramo de desenvolvimento original , que é o commit do qual você ramificou. Quando digo algumas, posso dizer 3 ou 4 (por exemplo, todo o front end, todo back-end, todos os patches do banco de dados) ou qualquer figura humanamente razoável. Depois de consolidá-los, use fetche trabalhe sua rebase na ramificação upstream. Isso não salvará você de conflitos, a menos que sua equipe revise sua própria abordagem, mas tornará sua vida menos dolorosa.

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

[Editar] sobre a regra de não reformatação e escoteiro. Reformulei um pouco o formato RE para destacar que o que quero 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, que é perfeitamente desprezível, vários desenvolvedores, inclusive eu, são usados para reformatar o arquivo inteiro com os recursos do IDE. Quando o arquivo é tocado por outras pessoas, mesmo que as linhas afetadas não sejam alteradas em seu conteúdo e semântica, o Git o verá como um conflito. Somente um editor com reconhecimento de idioma muito poderoso pode sugerir que o conflito está relacionado apenas à formatação e mesclagem automática do fragmento melhor formatado. Mas não tenho evidências de tal ferramenta.

Afinal, a regra dos escoteiros não exige que você limpe a bagunça de outras pessoas. Apenas seu.

— usr-local-ΕΨΗΕΛΩΝ
fonte

3

É em grande parte uma questão de opinião, mas discordo que conflitos de mesclagem são mais fáceis de lidar do que rebase de conflitos. Ao refazer, você aplica os commits essencialmente um por um, mantendo o escopo dos conflitos de mesclagem muito menores e mais fáceis de seguir (você aplica SUAS alterações que você conhece - não as alterações de outras pessoas que você não faz). Pode ser necessário resolver mais conflitos de mesclagem dessa maneira (devido ao toque nos mesmos arquivos várias vezes nas confirmações), mas eles serão menores e mais fáceis de resolver.

— user622505

3

Em relação à reformatação, enquanto o VS não pode fazer isso automaticamente ao salvar, se você definir "Quando colo" como "Recuar e formatar" em "Ferramentas" -> "Opções" -> "Editor de texto" -> "< Seu idioma de escolha> "->" Formatação ", isso significa que ele formata automaticamente ao colar. Isso permite que a sequência de três pressionamentos de teclas: ctrl-A, ctrl-C, ctrl-V tenha o resultado desejado. Dito isto, +1 para fazer. Não. ABSOLUTAMENTE. Reformatar. Exceto conforme descrito sob condições cuidadosamente controladas.

— dgnuff

11

Os leitores de Bob Martin devem observar que a regra dos escoteiros deve ser aplicada com restrição se você estiver trabalhando em equipe (se estiver trabalhando sozinho, terá muito mais flexibilidade). Se você interpretar a regra como "É meu dever como codificador corrigir literalmente tudo em todos os arquivos que não sejam perfeitos no instante em que eu descobrir sobre isso, não se preocupe com o que os outros estão trabalhando". uma quantidade gigantesca de conflitos difíceis de resolver, e será uma bagunça gigante, não importa quão boas sejam suas intenções.

— Jrh 20/08

2

Você sente a necessidade de reformatar ou refatorar levemente o código, fazê-lo antes ou depois do seu comprometimento significativo. Ele não só irá reduzir os conflitos, mas também ajuda futuro leitor de seus cometem, incluindo revisores

— max630

11

Na minha cultura C #, "reformatar" significa a ação de formatar um arquivo de código inteiro ou até mesmo um repositório inteiro em que a formatação está relacionada apenas à legibilidade . Se o seu idioma usar espaços em branco de forma significativa, você não deve mexer com espaços em branco nos LOCs que não são seus. Por outro lado, seu idioma de escolha ainda pode permitir espaços em branco não significativos (por exemplo, antes de um chaveta) que podem ser "reformatados" de acordo com um padrão de legibilidade

— usr-local-

5

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

Segundo, encontre uma pessoa que trabalhou nos arquivos que estão causando conflito. Você pode ver a história. Converse com a pessoa e resolva 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 a resolver conflitos pelas ferramentas de cliente da interface do usuário do Git. Eu uso o TortoiseGit. Ajuda na mesclagem.

E para evitar no futuro,

É uma prática muito boa mesclar o ramo de desenvolvimento regularmente ao ramo de recursos.
Se você tiver o IC ativado, veja se a ferramenta de IC fornece uma compilação de ramificação. Isso deve se basear em todas as verificações feitas no ramo de recursos, mas após a mesclagem, desenvolva o ramo.

— PKV
fonte

11

+1 As outras sugestões para usar melhor o Git são boas, mas conversar com outros desenvolvedores sobre conflitos de mesclagem é outro aspecto essencial para desenvolver a eficácia do OP.

— Dragonel

11

"Você pode ver a história" Talvez! Depende de como esmagado & rebased tudo é: P

— Leveza raças em Orbit

1

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

É algo sobre o qual você deve conversar com o desenvolvedor líder (não necessariamente 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 cometer algum trabalho trivial (como formatação de código ou adicionar comentários) para poder testar o processo.

21

Não tenho certeza se isso está correto. Git fetch vai ter controles remotos / origem / master até à data, mas então você precisa merge remotes / origin / master em seu ramo de recurso (ou controles remotos / origem / desenvolver se esse é o fluxo que eles estão usando)

— Richard Tingle

Supondo que ele esteja usando o git, também é uma boa idéia aprender como esmagar seu comprometimento com partes significativas. Dessa forma, quando você estiver pronto para fazer uma solicitação pull, seu commit será enxuto, direto e fácil de entender.

@RichardTingle Correto, ele está pensando em uma opção de rebase. Você simplesmente busca e refaz seu ramo com o ramo dev. Isso sincronizará tudo.

6

@ Dan Eu acho que isso pode ser uma questão de opinião. Pessoalmente, eu odeio compromissos maciços. Tente git dividir isso!

— precisa

2

@PeteCon "e leve-os para o seu ramo de recursos sem tentar integrar as alterações ao seu ramo". Parece uma afirmação contraditória. Eu acho que você quer dizer trazê-los para o seu repositório local sem integrá-los em seu ramo de funcionalidade, mas não tenho certeza de como isso ajuda ...

— Jason Goemaat

1

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

Dito isto, vejo muitas respostas recomendando mesclar / re-criar 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 ajudará tremendamente com esse processo é ter tantos testes de regressão disponíveis imediatamente, incluindo os novos que fazem parte do seu novo recurso. Se você sincronizar sua ramificação muito regularmente com o develop, invariavelmente acabará tendo que resolver 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, como você não fez com ele. Antes de tentar mesclar, verifique se o seu ramo é uma unidade coerente de mudança. Melhor ainda,

Tentei não entrar no mérito de rebase sobre mesclagem, o que provavelmente é para outra pergunta. Nesse contexto, as ferramentas realmente não importam.

— Kafein
fonte

1

No momento em que estou pronto para mesclar meu ramo de volta ao desenvolvimento, os outros fizeram tantas mudanças que resolver os conflitos é esmagador

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

Mais informações sobre os benefícios e abordagens básicas:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

Você naturalmente acelerará com o tempo trabalhando sozinho, mas pode ser assustador até esse momento chegar, e às vezes também é um longo caminho. Além disso, embora as pessoas possam aprender rapidamente a estar em um ambiente estressante sempre pressionado a se atualizar, outras pessoas que não aprenderem bem sob pressão constante serão prejudicadas.

Em vez de trabalhar em um ramo por conta própria e tentar acompanhar outros desenvolvedores que são obviamente muito mais rápidos que você, você trabalha diretamente (o mesmo PC) com outro desenvolvedor. Dessa forma, você recebe conselhos instantâneos e provavelmente receberá dicas de como acelerar etc.

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

Sentar-se com um desenvolvedor mais rápido e experiente tem potencial para ajudar:

Provavelmente reduzirá os conflitos de mesclagem, pois trabalhar com alguém mais experiente aumentará o tempo de conclusão, em vez de trabalhar sozinho
Como eles ensinam a você, é provável que eles sejam mais lentos do que trabalhariam sozinhos, por isso ainda podem haver alguns conflitos de mesclagem e por isso podem trabalhar com eles com alguém experiente e, talvez, pegar algumas dicas sobre como economizar tempo etc.
Ajudá-lo a ver truques em potencial e maneiras de ser mais rápido (embora ser lento às vezes seja simplesmente uma falta de experiência e não uma falta de boas práticas)
Pode fazer perguntas imediatamente quando algo não faz sentido ou não é 100% claro
Trabalhar 1: 1 é valioso para o aprendizado, porque a pessoa com quem você pediria ajuda já entende o código e o cenário exatos enquanto estão trabalhando nele. para que você perca seu tempo / atenção em obter realmente os conselhos necessários
Conheça o processo de pensamento de alguém mais experiente e experiente e, com boas comunicações, certamente aprenderá coisas novas

Existe uma tática que eu possa usar além de 'ser melhor em codificação'? Pretendo falar com meu supervisor na próxima semana.

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

— James
fonte

Honestamente, quem recusou :( isso não é um palpite, isso acontece no meu local de trabalho e está comprovadamente funcionando! ) apenas para ser capaz de sugerir "a programação em pares" em um presente, porque ninguém sugeriu que eu trabalhei muito duro para responder a esta..

— James

1

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

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

2) Se você não tiver código de trabalho em nenhum momento durante seu dia normal de trabalho, provavelmente terá grandes pedaços de código para trabalhar. Você precisa dividir sua tarefa em tarefas menores que podem ser concluídas (idealmente independentemente uma da outra) mais rapidamente para poder 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 ser separado do que todo mundo está trabalhando.

4) Sua equipe pode ser muito grande. Se você achar mais fácil jogar fora um recurso inteiro e recomeçar, é provável que haja muitas pessoas enviando código para o mesmo repositório.

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

6) As pessoas podem estar enviando suas alterações diretamente para o ramo de desenvolvimento.

Aqui está o que você pode fazer: 1) Se você não conseguir mesclar o desenvolvimento todos os dias, mescle / rebase desenvolva no seu ramo todos os dias (ou com mais frequência).
2) Tente separar seu código do código de todos os outros.
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).

— xyious
fonte

1

Na verdade, parece mais fácil descartar meu trabalho e recomeçar a tarefa, o que obviamente não é uma solução sustentável)

Na maioria das vezes, é isso que faço, na primeira vez em que corrigo um bug ou faço uma alteração no sistema, estou aprendendo sobre como fazê-lo. A próxima vez que eu corrigir o mesmo bug, leva apenas 1% do tempo, pois agora eu entendo o problema.

Também acho que, quando refiz um pouco de trabalho, escrevo um código melhor ...

Portanto, não há nada de errado em criar uma nova ramificação do mestre, refazendo seu trabalho nela, enquanto usa sua "ramificação privada" para lembrá-lo do 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 será mesclada na ramificação mestre depois de concluída. Por exemplo, os testes de unidade e as alterações no código de back-end podem ser feitos e mesclados. Em uma operação separada, você pode fazer as alterações na interface do usuário que as utilizam, portanto, há menos risco de alguém editar o mesmo arquivo da interface do usuário.

— Ian
fonte

1

Se você não deseja mesclar a ramificação de desenvolvimento em sua ramificação com muita frequência, poderá obter um fluxo de trabalho mais parecido com o svn usando git pull --rebase. Isso irá puxar os novos commits e rebase seus commits neles. Isso significa que, quando você mesclar sua ramificação para o desenvolvimento, será uma mesclagem de avanço rápido (como se você tivesse adicionado todos os seus commits do passado ao mesmo tempo, um após o outro) e não tivesse nenhum conflito de mesclagem, porque você os resolveu durante git pull --rebase.

Porém, quanto mais confirmações você fizer antes de mesclar sua ramificação para desenvolver ou evoluir para sua ramificação, mais complicada será a próxima rebase e subverte um pouco a sensação de ramificação de recursos, pois sua ramificação só existe enquanto estiver imersa .

— todos
fonte

1

Quando você trabalha em arquivos comuns, você ou seus colegas de equipe precisam resolver todos os conflitos antes que a mesclagem termine; portanto, em primeiro lugar, não fique chateado . Você ainda está trabalhando no projeto e se orgulha do seu trabalho. Agora, para fazer uma jogada mais inteligente, você pode seguir algumas sugestões abaixo.

Divida as tarefas independentemente:
Antes de iniciar seu trabalho, planeje e divida tarefas inteiras de maneira que a tarefa atribuída a cada membro da equipe seja o mais independente e modular possível (para evitar possíveis conflitos durante o desenvolvimento). Você pode se aproximar do seu líder de scrum para atribuir algumas tarefas independentes para você como você é novato.
Mesclar confirmações frequentes granulares:
Não espere que a tarefa completa seja concluída antes da marcha final. Obviamente, qualquer tarefa maior pode ser particionada em várias subtarefas. Portanto, uma abordagem melhor é mesclar confirmações menores para subtarefas menores ao mesmo tempo, com frequência, para evitar a resolução de conflitos volumosa.
Troque sua ramificação com frequência:

Faça uma prática de rebase frequente para sua filial local com a remota. Você pode usar o comando abaixo para refazer frequentemente sua ramificação local por uma remota,
```
git pull --rebase #or
git pull --rebase origin dev #when dev is remote branch
```
Até agora, esse é o comando git mais útil para mim na minha vida de desenvolvimento.
Trabalhe em estreita colaboração com os colegas de equipe:

Se você realmente precisa trabalhar paralelamente com seu colega de equipe em uma tarefa comum, trabalhe em colaboração. Ela pode esperar algum tempo para evitar uma complexa resolução de conflitos para sua conveniência, pois você é iniciante e é especialista.
Acostume-se com as opções git:

Use o poder das ferramentas de fusão do git. Existem muitas maneiras convenientes de resolver conflitos durante a mesclagem. Às vezes, mesclar estratégias pode ajudar bastante. Esteja acostumado e destemido com os comandos git.

— Sazzad Hissain Khan
fonte

Novo desenvolvedor não consegue acompanhar as mesclagens de filiais

Divida as tarefas independentemente:

Mesclar confirmações frequentes granulares:

Troque sua ramificação com frequência:

Trabalhe em estreita colaboração com os colegas de equipe:

Acostume-se com as opções git: