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

Minha empresa mudou do Subversion para o Git cerca de três meses atrás. Tivemos semanas de aviso prévio antes da troca. Como eu nunca havia usado o Git antes (ou qualquer outro DVCS), li o Pro Git e passei um pouco de tempo revirando meus próprios repositórios e brincando, de modo que, quando mudássemos, eu pudesse continuar trabalhando com um mínimo de dor. Agora eu sou o 'cara Git' por padrão.

Com algumas exceções, a maioria da minha equipe ainda não tem idéia de como o Git funciona. Por exemplo, eles ainda consideram as ramificações como cópias completas do código-fonte e chegam a clonar o repositório em várias pastas (uma por ramificação). Eles geralmente olham para o Git como uma caixa preta assustadora.

Dada a natureza fundamental do controle de fonte em nosso trabalho diário (sem mencionar a quantidade ridícula de poder que o Git nos oferece), sou da opinião de que qualquer desenvolvedor que não atinja um certo nível de proficiência é um passivo .

Devo esperar que minha equipe tenha pelo menos alguma compreensão de como o Git funciona internamente e como usá-lo além das operações mais básicas de puxar / mesclar / empurrar? Ou estou apenas fazendo algo do nada?

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

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

Tivemos semanas de aviso prévio antes da troca.

Semanas? Trocar o controle da fonte é um grande negócio. Deveria haver meses de aviso prévio levando a uma mudança como essa.

Com algumas exceções, a maioria da minha equipe ainda não tem idéia de como o Git funciona.

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

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

Introduzimos o Git onde trabalho e naturalmente houve resistência. Era 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 estiverem usando funcionar para eles. Ajudou quando sentamos com nossa equipe por algumas sessões de uma hora, onde apenas mostramos casos de uso de nossos projetos e como o Git tornou mais fácil. Por exemplo, as coisas que nos ajudaram:

• Agências locais para incentivar a experimentação
• Git bisect para rastrear bugs com facilidade
• confirmações frequentes sem interromper outras pessoas
• Troca rápida entre filiais

etc. Cada um deles resolveu um problema que havíamos encontrado com o nosso SCM anterior e para que as pessoas pudessem apreciar mais o Git.

A outra coisa é que você não pode esperar que as pessoas saiam e leiam livros sobre isso, porque poucos o farão. Talvez eles precisem concluir o trabalho, ter outras responsabilidades ou várias razões.

Portanto, como especialista em Git, você precisa se sentar e facilitar o máximo possível para que as pessoas o usem. Eles querem escrever código, não mexer com o sistema SCM.

A CLI do Git é um problema enigmático e trivial (para você e para mim) impedirá que as pessoas trabalhem. Aqui está o que aconteceu em nossa equipe (lembre-se, esses são desenvolvedores bastante competentes):

• Git com SSH no Windows era um problema comum.
• As pessoas puxariam, fundiriam, mas não empurrariam a fusão. Portanto, o gráfico seria uma enorme bagunça confusa
• Problema de desempenho no Windows fez com que o "status git" demorasse 15 segundos
• Não foi possível descobrir como puxar um novo ramo. Eles faziam um "git checkout -b" que se ramifica do que quer que eles estejam trabalhando
• EGit em eclipse tinha um menu avassalador. Acabou dizendo para todos usarem a linha de comando primeiro
• Com base 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. Além disso, eu evitaria ensinar coisas legais como reset / rebase / - modify / etc. Como a maioria das pessoas usa o Git como SVN, é melhor deixá-las 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 nisso). Muitos de nós foram gravemente queimados pela negligência de nós mesmos e de outras pessoas com o controle da fonte.

Por que é importante (tanto)

As ferramentas de controle de origem são críticas porque o uso indevido pode retardar não apenas uma pessoa, mas uma equipe inteira. O mau uso do Git deve ser menos problemático do que o mau uso do SVN, CVS e outros sistemas. Historicamente, o uso inepto de sistemas que bloqueavam arquivos era particularmente problemático, e as empresas contratavam equipes de criação discretas para que, quando alguém se metesse em problemas, houvesse um especialista fluente que não fizesse quase nada além do controle de origem que poderia curar a ferida no repositório. Isso explica parcialmente parte da 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:

  • Pode adicionar arquivos, confirmar alterações, enviar e receber atualizações.
  • Pode visualizar o status e a atividade de revisão.
  • Pode ramificar e mesclar rapidamente e sem introduzir erros.
  • Pode usar o checkout adequadamente.
  • Crie comentários de confirmação que atendam aos critérios do grupo para comentários.
  • Alterações diferentes entre cópia de trabalho e arquivo morto.

• Com documentação:

  • Adicione usuários e credenciais para o repositório local.
  • iniciar um repositório local.
  • Administre o repositório remoto.
  • Configure arquivos ignorados, gere pares de chaves públicas / privadas de PKI.
  • Mova e exclua arquivos.
  • Use o bisect para encontrar a alteração que introduziu um bug específico.

Um modelo mental sólido do git e o código que está sendo gerenciado são críticos para evitar erros.

O que você adicionaria para proficiência / especialização avançada?

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

Sempre haverá alguns membros da 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 incentivados a continuar aprendendo o git (e outras ferramentas) até que o ROI do aprendizado caia abaixo do valor de fazer outra coisa no projeto, com a principal limitação em acompanhar os itens de burnout atribuídos do atual arrancada.

O GIT é uma ferramenta justa para fazer um trabalho, e um dos seus maiores problemas é que muitos evangelistas do GIT esperam que todos os usuários do GIT fiquem sob o capô especialistas entendendo os melhores pontos de como ele funciona. Essa é a maior fraqueza do GIT - para usá-lo, você precisa saber como ele funciona. Não há receitas com o GIT, você deve ser um especialista em GIT ou não usá-lo. É ótimo que você leia o Pro-GIT, pois sua organização precisa de um guru do GIT (ou dois) para maximizar o investimento, porque nem todo desenvolvedor deseja se tornar um GIT Guru - e isso é bom.

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 exige que elas usem), não como o GIT funciona. É prejudicial esperar que todos os desenvolvedores conheçam todos os detalhes sobre todas as ferramentas que usam. Se você não recebeu um livro de receitas que suporta seu fluxo de trabalho, não implantou o GIT, lançou-o nos desenvolvedores.

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

Sim.

Independentemente da ferramenta escolhida pela "empresa", sua equipe de desenvolvimento deve dedicar algum tempo aprendendo como usar a ferramenta corretamente. Nada prejudica a produtividade mais do que um monte de desenvolvedores com medo ou ignorância de uma ferramenta. Se eles estiverem usando errado ou trabalhando contra ele, surgirão problemas e, conforme o assunto, você será encarregado de limpar a bagunça.

O Git é uma transição difícil para muitos; portanto, uma sessão obrigatória de treinamento pode ser necessária. Isso deve ajudar a resolver muitos dos problemas que as pessoas estão enfrentando.

Eu usei o Git apenas em um ambiente pessoal e não profissional, e embora eu goste do poder que ele tem e da idéia de um controle de fonte mais descentralizado, ele tem grandes problemas. O Git tem abstração com vazamento e são necessários vários comandos para fazer coisas simples (por exemplo, para fazer uma alteração: git add, git commit e git push). Além disso, algumas das documentações estão ausentes e / ou confusas, como com a descrição do comando rebase ... "O local da porta de encaminhamento se confirma no cabeçalho upstream atualizado". Eu não tenho idéia do que isso significa, e embora eu saiba agora que você pode mudar de assunto e reescrever a história com ele (outro aborrecimento ... por que você deveria fazer isso ???) Eu nunca imaginaria isso com esse comando descrição. Acho que algumas leituras por parte de sua equipe e mais treinamento fornecido 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 sobre como sua equipe o usaria. Você não adotaria uma nova linguagem de programação sem diretrizes. O treinamento do motorista é muito mais eficaz quando as regras estabelecidas da estrada são incorporadas.

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

1. Execute tarefas diárias (confirmar, empurrar, puxar, ramificar, mesclar, dividir, etc.) sem segurar a mão.
2. Execute tarefas não rotineiras sem instruções repetidas. (Algumas repetições são aceitáveis ​​- eu tenho que encontrar alguém 2-3 vezes antes que o nome realmente grude.)

Se eles não conseguirem o número 1, a parte de treinamento da sua implantação provavelmente não será suficiente. Se eles não conseguem fazer o número 2, primeiro verifique se você está explicando as coisas com bastante clareza antes de ficar muito chateado.