Quale DVCS (git o hg) è più facile per programmare gli studenti? [chiuso]

Mercuriale, senza dubbio.

Questo è ovviamente soggettivo e vaires da persona a persona, ma l'opinione generale è che Mercurial è più facile da convincere, specialmente per qualcuno che è nuovo a VCS o qualcuno che proviene da uno dei VCS di vecchia generazione.

Punti in mano:

1. Mercurial è stato sviluppato pensando a Windows ; Git è stato portato. Non importa cosa qualcuno abbia provato a dirmi, Git è ancora un cittadino di second'ordine su Windows. Le cose sono decisamente migliorate negli ultimi anni, ma si vedono ancora molti litigi sul motivo per cui qualcosa funziona o non funziona su Windows come ha fatto su * nix box. TortoiseHg funziona molto bene e le implementazioni di Visual Studio sono ancora più facili da usare senza interrompere il flusso di lavoro.

2. Se qualcuno inizia la discussione "Git è più potente dopo di te ...", allora sta praticamente dicendo tutto. Per il 95% degli utenti Mercurial sembra più intuitivo. A partire da una mancanza di indice, alle sue opzioni più intuitive (le opzioni sono coerenti), ai numeri locali per i commit invece degli hash SHA1 (chi ha mai pensato che gli hash SHA1 siano user-friendly ??!)

3. I rami di Mercurial non sono meno potenti di quelli di Git. Post che descrive alcune delle differenze. Tornando ad alcune revisioni precedenti è semplice come "aggiorna la vecchia revisione". A partire da lì; basta fare un nuovo commit. I rami nominati sono anche disponibili se si desidera utilizzarli.

Ora, so che tutti questi sono dettagli, e possono essere appresi e tutto, ma la cosa è ... queste cose si sommano. E alla fine, sembra più semplice e intuitivo di un altro. E il sistema di controllo della versione non dovrebbe essere qualcosa che si spende per imparare il tempo: sei lì per imparare la programmazione e poi per programmare; VCS è uno strumento.

Solo per notare; Io uso quotidianamente Git e Mercurial. Non avere problemi a usare uno di questi. Ma quando qualcuno mi chiede una raccomandazione, consiglio sempre Mercurial. Ricordo ancora, quando è arrivato per la prima volta nelle mie mani, mi è sembrato molto intuitivo. Nella mia esperienza, Mercurial produce solo meno WTF / minuto di Git.

Ho scoperto che l'interfaccia utente TortoiseHg è una grande esperienza su Windows. In passato, quando ho sperimentato Git, ho finito per passare alla riga di comando. Per il tuo utente medio, una buona interfaccia utente è molto più accessibile di una riga di comando. Quindi, suggerirei di usare Mercurial. (Include anche un bel grafico di ramo nella finestra del workbench. Dovrebbe chiarire qualsiasi difficoltà di ramificazione di base.)

Una volta che capiscono le cose dal punto di vista dell'interfaccia utente, potrebbero finire per andare alla riga di comando per eseguire script o eseguire operazioni manuali, ma non è necessario.

Se sei interessato a una terza opzione, ti suggerisco fossile . Trovo che la possibilità di creare un server web temporaneo per condividere il codice funzioni bene in piccoli progetti. Fossil è solo un eseguibile, quindi puoi metterlo e la tua fonte in una pen drive e usarlo da qualsiasi computer universitario.

Usa fossil ui per avviare un server web temporaneo ovunque tu voglia far sincronizzare gli altri studenti con te. Fornisce anche un sistema di ticket, wiki e un'interfaccia Web facile da usare per cambiare rami e commit di tag.

Assicurati solo che leggano la guida rapida e / o libro . Infine, c'è un progetto chiamato winFossil per dare un'interfaccia utente più amichevole del web ui.

Dato che i team sono nuovi al controllo della versione, e molti usano Windows, io raccomanderei mercurial over git.

Il modello concettuale di controllo della versione usato da git e mercurial è molto simile, quindi una volta che ne hai padroneggiato uno, è facile prendere l'altro (e per ragioni simili, è abbastanza facile convertire un repository da uno a l'altro). Ciò significa che non è un grosso problema se cambi idea in seguito.

Secondo me, Mercurial è più facile da apprendere per i nuovi utenti. Semplifica le cose semplici e quelle pericolose. Git rende facili le operazioni pericolose (facile da fare, non necessariamente facile da fare correttamente!).

Anche l'interfaccia TortoiseHg per Winodows è molto bella ed è un altro argomento a favore dell'uso di mercurial.

La mia preferenza personale è per git.

Tuttavia, dato che alcune persone useranno Windows e il superbo tutorial hginit esiste, ti consiglio di insegnare loro il mercurial.

Come molte persone hanno suggerito, Mercurial tramite TortoiseHg ha una barriera molto bassa per entrare.

Per quelli su Windows è un singolo programma di installazione piuttosto che due programmi di installazione (e un intero carico di cose di cui non si vuole sapere nulla) e l'interfaccia utente di THg è molto più raffinata di TortoiseGit + Msysgit .

Teste anonime

Se pensi che sarebbero confusi da teste anonime, allora non incoraggiarne l'uso. La maggior parte dei libri di hg adottano un approccio equilibrato e insegnano sia i rami topologici che quelli denominati e consentono al lettore di determinare quale sia il più appropriato per il loro utilizzo.

Rami nominati

Una cosa che io davvero manca in git è hg rami denominati , quindi questa è un'opzione. % filiali digit vanno bene mentre ci stai lavorando, ma una volta che hai fuso quel lavoro in un altro ramo, perdi molto del contesto per queste modifiche.

In hg potresti creare un ramo chiamato Jira#1234 e essere sempre in grado di trovare tutte le revisioni associate a quella correzione . In git , una volta che il tuo ramo è unito e il ref eliminato, devi dedurre quali revisioni facevano parte della correzione dalla topologia dell'albero delle revisioni. Anche se non elimini l'arbitro, conosci ancora solo l'ultimo commit su quel ramo, non quale dei suoi antenati faceva parte di quella catena di commit.

Segnalibri

In alternativa, se non vuoi utilizzare i rami nominati, ma vuoi un flusso di lavoro in stile git con i tuoi rami anonimi, puoi utilizzare preferiti invece.

Questo potrebbe essere il migliore dei due mondi: imparano un flusso di lavoro git , ma puoi usare i comandi hg più semplici.

Indice / Cache / Area di gestione temporanea

Personalmente, penso che gli studenti siano molto più inclini a essere confusi dall'area indice / cache / staging di git che dalle teste anonime di hg . Preferisco di gran lunga hg rendendo questa funzionalità avanzata opzionale sulla riga di comando, mentre git presuppone che tu voglia / abbia sempre bisogno di usarlo.

Penso anche che l'area di sosta incoraggia i commit che non sono stati testati o nemmeno compilati. Dal momento che molti dei luoghi in cui ho lavorato hanno una regola non eseguire il commit se non viene compilata , preferirei piuttosto shelve / stash modifiche I do not voglio subito, rieseguire i test unitari e impegnare una versione che conosco compila.

Quando in seguito arriverà a rintracciare un bug utilizzando hg bisect o git bisect , ti ringrazierai che puoi testare tutte le revisioni, non solo quelle che compilano.