Nella mia azienda mi trovo di fronte all'affermazione secondo cui le interfacce grafiche per VCS come SVN o (soprattutto) Git tendono a confondere i repository, specialmente per quanto riguarda la ramificazione.
Essendo un appassionato utente di Windows e GUI, ho difficoltà a credere che sia vero.
Specialmente per Git, accetto che alcune mosse siano troppo complesse per la conduzione tramite una GUI. Ma qual è il reale background di questa accusa?
In base alla mia esperienza, un front-end GUI ben progettato, come TortoiseHG non crea di per sé problemi, cosa invece causa problemi sono incomprensioni e disattenzione dell'utente.
Uso thg come esempio perché la mia esposizione a TortoiseSVN e TortoiseGit è limitato.
Con uno strumento GUI, è molto facile per un utente inesperto non notare che lo strumento farà qualcosa che non si aspetta. Ad esempio, con Mercurial , puoi avere un numero arbitrario di teste remote senza nome. Normalmente Hg si lamenterà se proverai a spingere una testina remota senza nome, ma se hai l'opzione 'force push' selezionata nella GUI, non si lamenterà e non farà altro che alzare la testa comunque. Ciò può causare confusione poiché le persone si chiedono a cosa serve questo ramo, è stabile e dovrei usarlo? .
Con uno strumento da riga di comando, tali situazioni provocheranno un errore o un avvertimento e gli utenti dovranno capire l'errore per capire come correggere l'errore (unione nel ramo che causa l'errore ) o ignorarlo (rinominare il ramo in modo che lo scopo sia ovvio e quindi forzare il push se non dovrebbe essere unito in questo momento).
In definitiva, mentre gli strumenti della GUI semplificano l'avvio con un VCS , sono non un sostituto per comprendere come funziona realmente VCS . Questo è il motivo per cui molte persone consigliano di imparare prima la riga di comando e poi di migrare alcune attività in strumenti della GUI in seguito per ottimizzare il flusso di lavoro.
Dipende davvero dalla GUI. Gli utenti di prima volta trovano TortoiseGit molto confuso e fondamentalmente usano la forza bruta per ottenere il check-in, il che significa che potrebbero o non rovinare il repository. In un hackathon che ho partecipato a pochi mesi fa, gli utenti che erano venuti per la prima volta erano in grado di rompere il repository (operazioni rapide, cattive fusioni, ecc.) In diverse occasioni. Non sono stati in grado di ottenere una buona panoramica di quello che sta succedendo. git-gui e in particolare SmartGit erano molto più facili da comprendere e lavorare con (git-gui tuttavia essendo molto limitato nella funzionalità).
(Si è trasferita come risposta ai commenti al mio commento).
Ho sempre pensato che le GUI incoraggiano le persone a "fare un giro" senza leggere il manuale.
L'uso di svn / git senza leggere il manuale è molto simile a far funzionare una mitragliatrice senza una pratica adeguata di tiro: ne consegue un danno collaterale may .
C'è anche un problema con le persone esperte di vcs che usano la riga di comando, non volendo avere nulla a che fare con la GUI, ( Tortoise è così ... click-menu-scroll-click-menu-scroll ) e quindi non aiuta il vcs gospel a diffondere tra i nuovi arrivati .
Quindi potrebbe esserci un problema con gli sviluppatori nuovi o esterni che lavorano su diverse piattaforme (quelle dang mac people che fanno app iOS o sviluppo / progettazione web) utilizzando un diverso GUI da quella che usi e che richiede un serio allenamento costante e veloce che risulta più difficile da impartire rispetto all'originale.
L'ignoranza. Poiché la risposta è troppo corta, TortoiseSVN e TortoiseGit mi hanno servito bene fino a quando non ho visto la luce e ho iniziato a usare la shell, ma ciò non significa che uno strumento sia semplice da usare. Se non comprendi la funzionalità sottostante, le astrazioni leaky e le informazioni occulte che occorrono per creare una GUI che è più facile da usare rispetto all'equivalente di shell rende molto difficile capire cosa sia realmente in corso sotto.
Ognuna (con piccole dimensioni di asserzioni) GUI implementa due paradigmi dalla triade "Nice - Smart - Fast". Nella maggior parte dei casi il perdente è intelligente. Più complesso il sistema originale perde di più nei limiti e nelle metafore della GUI. Il manuale per Git è un must , quindi - nel letto di GUrustean della GUI ha perso gran parte delle funzionalità, rispetto ad altri VCS.
Un altro lato sono gli utenti. Poiché le GUI (vedi sopra) danno un'impressione di avvio rapido e di facile utilizzo e nascondono alcune informazioni dall'end-user, alcuni noob non vedono alcun bisogno di studiare, RTFM e STWF: "perché funziona anche ora!" a meno che "SHIT HAPPENS! Oh, è un cattivo programma" dice "scimmia con granata" pigra, stupida, analfabeta e rumorosa (vedi al più git-boys qui, su SE - no RTFM, nessuna ricerca locale)
L'asserzione è di destra "Pasticcio della GUI ..."; ed è sbagliato da un altro lato: nel determinare le relazioni di causa ed effetto e la natura soggetto-oggetto.
Statisticamente e logicamente non la GUI, ma gli utenti di ... tendono a fare confusione, dato che tendono a confondere qualsiasi attività complessa in qualsiasi area