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.
Respostas:
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.
fonte
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:
aqueles que os usuários mais avançados precisarão são
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.
fonte
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.
fonte
git gui
egitk
vem com o próprio git, e eu os achei muito mais fáceis de aprender do que as ferramentas de linha de comando. Se você é naturalmente orientado à linha de comando, as GUIs simples são ótimas para o básico, e você pode fazergit rebase
coisas mais complexas na linha de comando.Esta resposta tenta abordar como interessar programadores seniores
git
, não sobre como aprendergit
da 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
git
nerd e queria transformar uma equipe longe desvn
, 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,git
especificamente, você sempre tem o efeito de "por que deveríamos usá-lo se tudosvn
está bem?", O que é uma enorme barreira psicológica.Além disso, realmente grokking
git
requer 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 add
em 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, usegitk
como último recurso. Se vocês usam algum tipo de editor visual, encontre ogit
componente 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-file
os objetos reais para mostrar que eles são de fato tão triviais quanto os anunciados.Se você pode ajudá-los a entender que
git
subcomandos 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 ...ls
e comgit 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
svn
sã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. Emsvn
, 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
svn
caras é quesvn
usa 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
git
repositório é composto, é hora de mostrar exatamente o que osgit
subcomandos individuais fazem em termos deles.Estou falando sobre
add
,commit
em 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 push
egit pull
(no modo de avanço rápido! ) para mostrar a eles que,git
literalmente, 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.txt
aqui.Ramos
Observe que a ramificação é especialmente difícil para as
svn
pessoas, pois é totalmente diferente. Osvn
modelo é muito mais fácil de visualizar, pois basicamente não há nada para visualizar - ele está à vista. Ogit
modelo 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
é realmentegit fetch && git merge
; como todos os repositórios realmente contêm exatamente os mesmos objetos (git fetch
é quase o mesmo que copiar coisasscp
dentro 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
git
no futuro, considere substituir toda a interação porgit
comandos por scripts elaborados ou alguma GUI quegit
retire todos os detalhes. Coloque todo o controle de erros etc. nos scripts e tente fazê-lo funcionar.fonte
git
por uma super porcelana para não usargit
, de forma eficaz. O OP precisaria adotá-lo (incluindo o tempo envolvido) conforme apropriado para seus negócios. Como escrevi, não fui bem-sucedido com essa (ou qualquer outra) abordagem, para colocar todo mundo "dentro do redil", mas ainda assim, se eu fosse forçado a tentar novamente, essa seria a minha abordagem novamente.git
. Obviamente, todos os outros recursos (excelente documentação do git, tutoriais etc.) também são válidos. Gusdor, se você quiser saber mais, pesquise no google "objetos git" ou "estruturas de dados git" e encontrará rapidamente uma grande quantidade de informações. Eu adicionei alguns links na resposta. Você pode até pedir a um dos idosos que faça uma sessão sobre isso. ;)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:
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.
fonte
git status
que é vital, além dos quatro comandos que você anotou.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 :
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:
.gitignore
funcionaSim, 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.
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:
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:
Olhe para eles e o Gitflow, avalie-os contra seus casos de uso e escolha um que se encaixe.
fonte
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.
fonte
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.
fonte
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
.git
diretó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
.git
diretório e assim por diante ...fonte
Estou brincando de apresentar
git
onde 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:
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
git
especialista para parar de usargit
e seguir em frente,svn
não é? Eu acho que o especialista em git ficaria irritado e provavelmente não se esforçaria muitosvn
porquegit
funciona bem e há partes dele que ela realmente gosta que são difíceis de fazersvn
.Provavelmente é por isso que os juniores o adotaram melhor - talvez eles não tenham entendido
svn
egit
é 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: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
git
recursos?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 quegit
vale 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 recomendo que as pessoas lembrem que a maioria dos desenvolvedores não é burra quando se trata de coisas técnicas. Apenas descarte isso como uma razão até que não haja outras explicações.
e ser mais empregável, o que é algo que os idosos podem não pensar muito, especialmente considerando o envelhecimento que prevalece em nossa indústria.
fonte
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íciosgit
, 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 segit
pode resolver esses problemas, eles terão se convencido.fonte
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.
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.
fonte
git log --graph --abbrev-commit --decorate --date=relative --all
git gui
egitk
vem com o pacote principal do git, e não tente fazer com que o git pareça com qualquer outra coisa. Eles são excelentes, especialmentegitk --all
por ver todas as ramificações e por redefinir a ramificação atual para apontar para outras confirmações, ou coisas assim. No gitk, "cherry-pick" é uma das opções que você obtém ao clicar com o botão direito do mouse em um commit. Ele usa a mesma terminologia que as ferramentas de linha de comando.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 reflog
funciona. 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 -A
seguido porgit commit
nã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:
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.
fonte
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 rebase
são tratadosgl fuse
etc.) 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.fonte
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.
fonte
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.
fonte
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.
Portanto, assim que alguns me dizem que uma ferramenta é boa para ramificar, minha mente me diz.
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:
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.
fonte