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

Un po 'di contesto: sono al terzo anno di college. gli studenti sono divisi in gruppi di 4. Quasi tutti lavoreranno sotto Windows (tranne pochi come me che sono su Linux). Come parte del curriculum scolastico, inizieremo presto a lavorare su un progetto per un vero cliente, ma io e un altro team ci chiediamo quale sia il modo migliore per condividere il nostro codice tra loro.

Lavoro part-time da 3 anni e ho avuto molta esperienza con git e mercurial su diversi progetti, quindi non ho alcun problema ad usare un sistema o l'altro. Tuttavia, nessuno dei miei compagni di squadra ha mai usato un sistema di controllo della versione prima. C'è anche un altro team che ha provato a utilizzare SVN ma ha avuto grossi problemi e preferirebbe provare qualcos'altro, quindi hanno chiesto la mia opinione.

I miei pensieri: ho sentito che mercurial + TortoiseHg ha una migliore integrazione sotto Windows, ma mi chiedo se il concetto di teste anonime possa confonderle anche se le spiego. D'altra parte, trovo che i rami git siano più facili da capire per un principiante (chiara separazione del lavoro per ciascun programmatore) ma non funziona altrettanto bene sotto Windows.

Mercuriale, senza dubbio.

Questo è ovviamente soggettivo e varia da una persona all'altra, ma l'opinione generale è che Mercurial è più facile da brontolare, specialmente per chi non conosce VCS o per chi proviene da una VCS di vecchia generazione.

Punti in mano:

1. Mercurial è stato sviluppato pensando a Windows ; Git è stato portato. Indipendentemente da ciò che qualcuno ha cercato di dirmi, Git è ancora un cittadino di seconda classe su Windows. Le cose sono nettamente migliorate negli ultimi anni, ma si vedono ancora molti battibecchi sul perché qualcosa funziona / o non funziona su Windows come nella scatola * nix. 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 (i selettori di opzione sono coerenti), ai suoi numeri locali per i commit invece degli hash SHA1 (chi ha mai pensato che gli hash SHA1 siano facili da usare ??!)

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

Ora, so che tutti questi sono dettagli, e possono essere appresi e tutto, ma il fatto è ... queste cose si sommano. E alla fine, uno sembra più semplice e più intuitivo di un altro. E il sistema di controllo delle versioni non dovrebbe essere qualcosa in cui si passa il tempo all'apprendimento: sei lì per imparare a programmare e poi a programmare; VCS è uno strumento.

Solo per notare; Uso Git e Mercurial ogni giorno. Non avere problemi a usarne uno. 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 di TortoiseHg è un'ottima esperienza su Windows. Quando ho sperimentato Git in passato, ho finito per andare invece 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 diramazione nella finestra del banco di lavoro. Dovrebbe chiarire le difficoltà di ramificazione di base.)

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

Se sei interessato a una terza opzione, suggerirei fossili . Trovo che la possibilità di lanciare un web server temporaneo per condividere il codice funzioni alla grande in piccoli progetti. Fossil è solo un eseguibile, quindi potresti metterlo e la tua fonte in una chiavetta USB e usarlo da qualsiasi computer universitario.

Utilizzalo fossil uiper avviare un server web temporaneo ovunque tu sia per far sincronizzare i tuoi compagni di studi con te. Ti dà anche un sistema di ticket, wiki e un'interfaccia web facile da usare per cambiare filiali e contrassegnare i commit.

Assicurati solo che leggano la guida di avvio rapido e / o il libro . Infine, esiste un progetto chiamato winFossil per offrire loro un'interfaccia utente più amichevole rispetto all'interfaccia utente web.

Dato che i team sono nuovi nel controllo delle versioni e molti usano Windows, consiglierei mercurial su git.

Il modello concettuale del controllo di versione utilizzato da Git e Mercurial è molto simile, quindi una volta che hai imparato l'uno, è facile raccogliere l'altro (e per ragioni simili, è abbastanza facile convertire un repository da uno all'altro) . Questo significa che non è un grosso problema se cambi idea in seguito.

Secondo me, mercurial è più facile da imparare per i nuovi utenti. Rende le cose semplici facili e pericolose quelle difficili. Git semplifica le operazioni pericolose (facile da eseguire, non necessariamente facile da eseguire correttamente!).

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

La mia preferenza personale è per git.

Tuttavia, poiché alcune persone useranno Windows ed esiste il superbo tutorial hginit , consiglierei di insegnare loro mercurial.

Come molte persone hanno suggerito, Mercurial via TortoiseHg ha una barriera molto bassa all'ingresso.

Per quelli su Windows è un singolo programma di installazione piuttosto che due programmi di installazione (e un sacco di cose che potrebbero non voler conoscere) e l'interfaccia utente THg è molto più raffinata di TortoiseGit + Msysgit .

Teste anonime

Se pensi che sarebbero confusi da teste anonime, quindi non incoraggiarne l'uso. La maggior parte dei hglibri ha un approccio equilibrato e insegna sia rami topologici che nominati e lascia che il lettore determini quale sia il più appropriato per il loro uso.

Rami nominati

Una cosa che mi manca davverogit è hgil nome dei rami , quindi questa è un'opzione. giti rami vanno bene mentre ci stai lavorando, ma una volta che hai unito quel lavoro in un altro ramo, perdi gran parte del contesto per quei cambiamenti.

In hgpuoi creare un ramo chiamato Jira#1234ed essere sempre in grado di trovare tutte le revisioni associate a quella correzione . In git, una volta che il tuo ramo viene 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 l'ultimo commit su quel ramo, non quale dei suoi antenati faceva parte di quella catena di commit.

segnalibri

In alternativa, se non si desidera utilizzare i rami con nome, ma si desidera un gitflusso di lavoro di stile con i rami anonimi, è possibile utilizzare invece i segnalibri .

Questo potrebbe essere il migliore dei due mondi: imparano un gitflusso di lavoro, ma usano i hgcomandi più semplici .

Area indice / cache / staging

Personalmente, penso che gli studenti abbiano molte più probabilità di essere confusi gitdall'indice / cache / area di gestione temporanea che dalle hgteste anonime. Preferisco di gran lunga hgrendere opzionale questa funzionalità avanzata sulla riga di comando, oltre a gitpensare che tu voglia / debba sempre usarla.

Penso anche che l'area di stadiazione incoraggi impegni che non sono stati testati o addirittura compilati. Dal momento che molti dei posti in cui ho lavorato hanno avuto un non commit se non compila la regola, preferirei piuttosto accantonare / nascondere le modifiche che non voglio in questo momento, rieseguire unit test e eseguire il commit di una versione che Conosco compilazioni.

Quando in seguito vieni a rintracciare un bug usando hg bisect o git bisect , ti ringrazierai di poter testare tutte le revisioni, non solo quelle che vengono compilate.