Contexto

Minha equipe de 8 engenheiros está atualmente migrando para o Git (do Subversion) para a próxima grande novidade. Temos um punhado de engenheiros 'mais experientes' que acham bastante difícil adquirir o Git. Recebi as mesmas perguntas triviais, apesar de ter fornecido manuais do usuário, atividades de treinamento e sessões de quadro branco. Tivemos dois consultores juniores que buscaram tudo em poucos dias e isso realmente esclareceu a questão. Este não é um padrão limitado ao Git, mas tornou-se visível como resultado.

Pergunta, questão

Não me sinto particularmente favorável a engenheiros que não podem / não querem aprender - especialmente funcionários com os níveis de antiguidade que temos aqui. No entanto, quero que a equipe tenha sucesso e construa um ótimo produto. Estamos usando um modelo centralizado do Git Flow e eu sinto que toda a nova terminologia os está desconcertando.

Existe algo que eu possa fazer para ajudar esses funcionários a aprender o Git?

Sourcetree é o cliente que está sendo usado por toda a equipe.

Dê a eles um brinquedo.

Git é difícil. Especialmente se você estiver controlando a fonte em um paradigma diferente. Eu quebrei a compilação na primeira vez que tentei trabalhar com o git. Isso me deixou tão paranóico que não quis fazer o check-in até que tudo estivesse pronto. Eu estava escondendo versões em pastas. Então finalmente descobri o que precisava para superar isso:

Eu precisava de um lugar seguro para brincar.

Uma vez que eu tive isso, estava causando problemas intencionalmente para que eu pudesse aprender como consertá-los - tudo no meu lugar seguro. Eu desenvolvi um padrão que eu poderia usar mesmo que interrompido e ainda voltasse a um bom estado. Em pouco tempo, as pessoas estavam me procurando para obter ajuda com o git. Tudo porque eu dediquei tempo para brincar com um brinquedo.

Se você apenas jogá-los no fundo do poço, terá sorte se eles conseguirem flutuar.

O desenvolvedor médio não precisa de muitas guloseimas do git. É um sistema de controle de fonte distribuído, mas a maioria das equipes o usa com um repositório canônico central para empurrar e retirar.

Os comandos principais que sua equipe precisará são:

• extrair e mesclar alterações do controle remoto e lidar com conflitos resultantes (potencialmente reencaminhamento)
• confirmar e enviar por push para remoto (ou enviar para repo / branch de armazenamento temporário para obter as alterações inseridas no main após revisão)
• Para suporte: corrija a bagunça depois de fazer algo errado.

aqueles que os usuários mais avançados precisarão são

• lidar com confirmações locais
• gerenciar filiais

Para pessoas não familiarizadas com o git e para quem não quer aprender, configure alguns comandos rápidos e alternativos para executá-los e verifique se tudo está correto (adicione novos arquivos, remova arquivos excluídos do repositório, etc.)

Verifique se eles estão bem documentados e à prova de erros.

Isso está na veia dos quadrinhos do xkcd , apenas memorize os comandos e espere que as coisas não fiquem muito bagunçadas quando perguntam a um profissional.

Faça com que eles usem uma interface do usuário do Git.

Se eles têm experiência com o TortoiseSVN, o TortoiseGit (somente Windows) funciona quase exatamente da mesma forma. Caso contrário, o SourceTree (Windows + Mac) é maravilhoso - temos vários QA de não desenvolvedores que foram capazes de dominar facilmente tarefas complexas no Git, graças ao SourceTree.

Esta resposta tenta abordar como interessar programadores seniores git, não sobre como aprender gitda maneira mais rápida - para isso, o excelente livro git é ótimo ou qualquer quantidade de tutoriais (=> Google). Bons links para essa resposta são: Git é uma estrutura de dados puramente funcional ou, especialmente, o pequeno Como o git armazena seus dados .

Receio ter uma visão bastante sombria disso. Eu estive exatamente no seu lugar - sou um gitnerd e queria transformar uma equipe longe de svn, vamos encarar, resultados minúsculos. No meu caso, isso me levou a mudar ativamente minha própria percepção e a aceitar essas pessoas, simplesmente não podem ser "forçadas à felicidade". As pessoas não são computadores, é incrivelmente difícil programá-las. Ainda estou feliz por ter tentado, isso me mostrou de maneira bastante suave o que faço e o que não quero fazer na minha vida profissional.

Há pessoas que começam a se motivar quando há coisas novas envolvidas e outras que são desmotivadas. Isso não tem nada a ver com isso git, mas, gitespecificamente, você sempre tem o efeito de "por que deveríamos usá-lo se tudo svnestá bem?", O que é uma enorme barreira psicológica.

Além disso, realmente grokking gitrequer um interesse intenso em estruturas de dados abstratas. Pode parecer inacreditável, mas, na minha experiência, existem programadores que não têm interesse algum e que estão entediados e sobrecarregados por elementos mais complexos que as simples matrizes. Você pode argumentar de um lado para outro se aqueles deveriam fazer o trabalho que estão fazendo, mas é o que é.

Se as pessoas não estiverem interessadas, não entenderão. Claro e simples. Aposto que o desinteresse é a principal razão das notas ruins na escola, sem perder a inteligência.

Dito isto, aqui seria um currículo como eu o aplicaria, com base na acumulação de conhecimento de baixo para cima. Não funcionou para mim, mas você pode ter como inspiração fazer o seu próprio.

GUI

Embora a abordagem a seguir não precise necessariamente de suporte da GUI para as ações ( git addem um repositório hello world ...), ajuda tremendamente ter uma GUI para visualizar o repositório, desde o início. Se você não pode decidir sobre qual usar, use gitkcomo último recurso. Se vocês usam algum tipo de editor visual, encontre o gitcomponente da GUI.

A estrutura de dados (estática) é fundamental

Comece explicando os tipos de dados internos (existem apenas três mais um deles: blobs, árvores, confirmações, tags anotadas, a última das quais não interessa absolutamente nada neste estágio) e sua estrutura. Você pode fazer isso facilmente no quadro branco / com um lápis; a árvore é fácil de desenhar, pois nunca pode ser alterada; você pode literalmente adicionar coisas o tempo todo. Você pode fazer uma sessão de reprodução em um repositório local criado recentemente e usar git cat-fileos objetos reais para mostrar que eles são de fato tão triviais quanto os anunciados.

Se você pode ajudá-los a entender que

• ... existem literalmente apenas 3 tipos de objetos na história, todos eles muito simples, quase triviais e
• ... a maioria dos gitsubcomandos apenas "massageia" esses objetos de uma maneira ou de outra, com operações quase triviais (basicamente, existe apenas uma: adicione um novo commit em algum lugar) e ...
• ... tudo pode ser facilmente visto bem na sua frente lse com git cat-file...

então eles terão a tradução mental do que realmente está no repositório. Nesse ponto, os seniours podem se lembrar de que os elementos internos svnsão mágicos arcanos (já tiveram problemas com bloqueios dentro do repositório svn ou com ramificações "reintegrando" e tal?), E isso pode motivá-los um pouco.

Um problema, especificamente com as pessoas acostumadas svn, é se acostumar com a idéia de que um commit (o objeto, não a ação) sempre é toda a árvore de diretórios. Em svn, as pessoas são usadas para confirmar arquivos individuais. É uma abordagem radicalmente diferente. Ah, e o fato de o mesmo termo "confirmação" ser usado tanto para um objeto estático quanto para uma ação também não está ajudando.

O outro problema para os svncaras é que svnusa uma história linear, não uma árvore. Isso é, novamente, totalmente diferente. Então este é o momento para apontar dessas diferenças muito .

Ações explicadas em termos da estrutura

Quando eles entenderem de que partes um gitrepositório é composto, é hora de mostrar exatamente o que os gitsubcomandos individuais fazem em termos deles.

Estou falando sobre add, commitem conjunto com o diretório de trabalho local e o estágio (certifique-se de que eles entendam que o diretório de trabalho não é o mesmo que a área de preparação que não é o mesmo que o repositório).

Quando eles entenderem que esses comandos simplesmente crescem a árvore (que, novamente, neste estágio, consiste em 3 dos tipos - blobs, árvores, confirmações e não apenas confirmações), você pode fazer o primeiro git pushe git pull(no modo de avanço rápido! ) para mostrar a eles que, gitliteralmente, apenas está empurrando seus objetos, que os hashes são realmente apenas hashes de conteúdo, que você pode facilmente copiar essas coisas com um comando de cópia do sistema de arquivos e assim por diante.

Obviamente, fique longe de qualquer opção não essencial desses comandos, estamos falando git add hello.txtaqui.

Ramos

Observe que a ramificação é especialmente difícil para as svnpessoas, pois é totalmente diferente. O svnmodelo é muito mais fácil de visualizar, pois basicamente não há nada para visualizar - ele está à vista. O gitmodelo nem tanto. Certifique-se de que eles estejam cientes desde o início de que ramificações e tags são apenas "notas adesivas" apontando para algum lugar e, na verdade, não "existem" em termos do histórico estático e imutável.

Em seguida, faça exemplo após exemplo fácil para mostrar o que você realmente pode fazer com eles. Como você parece estar acostumado git, não deve ter dificuldade em encontrar motivação lá. Certifique-se de que eles sempre visualizem isso em termos de como a árvore cresce.

Se eles têm isso, você pode explicar como git pullé realmente git fetch && git merge; como todos os repositórios realmente contêm exatamente os mesmos objetos ( git fetché quase o mesmo que copiar coisas scpdentro do diretório de objetos git) e assim por diante.

Provavelmente, se a essa altura você não tiver conseguido despertar o interesse deles, poderá desistir, mas se eles conseguirem chegar tão longe, terão todas as ferramentas mentais à sua disposição e deve haver pouco medo envolvido mais. O restante (fluxo de trabalho do git ...) deve estar em declive então.

Últimas palavras

Isso parece muito esforço, e realmente é. Não venda isso como "precisamos disso para este projeto", mas "isso ajuda você a se desenvolver pessoalmente e ajudará em todas as suas interações adicionais". Você precisa de muito tempo para isso, e tempo é dinheiro. Se você não tiver aceitação da gerência sobre isso, pode não valer a pena; talvez você deva conversar com seu chefe.

Se você decidir deixar de ensinar aos desenvolvedores que aparentemente não são capazes de entender, mas absolutamente deve usá-lo gitno futuro, considere substituir toda a interação por gitcomandos por scripts elaborados ou alguma GUI que gitretire todos os detalhes. Coloque todo o controle de erros etc. nos scripts e tente fazê-lo funcionar.

Gostaria de encaminhá-lo para esta entrada do blog de Joel Spolsky .

O motivo pelo qual você está percebendo esses desenvolvedores juniores rapidamente é muito provável, porque eles não têm uma noção predeterminada sobre como o controle de versão em geral funciona, ou pelo menos não um modelo mental profundamente arraigado. Como tal, eles entram com uma lousa limpa. Seus programadores mais experientes provavelmente estão tentando aplicar os conceitos que já conhecem e estão falhando como resultado disso.

Além disso, por mais que eu não goste de dizer; quem realmente lê os manuais do usuário? Normalmente, eles são muito ruins em explicar o uso básico. Basta olhar para a página git commit do manual e considerar quantos novos termos e frases estão sendo introduzidos para alguém que não está em dia com o conceito. Sem uma boa introdução, eu provavelmente teria desistido de usar o Git ali mesmo.

Meu conselho pessoal seria começar a explicar os comandos:

• git add <arquivos>
• git commit
• puxão
• empurrão
• status git

Os conflitos de mesclagem lógica devem ser explicados a seguir, porque esse será definitivamente o seu primeiro problema quando as pessoas aprenderem como confirmar o código.

Normalmente, surgem situações em que as pessoas precisam investir mais tempo aprendendo coisas (reverts, tags, conflitos de mesclagem, ramificações, rebasing, ganchos), mas tentar explicar tudo isso antes que seja necessário não ajudará as pessoas que estão tendo problemas para se envolver. o fluxo.

Apenas para concluir: de acordo com minha experiência pessoal, algumas pessoas simplesmente não gastam muito tempo explorando novas técnicas, conceitos ou ferramentas e geralmente tendem a entender as coisas que as apresentam em um ritmo mais lento. Isso não significa que eles são maus programadores ou pessoas más, mas geralmente têm um conjunto de habilidades mais restrito.

O Git é um repensar importante se você aprendeu como fazer o controle de origem no SVN. Muitos dos hábitos que você desenvolveu lá (o que pode ter sido uma boa prática para o SVN) irão desencaminhar você ao usar o git. Isso ocorre principalmente porque o modelo de ramificação do git é tão fundamentalmente diferente. Ele não utiliza pastas para ramificações e também é possível torná-lo não linear porque foi projetado para suportar melhor os casos de uso distribuídos. Leva algum tempo para desaprender os hábitos SVN e entender como você deve usar o git.

Comece simples

Você diz que escolheu o Gitflow como padrão para gerenciamento de filiais. Isso me parece o seu maior erro.

Para citar o Gitflow considerado prejudicial :

Todos esses ramos usados ​​forçam o GitFlow a ter um conjunto elaborado de regras complicadas que descrevem como eles interagem. Essas regras, juntamente com o histórico intangível, tornam o uso diário do GitFlow muito difícil para os desenvolvedores.

Você consegue adivinhar o que acontece sempre que você configura uma rede complexa de regras como essa? É isso mesmo - as pessoas cometem erros e os quebram por acidente. No caso do GitFlow, isso acontece o tempo todo. Aqui está uma lista curta, de maneira alguma exaustiva, dos erros mais comuns que observei. Eles são repetidos constantemente, às vezes todos os dias, muitas vezes repetidamente pelos mesmos desenvolvedores - que são, na maioria dos casos, muito competentes em outras áreas de software.

Seus desenvolvedores provavelmente estão sobrecarregados com a complexidade desse padrão. Pessoalmente, não acho que tenha nenhum benefício, e o artigo acima apresenta o mesmo argumento. Mas essa é uma discussão separada. Objetivamente, porém, é um padrão bastante pesado com muito gerenciamento manual e requer muito esforço cognitivo.

Você precisa começar mais simples. Não se preocupe com um padrão de ramificação agora. Concentre- se em acostuma-los a usar o git primeiro. Você realmente só precisa de algumas operações para começar:

• clone
• puxar
• ramo
• fundir
• cometer, entregar
• empurrar
• conhecimento sobre como .gitignorefunciona
• talvez marcar

Sim, seu histórico pode parecer um pouco confuso no começo. Esta certo. Não se preocupe com isso agora. Apenas pegue-os usando o git .

Aumentar gradualmente o conhecimento

A partir daqui, você pode gradualmente educá-los sobre o uso um pouco mais avançado.

• Ensine a eles o comando épico de esconderijo
• Ensine-os a usar o reset quando quiserem jogar fora o commit local que acabaram de fazer
• Ensine-os a alterar
• Ensine-os a se refazer para evitar confirmações desnecessárias de mesclagem
• Ensine-os a refazer interativamente para organizar seus commits antes que eles enviem
• Ensine a eles como podem fazer checkout de qualquer hash, tag ou ramificação

Especialmente, aproveite as oportunidades para mostrar a eles maneiras mais limpas de inserir o código no repositório, mas também ensine essas coisas nas atividades de treinamento e no que você tem. Ter um ou dois gurus que as pessoas possam abordar quando não tiverem certeza do que fazer também ajudará muito. Se você tem algo como o Slack, crie um canal dedicado e incentive as pessoas a fazer e responder perguntas lá.

Em seguida, escolha um padrão de ramificação

Depois de ter a maioria da companhia competente em usar git em tudo, então você pode olhar para os padrões de ramificação. Escolher uma antecipadamente é uma péssima ideia por vários motivos:

• Eles não têm conhecimento suficiente da ferramenta para informar se o padrão funciona bem nos casos de uso da empresa
• Eles não serão capazes de oferecer padrões alternativos
• Eles precisam aprender a ferramenta e o padrão ao mesmo tempo
• Alguns assumem que o padrão escolhido é a única maneira de usar o git
• Eles não serão capazes de identificar casos extremos raros em que o padrão está fazendo mais mal do que bem

Você não deveria estar entregando um fluxo de trabalho Git da montanha. Sua equipe precisa ter informações e poder fornecer feedback sobre se está indo bem ou não. Eles não podem fazer isso se ainda não entenderem os fundamentos. Você não precisa que todo desenvolvedor tenha um conhecimento profundo como esse, mas definitivamente precisa de vários que realmente o entendam. E você precisa que a grande maioria seja pelo menos competente em git, para que eles saibam o suficiente para permanecerem nos trilhos.

Aqui estão algumas alternativas ao Gitflow que sua equipe pode considerar:

• OneFlow
• Fluxo de trabalho da ramificação de recursos
• Fluxo de trabalho centralizado

Olhe para eles e o Gitflow, avalie-os contra seus casos de uso e escolha um que se encaixe.

Achei o stackoverflow muito útil enquanto eu pegava a terminologia do Git. Perguntas como essas foram realmente úteis para mim (principalmente por causa de sua concisão) e eu as mantive abertas em abas durante as primeiras duas semanas em que a usei. Talvez imprima algumas respostas em negrito? Especialmente o diagrama do primeiro.

Quais são as diferenças entre "git commit" e "git push"?

Qual é a diferença entre 'git pull' e 'git fetch'?

Também achei uma representação visual do porta-malas incrivelmente útil, mas você já está cobrindo essa com o SourceTree.

_{Além disso, esse trecho provavelmente pertence a um comentário, mas me falta o representante: sou um dos consultores juniores mencionados na pergunta. Antes de começar, eu tinha alguma idéia do que era um sistema de controle de origem e cutuquei o SVN literalmente duas vezes, Gusdor me dá mais crédito do que eu mereço. Toda a equipe teve treinamento especializado em Git de alta qualidade, brinquedos e tempo para brincar. O problema não está nas instruções de Gusdor. Espero que exista uma boa solução alternativa para que eu possa marcar isso com mais detalhes e aprender mais.}

Compre um livro para eles

Honestamente, eu caí diretamente no campo que você descreve. Eu vim de um background do SourceSafe e ClearCase. No começo, Git era completamente inescrutável para mim, apesar de meu chefe ter passado por isso várias vezes.

O que me ajudou foi um livro que descreveu claramente o que estava acontecendo, mas mais importante, como o Git era fundamentalmente diferente de qualquer sistema de controle de origem que eu já havia usado antes. Agora, eu prefiro o Git do que qualquer outra escolha.

Infelizmente, não consigo me lembrar de qual livro eu havia lido na época, mas certifique-se de que o livro que você recebe (ou aponte para eles) se concentre em como é diferente e como exige uma mentalidade diferente.

O melhor palpite para uma recomendação de livro é:

Pro Git de Scott Chacon (link da Amazon para facilitar ... compre de quem quiser: https://www.amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6 )

Nota : Você não comprar um livro de referência para Git. Isso não vai ajudar em nada.

Pela minha experiência, algumas pessoas podem se sentir confortáveis ​​usando o git sem entendê-lo. Eles encontram um tutorial básico, captam comandos básicos e estão prontos. Provavelmente é aí que os consultores juniores se encaixam. Não acredito que você possa aprender git em poucos dias!

Outras pessoas, não conseguem, precisam entender o que o git está fazendo, e isso leva mais tempo. Eu estava nessa categoria; Achei realmente útil brincar com o conteúdo do .gitdiretório, foi quando as coisas começaram a clicar para mim. Também ajudaram as sessões individuais com o nosso líder técnico.

Você pode fazer tutoriais individuais, porque as pessoas aprendem de maneira diferente e podem ficar realmente confusas sobre partes diferentes. Em uma sessão individual, é mais fácil ver e resolver. Se eles realmente se incomodam com o fato de não entenderem como o git monitora as ramificações, mostre o conteúdo do .gitdiretório e assim por diante ...

Estou brincando de apresentar gitonde estou (do TFS), para que sua pergunta seja oportuna para mim, especialmente porque também tive alguns empurrões ao abordar o assunto.

No Peopleware , as teses subjacentes de todo o livro são:

Os principais problemas do nosso trabalho não são tanto tecnológica como sociológica na natureza .

Trago isso à tona porque o nosso não é um problema técnico. git, embora um pouco obtuso, provavelmente não está além da capacidade dos seus ou dos meus desenvolvedores seniores, a menos que sejam extremamente estúpidos *.

Vejamos do ponto de vista dos desenvolvedores, como pessoas, não como máquinas técnicas:

Você está pedindo que eles parem de usar um sistema de controle de origem que eles possuam (provavelmente) domínio sobre um sistema que eles não possuem. É um pouco como pedir a um gitespecialista para parar de usar gite seguir em frente, svnnão é? Eu acho que o especialista em git ficaria irritado e provavelmente não se esforçaria muito svnporque gitfunciona bem e há partes dele que ela realmente gosta que são difíceis de fazer svn.

Provavelmente é por isso que os juniores o adotaram melhor - talvez eles não tenham entendido svne gité sua chance de se livrar deles.

Os idosos, porém, são cautelosos com o custo de oportunidade - se eles aprendem git, não são:

• Aprender Reagir / Angular / Swift / Blockchain / Kotlin (outra coisa que eles acham que deveriam estar aprendendo).
• Fazendo DIY / talha / vela / poesia / glockenspiel / o que mais eles realmente querem fazer.
• Passar tempo com seus filhos / parentes / amigos / outros significativos.

• Entregando essa "grande novidade" - há um prazo, orçamento etc. Eles provavelmente estão preocupados com isso.

  "Eu preciso fazer todas as opções acima, por que eu tenho que usar git quando já temos controle de origem?"

Que motivos você deu a eles para mudar de uma coisa em que eles são bons, para outra que é francamente estranha quando você é iniciante nela e exige uma repensação completa de como você desenvolve? Você explicou os benefícios dos gitrecursos?

Pull-solicitações? Checkins de grão fino? Fonte distribuída? Garfos?

Eles trouxeram para essas razões? Essas são mudanças estruturais maciças se você estiver em uma mentalidade centralizada de controle de fonte - não apenas mudanças técnicas, mas também culturais, e sabemos o quão difícil é mudar uma cultura.

Então, basicamente, pense no que você está pedindo que seus desenvolvedores façam e verifique se é pelos motivos certos. Se você só quer fazer isso porque svné estúpido e velho e ninguém mais usa, então é bom, mas é mais difícil vender para outras pessoas que não pensam como você e só querem continuar com o dia delas. Você precisa declarar os benefícios em termos que façam sentido para sua equipe e para o projeto. Se você conseguir que eles concordem que gitvale a pena, não precisará se preocupar com o aprendizado da tecnologia, apenas concordando com o fluxo de trabalho que você configurou.

Boa sorte.

Eu acho que isso é menos uma questão de engenharia de software e mais uma questão de psicologia. Eu gostaria de me referir Algorithms to Live By: The Computer Science of Humand Decisions. Nele, o autor aborda o tópico do tradeoff de exploração / exploração. Os seres humanos geralmente passam por uma fase de exploração e depois por uma fase de exploração (uso) do que eles exploraram. Há alguma teoria matemática sólida por trás desse motivo, a fim de obter o melhor uso possível de algo em um determinado intervalo.

Isso também se estende à idade e à experiência. Os seres humanos veem suas próprias vidas como um intervalo e, após uma certa fase de exploração, é ideal começar a usar seu conhecimento. Eles citaram um estudo no qual foi perguntado aos participantes mais velhos se queriam conhecer alguém famoso de quem gostassem ou melhor, um membro da família. Eles geralmente escolhem o membro da família, enquanto os mais jovens escolhem a pessoa famosa com mais probabilidade. No entanto, quando solicitados a imaginar como eles decidiriam se eram 20 anos mais jovens, os idosos também costumavam escolher a pessoa famosa. O que sugere que as pessoas param de construir suas redes sociais quando acreditam que têm menos com a exploração do que com o que já sabem.

Seus engenheiros seniores são provavelmente mais velhos, provavelmente passaram por alguns sistemas de controle de versão. SVNé provavelmente o melhor que eles usaram até agora (pelo menos, olhando para os sistemas de versão mais antigos que eu usei, o SVN venceu todos eles).

Sua estratégia ideal é explorar o SVN, porque eles exploraram e descobriram que esse é o melhor que eles exploram agora.

Isso é psicologia humana básica e centenas de milhares de anos de otimização evolutiva contra a qual você está lutando.

Você precisará mostrar a eles: a) quanto tempo uma carreira eles têm pela frente, para prepará-los para pensar a partir de uma perspectiva diferente no intervalo em que se veem eb) perguntar-lhes o que eles acham ótimo e o que eles ' está faltando SVN. Você pode apresentar centenas de benefícios git, mas eles já terão uma idéia clara do porquê SVNé o melhor, afinal eles experimentaram provavelmente 5 sistemas de controle de versão antes. Você precisa encontrar a fenda na armadura desse argumento e, em seguida, ver se gitpode resolver esses problemas, eles terão se convencido.

Não dê a eles uma ferramenta ou uma GUI para usar o Git. Só vai confundir as coisas. O Git foi concebido para rodar em uma linha de comando, de modo que provavelmente deve ser o local em que é aprendido. Qualquer GUI pode vir com seus próprios termos e peculiaridades, mantendo o que é simples.

O próximo seria examinar alguns dos problemas que o Git faz melhor que o SVN. Para que sua equipe aprenda, você precisa motivá-los a ver por que o git é melhor.

• Capacidade de confirmar enquanto não estiver conectado à rede
• Capacidade de criar e brincar com seus próprios ramos
• Patches que podem ser enviados entre si e ainda mesclar a faixa
• colheita de cereja sem dor.
• rebasing changes
• encontrando bugs com emenda do git

Tenho certeza de que o SVN seguiu em frente nos últimos anos, mas esses costumavam ser coisas que causariam um mundo de dor. Se os desenvolvedores perceberem que essa nova ferramenta não é apenas algo sofisticado, mas possui vantagens sólidas para o trabalho deles, é mais provável que eles fiquem por trás disso.

É uma coisa nova de aprender e há semelhanças suficientes que podem ficar confusas, mas realmente em 2017 o DCVS é ​​praticamente uma habilidade essencial para todos os desenvolvedores.

Diga a eles para não se preocuparem

No Git, uma vez que o trabalho é realizado, é quase impossível perder. O único trabalho que você pode facilmente perder é o trabalho que ainda não foi comprometido.

Mostre a eles como git reflogfunciona. Eles não precisam saber como usá-lo; eles só precisam saber que está lá, para que possam obter ajuda para recuperar o trabalho se algo der errado.

Em seguida, imprima neles esta regra simples: em caso de dúvida, comprometa-se. Eles sempre podem voltar atrás no commit (mesmo no controle remoto!).

Não use uma GUI

Uma GUI dará a eles um início mais rápido, mas eles nunca entenderão o Git. Além disso, eu descobri que ele é não "quase impossível perder" trabalho empenhado ao usar um Git GUI. Vi GUIs fazerem coisas horríveis, como apresentar uma lista de verificação ao mesclar e, em seguida, se o usuário desmarcar um item, limpe esse arquivo do histórico sem aviso e sem registro. Uma GUI é muito pior do que simplesmente aprender o Git da linha de comando.

O código do programa de par confirma

O aprendizado git add -Aseguido por git commitnão deve ser muito difícil, mas principalmente ao mesclar (ou refazer o processo) ao controle remoto, eles precisarão de alguma ajuda. Deixe claro que qualquer pessoa pode pedir ajuda a qualquer momento. Aguarde enquanto digitam os comandos e fazem anotações. Com o tempo, eles aumentarão gradualmente o número de situações que podem lidar sem ajuda.

Git já está seguro

Alguém acima falou sobre ter "um lugar seguro para brincar". Mas Git é aquele lugar seguro. Existem apenas dois casos normais do dia a dia em que é fácil perder o trabalho:

• Código não confirmado
• Usando uma GUI

Certifique-se de que eles se comprometam cedo e com frequência, e que eles não iniciem o caminho errado com uma GUI, e logo verão que podem confiar no Git com seu código ainda mais do que outros sistemas de controle de origem no passado.

Eu recomendaria uma olhada no Gitless . É um invólucro sobre o git que simplifica muito o fluxo de trabalho básico (não é necessário se preocupar com uma área de preparação, as filiais mantêm suas próprias cópias de trabalho dos arquivos, os usos mais simples git rebasesão tratados gl fuseetc.) enquanto mantém um repositório git subjacente para colaboração ou se você precisar fazer algo incomum. Além disso, as mensagens são um pouco mais amigáveis ​​para iniciantes. E os comandos são próximos o suficiente para o git funcionar como um trampolim, se eles precisarem usar um sistema sem o git, por qualquer motivo.

Tentei documentar o básico de como usar a linha de comando do git. Ainda era confuso - tanto para mim (que tinha experiência em usar o Perforce e o Source Safe) quanto para os programadores que preferiam o antigo paradigma "apenas feche as pastas relevantes". Era preocupante ter uma ferramenta opaca para modificar o conteúdo do meu diretório de trabalho e frequentemente ter que discutir com a ferramenta para incorporar alterações específicas no meu diretório de trabalho.

Em vez disso, eu uso dois tipos de indireção.

• Eu uso o GitKraken para fornecer um histórico visual dos meus ramos e uma GUI que oculta as instruções da linha de comando. O GitKraken lida com as interações entre o repositório remoto "origem" e o que o git pensa ser o meu diretório de trabalho local.

• Também mantenho um diretório de trabalho local "real" que é separado do que o git pensa ser o meu diretório de trabalho local. Sincronizo manualmente esses dois diretórios de trabalho, o que me permite ficar muito mais confortável com o que eu pretendia ter quaisquer alterações no meu diretório de trabalho.

Existe algo que eu possa fazer para ajudar esses funcionários a aprender o Git?

Tem certeza de que o problema é Git e não outra coisa? O que recebo do comentário é que a gerência decidiu mudar alguma coisa sem receber a contribuição dos colaboradores seniores e está encarregando alguém mais novo deles para conduzir a mudança. Parece um bom ponto de partida para o fracasso, qualquer que seja a mudança. A complexidade do Git não é um problema, o problema é que uma mudança que eles não sentem necessidade é imposta a eles.

Portanto, não se concentre em como ensiná-los o Git, desde que eles não vejam uma vantagem para a chave que estarão arrastando os pés. Mostre a eles como o Git é uma solução para os problemas que eles têm agora. Não é como o Git pode fornecer coisas que ainda não são necessárias, nem como o Git fornece uma solução para os problemas de outras pessoas, como o Git resolve os problemas que estão enfrentando agora. Então ensiná-los o Git não será um problema.

Geralmente, o Git é usado em uma empresa para resolver problemas com filiais. Sim, é melhor nos ramos do que no Subversion, mas não faz mágica.

É muito provável que os desenvolvedores experientes tenham trabalhado em muitas empresas.

• Filiais criadas porque a gerência não está disposta a decidir entre demandas conflitantes
• Usaram uma filial para cada cliente, em vez de switches de configuração.
• Foi necessário um ramo de correção de bug para cada cliente, pois o gerenciamento não estava disposto a fazer com que todos os clientes atualizassem para a mesma versão do software
• Etc.

Portanto, assim que alguns me dizem que uma ferramenta é boa para ramificar, minha mente me diz.

A gerência não quer decidir de que maneira a empresa está indo e prefere que eu desperdice a vida tendo que mesclar meu trabalho em 101 ramos diferentes, além de ter que testar 101 versões diferentes do software.

Além disso, o conceito de que duas pessoas estariam trabalhando no mesmo arquivo ao mesmo tempo é "bom", simplesmente não é aceitável para alguém que experimentou um projeto bem executado, portanto, promover o Git como uma ferramenta para fazer isso é improvável que seja experiente desenvolvedores gostando de você.

Toda vez que olho para a história no Git, é muito difícil ver por que o código foi alterado, pois 50% ou mais da história é mesclada que logicamente nunca deveria ter sido pública e elas se tornam sem sentido assim que o código deixa os desenvolvedores máquina.

Mas eu adoraria trabalhar em algum lugar onde:

• Nenhum código entra no sistema central até que tenha sido compilado e testado em unidade em um servidor confiável.
• Existe uma maneira fácil de rastrear revisões de código
• Onde sempre que eu faço um "get", o código sempre compila e funciona
• Onde eu posso empurrar minhas mudanças sem ter que correr com outra pessoa ou ter que me afastar no escritório para ver se eu quebrei a construção.

Resolva os problemas reais e, se o Git fizer parte das soluções que seus desenvolvedores experientes comprarão, mas não espere que eles gostem do Git apenas porque é um brinquedo legal que pode fazer "combinações mágicas".

Portanto, em qualquer lugar que permita que um desenvolvedor passe do Git local para o Git central esteja fazendo errado, um processo automatizado controlado deve receber as alterações dos desenvolvedores e depois testá-las, etc, e verificar se as fusões estão ok atualizando o Git central filiais etc. que não são de interesse a longo prazo.

Eu espero que o Kiln ( http://www.fogcreek.com/fogbugz/devhub ) ou mesmo o GitHub usando um fluxo de trabalho de "solicitação de recebimento" mantenha os desenvolvedores experientes felizes, por exemplo, não comece com o baixo nível necessário, comece com o aprimorado processo.