Devo esperar que minha equipe tenha mais que uma proficiência básica com nosso sistema de controle de origem?

O profissionalismo ditaria naturalmente que um desenvolvedor se familiarizasse com as ferramentas padrão de sua equipe, mesmo que sejam novas e desconhecidas (ou até indesejadas).

No entanto, algumas coisas na sua postagem me dão uma pausa.

We had weeks of advance notice prior to the switch.

Semanas? Trocar o controle de fonte é um grande negócio. Deveria ter havido meses de antecedência levando a uma mudança como essa.

With a couple of exceptions, most of my team still has no idea how Git works.

Então, sua empresa mudou para um sistema de controle de origem que poucos, se é que alguém entendeu na época?

A menos que haja algum outro contexto, parece que o movimento todo foi mal pensado (o movimento, não a escolha - eu sou um grande fã).

Nós temos introduzido o Git onde eu trabalho e naturalmente tem havido resistência. Foi para um novo projeto, então agora estamos mantendo dois repositórios.

Parte do problema é que as pessoas não verão os benefícios de mudar para um SCM diferente quando o que estiver usando funciona para eles. Ajudou quando nos sentamos com nossa equipe para algumas sessões de uma hora, onde mostrávamos casos de uso dos nossos projetos e como o Git tornava as coisas mais fáceis. Por exemplo, as coisas que nos ajudaram:

• Filiais locais para incentivar a experimentação
• Git bisect para rastrear facilmente bugs
• confirmações frequentes sem interromper outras
• Alternância rápida entre filiais

Cada um deles resolveu um problema que encontramos com nosso SCM anterior e assim as pessoas puderam apreciar mais o Git.

A outra coisa é que você não pode esperar que as pessoas saiam e leiam livros sobre isso, porque muito poucas o farão. Talvez eles precisem trabalhar, ter outras responsabilidades ou vários motivos.

Então, como o 'especialista em Git', você precisa se sentar e tornar o mais fácil possível para as pessoas usá-lo. Eles querem estar escrevendo código, não mexendo com seu sistema SCM.

O CLI do Git é enigmático e problemas triviais (para você e eu) bloquearão o trabalho das pessoas. Veja o que aconteceu em nossa equipe (lembre-se, esses são desenvolvedores bastante competentes):

• O Git com SSH no Windows era um problema comum.
• As pessoas puxam, mesclam, mas não pressionam a mesclagem. Então o gráfico seria uma bagunça enorme e confusa
• O problema de desempenho no Windows "git status" demora 15 segundos
• Não foi possível descobrir como puxar um novo ramo. Eles fariam um "git checkout -b" que se ramificaria de qualquer coisa em que estivessem trabalhando
• EGit no eclipse tinha um menu esmagador. Acabou dizendo a todos para usar a linha de comando em primeiro lugar
• Baseado no item anterior, mesclando e configurando git mergetool
• Confuso sobre as diferenças entre "git add" e "git commit" e "git push".

Ainda temos alguma resistência, mas as pessoas podem definitivamente ver os benefícios. É vital ter algumas pessoas do Git para orientação e estar disposto a ajudar. Também gostaria de evitar ensinar coisas legais como reset / rebase / - emendar / etc. porque a maioria das pessoas vai usar o Git como o SVN, é melhor deixá-los descobrir, se assim o desejarem.

Proficiente vs. Git-mania

Um termo como proficiência básica pode significar coisas diferentes para pessoas diferentes. Muitas pessoas parecem ter git-mania (não que haja algo errado com isso). Muitos de nós foram gravemente prejudicados pela negligência nossa e de outras pessoas com o controle de origem.

Por que é importante (muito)

As ferramentas de controle de origem são críticas porque o uso incorreto pode retardar não apenas uma pessoa, mas uma equipe inteira. O uso indevido do Git deve ser menos problemático do que usar de forma incorreta o SVN, o CVS e outros sistemas. Historicamente, o uso ineficaz de sistemas que bloqueiam arquivos era particularmente problemático, e as empresas contratavam equipes discretas para que, quando alguém se metesse em problemas, houvesse um especialista fluente que fizesse quase nada além de controle de origem para curar a ferida no repositório. Isso explica parcialmente a paixão que você encontra por trás do git.

Como é a proficiência básica?

Alguns critérios concretos incluem:

• Sem referência à documentação:

  • É possível adicionar arquivos, confirmar alterações, enviar e receber atualizações.
  • Pode ver o status e a atividade de revisão.
  • Pode ramificar e mesclar rapidamente e sem introduzir erros.
  • Pode usar o checkout de forma adequada.
  • Crie comentários de confirmação que atendam aos critérios de comentários do grupo.
  • Altera as diferenças entre a cópia de trabalho e o arquivo.

• Com documentação:

  • Adicione usuários e credenciais para repo local.
  • inicie um repositório local.
  • Administrar repo remoto.
  • Configure arquivos ignorados, gere pares de chaves pública / privada de PKI.
  • Mova e exclua arquivos.
  • Use a divisão para encontrar a alteração que introduziu um bug específico.

Um modelo mental sólido de git e o código sendo gerenciado é crítico para evitar erros.

O que você acrescentaria para proficiência / conhecimento avançado?

O uso fluente é essencial para desenvolvedores e possivelmente outros membros de sua equipe. Ferramentas como o Git são overhead e devem ser aprendidas até um nível em que podem ser quase automáticas. Minimizar o tempo e a distração produzidos usando comandos do git que são repetidos milhares de vezes por ano tem um alto valor.

Sempre haverá alguns membros de sua equipe que serão usuários avançados e usarão quase todos os comandos com quase todas as opções. Minha recomendação é que os membros da equipe sejam encorajados a continuar aprendendo o git (e outras ferramentas) até que o ROI para aprendizado fique abaixo do valor de fazer outra coisa no projeto, com a principal limitação em manter o ritmo dos itens queimados do atual. sprint.

O GIT é uma ferramenta justa para se fazer um trabalho, e um dos maiores problemas é que muitos evangelistas do GIT esperam que todos os usuários do GIT se tornem especialistas em capas, entendendo os melhores pontos de como isso funciona. Esta é a maior fraqueza do GIT - para usá-lo, você precisa saber como funciona. Não há receitas com o GIT, espera-se que você seja um especialista do GIT ou não o use. É ótimo que você leia o Pro-GIT que sua organização precisa de um guru "goto" do GIT (ou dois) para maximizar o investimento nele, porque nem todo desenvolvedor quer se tornar um Guru GIT - e está tudo bem.

A equipe precisa saber como usar o GIT (na verdade, eles só precisam saber como usar as partes do GIT que o fluxo de trabalho requer que usem), e não como o GIT funciona. É prejudicial esperar que todos os desenvolvedores saibam todos os detalhes sobre cada ferramenta que eles usam. Se você não tem um livro de receitas que suporte o seu fluxo de trabalho, você não implantou o GIT, você o despejou nos desenvolvedores.

Eu não dou aos macacos como o GIT funciona, desde que eu saiba como fazer o git funcionar para mim.

Sim.

Não importa qual ferramenta a "empresa" tenha decidido, sua equipe de desenvolvimento deve dedicar algum tempo para aprender como usar a ferramenta corretamente. Nada prejudica mais a produtividade do que um monte de desenvolvedores com medo ou ignorância de uma ferramenta. Se eles estão usando errado ou trabalhando contra ele, problemas surgirão e como ir para o cara, você será encarregado de limpar a bagunça.

O Git é uma transição difícil para muitos, então uma sessão de treinamento obrigatório pode estar em ordem. Isso deve ajudar a resolver muitos dos problemas que as pessoas estão tendo.

Eu só usei o Git em um ambiente pessoal e não profissional, e embora eu goste do poder que ele possui e da ideia de um controle de origem mais descentralizado, ele tem grandes problemas. O Git possui uma abstração gotejante e são necessários vários comandos para fazer coisas simples (por exemplo, para fazer uma mudança: git add, git commit, e git push). Além disso, parte da documentação está faltando e / ou confusa como com a descrição do comando rebase ... "Encaminhar local da porta compromete a cabeça upstream atualizada". Eu não tenho idéia do que isso significa, e embora agora eu saiba que você pode se mover e reescrever a história com ele (outro aborrecimento ... por que você deveria ter permissão para fazer isso?) Eu nunca teria adivinhado a partir daquele comando descrição. Acho que algumas leituras por parte de sua equipe e mais alguns treinamentos fornecidos por você estão em ordem.

Treinamento e compreensão são os requisitos mínimos. Alguém no comando deveria ter certeza de que havia um plano de como sua equipe iria usá-lo. Você não adotaria uma nova linguagem de programação sem diretrizes. A formação do condutor é muito mais eficaz quando as regras estabelecidas da estrada são incorporadas.

Não; Eu acho razoável esperar o seguinte:

1. Realize tarefas diárias (comprometa, empurre, puxe, ramifique, mescle, bifurcação, etc.) sem segurar as mãos.
2. Execute tarefas não rotineiras sem instruções repetidas. (Algumas repetições são ok - eu tenho que encontrar alguém de 2 a 3 vezes antes de o nome deles realmente ficar).

Se eles não puderem fazer o número 1, a parte de treinamento do seu lançamento provavelmente foi insuficiente. Se eles não puderem fazer o número 2, primeiro certifique-se de que você está explicando as coisas com clareza suficiente antes de ficar muito chateado.