Stavo seguendo alcuni tutorial su TortoiseHg. Nonostante abbia una ricca interfaccia grafica, i primi esempi vengono forniti utilizzando le opzioni della riga di comando. L'utilizzo ideale coinvolge la riga di comando o è stato avviato in questo modo in modo da avere un'idea di ciò che sta accadendo sotto il cofano e GUI utilizza internamente questo comando comunque.
Usa quello che vuoi. Usa ciò che ha senso per ciò che stai facendo ora.
Mentre sono principalmente un tipo da linea di comando (utilizzo la GUI solo per ottenere una rappresentazione grafica del grafico di revisione), ho difficoltà a capire perché pensi che l'uso della riga di comando ti consenta di capire meglio cosa succede dietro il cofano (ben tollerato per GIT :)), di solito c'è una chiara mappatura tra i due anche se CL può darti accesso ad alcune funzioni poco usate.
Ora, a mio parere, l'automazione di ciò che può essere automatizzato nel processo è parte del lavoro e per questo, CL è obbligatorio.
È più facile scrivere tutorial utilizzando la CLI . Tutto ciò di cui hai bisogno è un testo! Cercare di dimostrare i flussi di lavoro in una GUI significa schermate, cerchi e frecce e un paragrafo sul retro di ciascuno di essi che spiega che cosa sono ciascuno.
Usa quello che vuoi. Non esiste un modo "giusto".
Preferisco un mix di entrambi.
La GUI va bene per l'uso quotidiano delle funzionalità di base.
Tuttavia, è molto utile sapere come funzionano le cose dietro le quinte sulla riga di comando, specialmente se si desidera utilizzare funzionalità più avanzate o scrivere script per automatizzare alcune attività comuni.
Idealmente, vorrai entrambi.
Generalmente, i comandi sono implementati come una riga di comando, il che significa che hai i seguenti vantaggi:
Quest'ultimo è estremamente importante. Vuoi che il tuo server di build controlli il tuo codice e non abbia un'API diretta per il sistema? Bene, con un'interfaccia a riga di comando, sarà in grado di funzionare. Lo stesso vale per tutto.
È iniziato come una riga di comando. Guarda svn, bzr, hg, git ... Alcuni necessari GUI, perché erano pigri per ricordare i comandi e i pulsanti ricercati, quindi la maggior parte delle GUI esistenti sono overlay per l'interfaccia della riga di comando, anche se ci sono alcuni di questi sistemi che sono Solo GUI (di solito non sono visibili e sono implementati in alcuni editor di testo).
Certo, entrambi sono necessari. In Windows è un po 'duro usare cmd per fare commit e usare VCS mentre in Linux uso personalmente command-line mercurial ogni volta che faccio i compiti più velocemente e più pulito.
Dove dovrebbe essere usato da (GUI vs riga di comando)? Hai la scelta. Impara entrambi (ne avrai bisogno) e poi usa quello migliore nel tuo personale parere.
Altro sull'argomento: link
Qualunque cosa funzioni per te. Ho visto maestri della GUI che sono così veloci da mettere in imbarazzo molti utenti della linea di comando e viceversa. L'unica cosa che conta è scegliere qualcosa e imparare i dettagli. Una volta che sei molto bravo in ciò che hai scelto, impara dall'altra parte.
Penso che sia la risposta generale per i tipi di software che le persone usano regolarmente: Inizialmente la GUI e una volta che qualcuno ha padroneggiato i concetti, allora sempre più linea di comando. Attualmente sto usando uno specifico strumento di controllo della versione in una volta al mese. Sarebbe impossibile per me ricordare qualsiasi sintassi della riga di comando. Quindi solo GUI.
D'altra parte, dopo alcuni mesi di utilizzo di subversion, diventava una linea di comando solo affare, non c'era bisogno di immagini.
Vedrai che la maggior parte delle risposte, si riferisce a utilizzare entrambi. Impara ad usare entrambi e usa ciascun metodo in base alla situazione.
Il G.U.I., di solito è più facile da usare, ma, ci sono degli scenari, se è necessario attenersi alla versione da riga di comando. Alcuni programmi I.D.E. includere o può essere esteso con un G.U.I. per il C.V.S. di tua scelta.
A volte, potrebbe essere necessario utilizzare un C.V.S. per file che non sono applicazioni o non supportati dal tuo I.D.E di programmazione.
Ho lavorato una volta, in un progetto VB6 in cui il VB6 I.D.E. incluso proprio C.V.S. incluso con il suo G.U.I., sfortunatamente non ha funzionato bene e, a volte, ha danneggiato i file o perso alcune versioni. Abbiamo dovuto installare un C.V.S. Open Source, che dovevamo utilizzare dalla riga di comando.
Usa qualsiasi cosa ti renda più produttivo, ma impara la CLI a prescindere. È la lingua franca del VCS, quindi dovrai saperlo per chiedere e / o rispondere alle domande su luoghi come lo stack overflow. Inoltre, le funzionalità più avanzate sono disponibili solo su CLI, quindi è probabile che alla fine finirai per volerlo, anche se solo raramente. Puoi anche mescolare e abbinare i clienti. Personalmente sono più produttivo utilizzando una GUI per la visualizzazione della cronologia e risolvendo manualmente le unioni e la CLI per tutto il resto.
TortoiseSVN per SVN su Win32 / 64, a causa delle sovrapposizioni di icone per il feedback visivo.
Altrimenti: GUI per operazioni meno frequenti (rilevabilità superiore e migliori affordances), riga di comando per le operazioni più comuni (maggiore parsimonia, minore numero di tasti).
La GUI è obbligatoria quando si dispone di uno strumento distribuito su un ampio gruppo di utenti.
Se questo strumento ha alcune operazioni multi-passo (creazione di uno spazio di lavoro, unione di più file, ...), una finestra di dialogo della procedura guidata è benvenuta.
Se questo strumento può presentare una rappresentazione grafica di alcuni stati (cronologia, albero delle versioni, diramazioni e unione, ...), un utente apprezzerà una finestra grafica invece di un muro di testo in una shell.
Ma una CLI è obbligatoria anche ogni volta che un'operazione GUI fallisce: la stessa operazione eseguita da una CLI spesso genera un messaggio di errore molto più preciso e completo rispetto alla finestra di dialogo di errore visualizzata dalla GUI.
E qualsiasi script può utilizzare ovviamente una CLI per scopi di automazione.
Se hai molte operazioni ripetute, come ad esempio aggiungendo alcuni ma non tutti i file
git add file1
git add file2
git add file3
...
git add fileN
quindi la GUI con le caselle di controllo è decisamente migliore.
Se devi inserire gli hash come argomenti del comando, la GUI è decisamente migliore (consenti di selezionare e non è necessario ricordare gli hash)
Leggi altre domande sui tag version-control command-line