Penso che questa domanda sia solo un caso speciale di "Perché dovrei imparare una CLI per cui esiste un'alternativa GUI?". Sospetto che l'ultima domanda sia vecchia quanto le GUI e presumo che ci siano stati molti tentativi di rispondere nel corso degli anni. Potrei provare a confondermi con la mia risposta a questa domanda, ma Neal Stephenson ha articolato quello che sono d'accordo con "la risposta definitiva" più di dieci anni fa nel suo straordinario saggio In principio ... era la riga di comando .
Mentre il saggio tocca molti aspetti dell'informatica, e anche se lo stesso Stephenson stesso pensa che di questo è ormai obsoleto, il saggio spiega in che modo le CLI sono migliori GUI in un modo estremamente convincente che ha letteralmente cambiato la mia vita. È una lettura lunga (~ 40 pagine), ma non posso raccomandarla abbastanza a chiunque faccia domande come le hai chiesto qui.
Infine, anche se risponderei a qualsiasi tipo di domanda CLI vs GUI in modo simile, penso che la mia risposta sia particolarmente vera per la tua domanda specifica poiché tutte le cose sul computer che hai scelto di chiedere su git . git è probabilmente l'ultimo strumento in una lista non troppo lunga di strumenti informatici che sono veramente degni della metafora del buco-falco, come descritto nel saggio di Stephenson. git , come molte altre cose Unix-ish, è un motivo per conoscere le CLI tutto in sé. A volte nonostante la sua errata "porcellana" ; a volte a causa di esso.
Quindi sì, puoi sicuramente essere produttivo con la GUI di github, sia per OSX che anche solo sul loro sito web. Sì, in realtà è abbastanza elegante, utilizzo spesso le funzionalità del sito. Ma no, non avrai mai quel sentimento divino come il tuo mignolo giusto si blocca sopra un comando git filter-branch folle per un eone o due. Se dovessi tenere solo una cosa della mia esperienza con il computer: le sfide mentali, le strette amicizie formate in un datacenter alle 2 del mattino, la scala infinita di competenze per scalare, toccare la vita degli utenti e regnare su PB di dati preziosi, la comodità lavoro e vita comoda - mantieni solo una cosa - sarebbe quel sentimento divino.
Se tutti i tuoi bisogni sono coperti, fantastico, non c'è bisogno di approfondire la tua esperienza, il tuo tempo sarebbe meglio speso nell'apprendimento di qualcosa di cui hai effettivamente bisogno.
git è solo uno strumento, quando dovrai fare qualcosa che non puoi con un'app GUI, lo saprai. Basta ricordare che github! = Git.
La maggior parte delle funzionalità solo della CLI entrano in gioco solo quando accidentalmente il tuo repository diventa strano e vuoi ripararlo. D'altra parte, il modo più comune per ottenere lo stato repo in uno stato strano è quello di utilizzare funzionalità avanzate che non capisci. Se ti limiti a ciò che fornisce la GUI, ciò coprirà le tue esigenze il 99% delle volte.
L'altro motivo per cui vuoi imparare la CLI è che è la lingua franca di git. Ciò significa che molte persone usano GUI diverse su piattaforme diverse, se chiedi aiuto su StackOverflow o altrove, la risposta è molto probabile che arrivi sotto forma di comandi CLI. Se non conosci la CLI, le tue opzioni per ottenere aiuto saranno molto più limitate.
Le applicazioni GUI si basano su interazioni manuali per eseguire comportamenti complessi. Questo è ottimo per la creazione di progetti e lo sviluppo di nuove cose.
I vantaggi di una CLI (Command-Line Interface) derivano dalla possibilità di creare script predeterminati che possono essere automatizzati. Tutta la GUI di GitHub è, è una bella grafica e pulsanti di fantasia che chiamano la git CLI.
Ciò che l'applicazione della GUI non fa per te è l'aggiornamento automatico del trunk di un repository su un server ogni giorno alle 1:30 del mattino, ma un cron job che chiama la git CLI è un modo davvero semplice per configurarlo.
Inoltre, quando si lavora su un progetto in un team, è conveniente configurare script di installazione, creare script, distribuire script e simili in modo che i compagni di squadra possano concentrarsi sulla risoluzione dei problemi invece delle noiose attività ripetitive.
Un altro motivo per cui la CLI potrebbe essere preferibile è una questione di flusso di lavoro. Molti framework sono gestiti tramite la riga di comando. Usando git attraverso la CLI mi permetto di rimanere concentrato sul mio progetto e nella directory del progetto. Ad esempio, potrei eseguire un test e poi decidere di eseguire il commit delle nuove modifiche tutte dalla stessa interfaccia e posizione.
Recentemente ho dovuto scavare davvero Git per essere in grado di aiutare con una migrazione SVN-to-Git. E la cosa che ho imparato è che gli strumenti da riga di comando di Git sono non la parte complicata da imparare.
I concetti e le idee dietro Git sono la parte complessa (e non perché sono mal progettati, ma semplicemente perché sono estranei alla maggior parte delle persone che provengono da altri VCS centralizzati).
Una volta che ho afferrato i concetti, le dichiarazioni della riga di comando sono diventate relativamente facili. Ciò significa che un'interfaccia utente non aiuta veramente capire Git (ad eccezione delle operazioni più semplici).
Conoscere la CLI è utile quando (non se) ci si trova in un ambiente in cui non è possibile accedere a un'app della GUI.
Uno scenario potenziale: ti viene chiesto di dare una mano per un paio di giorni a un progetto in un luogo chiuso in cui è fastidioso e lungo avere nuovi strumenti nel sistema. Usano solo la CLI. La tua produttività ha subito un successo perché hai bisogno di imparare tutto da capo.
Un motivo per imparare git da riga di comando è che la maggior parte della documentazione è scritta per quell'ambiente. Inoltre, se fai una domanda: "come faccio X con git?", È probabile che la risposta conterrà i comandi della riga di comando.
Uno dei problemi principali dell'utilizzo di una GUI rispetto alla riga di comando è che non è possibile avere lo stesso controllo sul processo, nella maggior parte dei casi. Ad esempio, l'applicazione GitHub è ottima in termini di usabilità per un sacco di flussi di lavoro git, ma potrebbe comunque essere ingombrante per processi di git avanzati.
Ad esempio, ecco alcune cose che non ho capito come usare l'applicazione GitHub (un'altra cosa da notare è che ogni GUI ha anche una curva di apprendimento).
Infine, le CLI consentono agli utenti di utilizzare questi strumenti durante lo scripting.
Non conosco GitHub per Mac, ma l'app di Windows esegue solo le attività più comuni: aggiungi, commit, push, pull, ecc. Compiti più complessi come git merge --no-ff devono essere eseguiti dalla riga di comando.
Inoltre, ci sono casi con git quando la GUI non è disponibile, ad es. quando SSHing nei server remoti.
Altrimenti, se la GUI ti dà tutto ciò che ti serve, imparare la linea di comando può essere una perdita di tempo. Il mio lavoro utilizza TortoiseSVN in ambiente solo Windows e non ho dovuto nemmeno toccare una riga di comando di SVN neanche una volta.
Ho appena appreso un caso in cui la CLI può essere migliore della GUI. Per illustrare questo, ho preso un esempio da un libro git - controllo della versione per tutti.
Quando vuoi condividere su una intranet, puoi usare:
Guarda i passaggi per creare un repository nudo.
Il comando per la creazione di un repository nudo sarebbe lo stesso di quello usato in precedenza clonare un repository ad eccezione del parametro --bare, che fa la differenza. %codice% L'esecuzione del codice precedente nella tua console dovrebbe creare un clone del nostro repository Workbench nella tua cartella condivisa comune chiamata generic_share.
Creare un clone nudo da un repository già esistente usando la GUI è un processo semplice. Tutto quello che devi fare è:
Copia la directory .git dal repository esistente e incollala con un nome_name.git (qualunque sia il nome che vuoi dare al tuo nuovo repository nudo) all'esterno del repository. Nel nostro caso abbiamo un repository non banale chiamato Workbench in C: \ Users \ raviepic3 \ Desktop \ all'interno del quale abbiamo content.docx. E ora voglio creare un nuovo repository nudo usando questa GUI. Copierò C: \ Users \ raviepic3 \ Desktop \ Workbench.git e lo incollerò come C: \ generic_share \ Bare_Workbench.git.
Apri git clone --bare C:\Users\raviepic3\Desktop\Workbench C:\generic_share\
Bare_Workbench in Bare_Workbench.git con un editor di testo e trova il
linea che dice config file e sostituisce la stringa false con true.
Salva ed esci.
Nella GUI, devi fare tanti clic e ricordare quale file deve essere modificato. Nella CLI, un semplice comando fa tutto per te.