Qual DVCS (git ou hg) é mais fácil para programar os alunos? [fechadas]


25

Um pouco de contexto: estou no terceiro ano da faculdade. os alunos são divididos em equipes de 4. Quase todo mundo estará trabalhando no Windows (exceto alguns como eu, que estão no Linux). Como parte do currículo da escola, em breve começaremos a trabalhar em um projeto para um cliente real, mas eu e outra equipe estamos nos perguntando qual seria o melhor caminho para compartilhar nosso código.

Trabalho em período parcial há 3 anos e tenho muita experiência usando o git e o mercurial em projetos diferentes, por isso não tenho problemas ao usar um sistema ou outro. No entanto, nenhum dos meus colegas de equipe já usou um sistema de controle de versão antes. Há também uma outra equipe que tentou usar o SVN, mas teve grandes problemas e prefere tentar outra coisa, então eles pediram minha opinião.

Meus pensamentos: Eu ouvi dizer que o mercurial + TortoiseHg tem uma melhor integração no Windows, mas estou me perguntando se o conceito de cabeças anônimas pode confundi-las, mesmo que eu as explique. Por outro lado, acho que os ramos git são mais fáceis para um iniciante (separação clara do trabalho de cada programador), mas não funcionam tão bem no Windows.


2
O git tem muito poder ativado por padrão, mas todos com quem conversei dizem que o mercurial é mais fácil de aprender, e estou inclinado a concordar com base nas minhas experiências usando os dois. E sim, as ferramentas mercuriais são mais fáceis de instalar no Windows vs. seus equivalentes git. Dito isto, espere orientar as pessoas e apontá-las para os tutoriais da primeira semana (ou mais ...).
Wkl

1
O uso de um DVCS desde o início provavelmente será a maneira mais simples de gerenciar as contribuições mescladas de vários colaboradores trabalhando em paralelo. Se você achar que as cabeças anônimas são confusas, não as use (mercurial suporta ramos nomeados).
Stephen C. Steel

2
Mais uma vez para vincular a esta postagem do blog? Git é um Harrier Jump Jet .
S28 /

1
Eu nunca entendi por que o todo "muito difícil de aprender" é importante. Certo, leva 20 minutos para aprender como se comprometer e se ramificar, e não em oposição a 10 ... Grande coisa?
alternativa

1
Assista (um) a eles através do hginit.com e tome medidas com base em suas reações.
Chelmertz 04/11

Respostas:


49

Mercurial, sem dúvida.

Naturalmente, isso é subjetivo e varia de uma pessoa para outra, mas a opinião geral é de que o Mercurial é mais fácil de se grudar, especialmente para alguém novo no VCS ou alguém de um dos VCS da velha geração.

Pontos na mão:

  1. Mercurial foi desenvolvido com o Windows em mente ; Git foi portado. Não importa o que alguém tente me dizer, o Git ainda é um cidadão de segunda categoria no Windows. Certamente, as coisas melhoraram nos últimos anos, mas você ainda vê muitas discussões sobre por que algo funciona / ou não funciona no Windows, como no * nix box. O TortoiseHg funciona muito bem e as implementações do Visual Studio são ainda mais fáceis de usar sem interromper o fluxo de trabalho.

  2. Se alguém inicia a discussão "O Git é mais poderoso depois de você ...", então ele está praticamente dizendo tudo. Para 95% dos usuários, o Mercurial parece mais intuitivo. Começando pela falta de índice, pelas opções mais intuitivas (as opções são coerentes), pelos números locais para confirmações, em vez dos hashes SHA1 (quem pensou que os hashes SHA1 são amigáveis ​​??!)

  3. Os ramos de Mercurial não são menos poderosos que os de Git. Post descrevendo algumas das diferenças. Voltar a uma revisão anterior é tão simples quanto "atualizar a revisão antiga". A partir daí; basta fazer um novo commit. As ramificações nomeadas também estão disponíveis se você desejar usá-las.

Agora, eu sei que tudo isso são detalhes, e eles podem ser aprendidos e tudo, mas a coisa é ... essas coisas se somam. E, no final, um parece mais simples e mais intuitivo que o outro. E o sistema de controle de versão não deve ser algo que se gasta tempo aprendendo - você está lá para aprender programação e depois programar; VCS é uma ferramenta.

Apenas para observar; Eu uso Git e Mercurial diariamente. Não tenha problemas para usar qualquer um deles. Mas quando alguém me pede uma recomendação, eu sempre recomendo o Mercurial. Ainda me lembro, quando ele chegou às minhas mãos, parecia muito intuitivo. Na minha experiência, Mercurial apenas produz menos WTF / minuto que Git.


4
+ para "VCS é uma ferramenta". Eu não tinha considerado as "pequenas coisas" como um fator, mas é verdade que quando você soma pequenos problemas aqui e ali, eles podem se tornar um verdadeiro incômodo.
Gregory Eric Sanderson

8
"O sistema de controle de versão não deve ser algo que se gasta tempo aprendendo." Isso é um monte de porcaria. Você sempre deve gastar tempo aprendendo suas ferramentas. Você gasta tempo aprendendo seu compilador; mas o VCS é uma ferramenta tão crítica para sua programação quanto seu compilador.
JesperE

9
+1. Especialmente o argumento "cidadão de segunda classe no Windows" é absolutamente importante nessa situação.
tdammers

+1 para "WTF (s) / minuto" ( osnews.com/story/19266/WTFs_m ). Essas crianças tem que aprender a skillz :-)
Ross Patterson

1
@ Mark é apenas o resultado de uma diferença de terminologia ... Uma ramificação no Git é realmente apenas um nome.
alternativa

10

Descobri que a interface do usuário do TortoiseHg é uma ótima experiência no Windows. Ao experimentar o Git no passado, acabei indo à linha de comando. Para o usuário médio, uma boa interface do usuário é muito mais acessível que uma linha de comando. Então, eu sugiro usar o Mercurial. (Ele também inclui um bom gráfico de ramificação na janela do ambiente de trabalho. Deve esclarecer qualquer uma das dificuldades básicas de ramificação.)

Uma vez que eles entendam as coisas da perspectiva da interface do usuário, eles podem acabar indo para a linha de comando para criar scripts ou executar operações manuais - mas não precisam.


Sendo um "viciado em console", nunca usei os aplicativos Tortoise {Svn, Git, Hg} antes, então não sabia que o TortoiseHg tinha um gráfico de ramificação. Vou ter que ir verificar isso
Gregory Eric Sanderson

4

Se você estiver interessado em uma terceira opção, sugiro fósseis . Acho que a capacidade de ativar um servidor web temporário para compartilhar código funciona muito bem em pequenos projetos. O Fossil é apenas um executável; portanto, você pode colocá-lo e sua fonte em um pen drive e usá-lo em qualquer computador da universidade.

Use fossil uipara iniciar um servidor Web temporário onde quer que você esteja para que seus colegas sincronizem com você. Também oferece um sistema de tickets, wiki e uma interface da web fácil de usar para alterar ramificações e confirmar as marcações.

Apenas certifique-se de ler o guia de início rápido e / ou o livro . Finalmente, existe um projeto chamado winFossil para oferecer a eles uma interface de usuário mais amigável do que a interface do usuário da web.


Ouvi coisas boas sobre fósseis, mas infelizmente não tenho muito tempo para me familiarizar com um novo DVCS. Prefiro usar algo com o qual estou acostumado (se possível), pois já sei como solucionar as armadilhas mais comuns. Mas obrigado pela sugestão, eu definitivamente analisarei quando tiver tempo.
Gregory Eric Sanderson

+1; O fóssil é pouco conhecido, mas é tão fácil de trabalhar e tão autônomo (dvsc + wiki + tickets + webserver) que é uma alternativa real para todo o trac ou mesmo o github.
Javier

Mas o fóssil não parecerá tão bom no currículo dos alunos quanto o git ou o hg, pois pouquíssimos indivíduos têm dificuldade com isso.
Ian

O Mercurial também possui a funcionalidade hg serve. Falta um rastreador de bugs e wiki, é claro. Mas também há bitbucket.com
Johannes Rudolph

3

Dado que as equipes são novas no controle de versão e muitas estão usando o Windows, eu recomendaria o mercurial over git.

O modelo conceitual de controle de versão usado pelo git e mercurial é muito semelhante; portanto, depois de dominar um, é fácil escolher o outro (e por razões semelhantes, é muito fácil converter um repositório de um para o outro) . Isso significa que não é grande coisa se você mudar de idéia mais tarde.

Na minha opinião, mercurial é mais fácil para novos usuários aprenderem. Torna as coisas simples fáceis e as perigosas difíceis. O Git facilita operações perigosas (fáceis de fazer, não necessariamente fáceis de fazer corretamente!).

A interface do TortoiseHg para o Winodows também é muito boa e é outro argumento a favor do uso do mercurial.


2

Minha preferência pessoal é pelo git.

No entanto, como algumas pessoas estarão usando o Windows e o excelente tutorial hginit existe, eu recomendaria ensiná-las a usar mercurial.


+1 por mencionar o hginit. Embora o Pro Git também seja muito bom.
Tamás Szelei 29/10

@ TamásSzelei, Obrigado, eu nunca tinha visto o Pro Git antes.
3151111

0

Como muitas pessoas sugeriram, o Mercurial via TortoiseHg tem uma barreira muito baixa à entrada.

Para os usuários do Windows, é um instalador único, e não dois instaladores (e um monte de coisas que eles talvez não queiram aprender) e a interface do usuário THg é muito mais polida que o TortoiseGit + Msysgit .

Cabeças anônimas

Se você acha que eles ficariam confusos com cabeças anônimas, não incentive o uso delas. A maioria dos hglivros adota uma abordagem equilibrada, ensina ramos topológicos e nomeados e permite que o leitor determine qual é o mais apropriado para seu uso.

Ramos nomeados

Uma coisa que eu realmente sinto falta gité hgo nome de branches , então essa é uma opção. gitramificações são boas enquanto você trabalha nelas, mas depois de mesclar esse trabalho em outra ramificação, você perde grande parte do contexto dessas alterações.

Em hgvocê poderia criar um ramo chamado Jira#1234e sempre ser capaz de encontrar todas as revisões associadas a essa correção . Em git, uma vez que sua ramificação é mesclada e a ref excluída, é necessário inferir quais revisões fizeram parte da correção da topologia da árvore de revisões. Mesmo que você não exclua a ref, você ainda sabe apenas o último commit nesse ramo, e não quais de seus ancestrais faziam parte dessa cadeia de commits.

Favoritos

Como alternativa, se você não quiser usar ramificações nomeadas, mas desejar um gitestilo de fluxo de trabalho com suas ramificações anônimas, poderá usar marcadores .

Esse poderia ser o melhor dos dois mundos - eles aprendem um gitfluxo de trabalho, mas usam os hgcomandos mais simples .

Área de índice / cache / armazenamento temporário

Pessoalmente, acho que é muito mais provável que os alunos se confundam com a gitárea de indexação / cache / preparação do que com hgos chefes anônimos. Eu prefiro hgtornar opcional essa funcionalidade avançada na linha de comando, da maneira que gitvocê sempre deseja / precisa usá-la.

Eu também acho que a área de preparação encoraja confirmações que não foram testadas ou compiladas. Como muitos dos locais em que trabalhei tiveram uma regra de não confirmar, se não compilar , prefiro arquivar / esconder as alterações que não quero no momento, executar novamente os testes de unidade e confirmar uma versão que Eu sei compila.

Quando você mais tarde rastrear um bug usando hg bisect ou git bisect , agradecerá a si mesmo por poder testar todas as revisões, não apenas as que são compiladas.


Você não precisa excluir o ramo git após concluir; é apenas personalizado. Também -1 para interpretar incorretamente os usos do índice - você não o usa para preparar commits ruins, mas para etapas parciais de uma série maior de commits. Geralmente, isso acontece durante uma nova refazer quando você está limpando seu histórico.
alternativa

@mathepic - Se você não excluir os nomes das filiais e enviar todos os ramos 'fixos' remotos para o controle remoto, terá um grande número de referências, assim como uma infinidade de filiais antigas em svn. Em hgestes nomes filiais são sempre topologicamente local, assim você só vê-los se você olhar para eles.
Mark Booth

@mathepic - Quanto ao seu -1, acho que você está interpretando mal o que estou dizendo. Não consigo imaginar por que alguém intencionalmente faria um commit ruim, mas com o git é fácil fazê-lo por acidente. Se você esquecer que o arquivo cimplementa uma interface modificada no arquivo ie acidentalmente confirmar o isem, centão se alguém puxar suas alterações antes que você comece a cometer ca compilação delas falhará. Se você usar o fluxo de trabalho stash / compilar / confirmar, esse erro simplesmente não ocorrerá, pois sua compilação será interrompida primeiro. Eu tentei deixar minha resposta mais clara.
Mark Booth
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.