Pourquoi apprendre Git quand il existe des applications GUI pour GitHub?
Étant donné que GitHub fournit des applications GUI pour Mac et Windows , quels sont les avantages d'apprendre à utiliser git à partir de la ligne de commande?
Actuellement, j'utilise leur application mac pour mettre à jour mes référentiels, et jusqu'à présent, il semble couvrir mes besoins. Que pourrais-je manquer?
Je pense que cette question n'est qu'un cas spécial de "Pourquoi devrais-je apprendre une CLI pour laquelle une alternative GUI existe?". Je soupçonne que cette dernière question est à peu près aussi ancienne que les interfaces graphiques, et je suppose qu'il y a eu de nombreuses tentatives pour y répondre au fil des ans. Je pourrais essayer de me frayer un chemin à travers ma propre réponse à cette question, mais Neal Stephenson a articulé ce avec quoi je suis d'accord comme la `` réponse ultime '' il y a plus de dix ans dans son remarquable essai Au début ... était la ligne de commande .
Alors que l'essai touche à de nombreux aspects de l'informatique, et même si Stephenson lui-même pense que beaucoup d'entre eux sont maintenant obsolètes, l'essai explique de quelle manière les CLI sont de meilleures interfaces graphiques d'une manière extrêmement convaincante qui a littéralement changé ma vie. C'est une longue lecture (~ 40 pages), mais je ne le recommanderai jamais assez à quiconque pose des questions comme vous l'avez posée ici.
Enfin, même si je répondrais à n'importe quelle sorte de question CLI vs GUI dans la même veine, je pense que ma réponse est particulièrement vraie pour votre question spécifique car de toutes les choses informatiques que vous avez choisies de poser sur git. git est sans doute le dernier outil d'une liste pas si longue d'outils informatiques qui sont vraiment dignes de la métaphore du trou-hawg comme décrit dans l'essai de Stephenson. git, comme plusieurs autres choses Unix-ish, est une raison de connaître les CLI en soi. Parfois malgré son caractère erratique 'porcelaine' ; parfois à cause de cela.
Alors oui, vous pouvez certainement être productif avec l'interface graphique de github, que ce soit pour OSX ou même simplement sur leur site Web. Oui, c'est en fait assez élégant, j'utilise souvent les fonctionnalités du site. Mais non, vous n'aurez jamais ce sentiment divin alors que votre petit doigt droit est suspendu au-dessus d'un fou git filter-branch commande pour un éon ou deux. Si je devais garder une seule chose de mon expérience avec l'informatique - les défis mentaux, les amitiés étroites formées dans un centre de données à 2 heures du matin, l'échelle infinie de compétences pour grimper, toucher la vie des utilisateurs et régner sur des PB de données précieuses, le cushy emplois et vie confortable - gardez juste une chose - ce serait ce sentiment divin.
Si tous vos besoins sont couverts, génial, pas besoin de creuser plus profondément dans git, votre temps serait mieux consacré à apprendre quelque chose dont vous avez réellement besoin.
git n'est qu'un outil, quand vous aurez besoin de faire quelque chose que vous ne pouvez pas faire avec une application GUI, vous le saurez. Gardez juste à l'esprit que github! = Git.
La plupart des fonctionnalités CLI uniquement n'entrent en jeu que lorsque vous placez accidentellement votre référentiel dans un état étrange et que vous souhaitez le corriger. D'un autre côté, la façon la plus courante de mettre votre repo dans un état étrange est d'utiliser des fonctionnalités avancées que vous ne comprenez pas. Si vous vous en tenez à ce que propose l'interface graphique, cela couvrira vos besoins 99% du temps.
L'autre raison pour laquelle vous voudrez peut-être apprendre le CLI est qu'il s'agit de la lingua franca de git. Cela signifie que si de nombreuses personnes utilisent différentes interfaces graphiques sur différentes plates-formes, si vous demandez de l'aide sur StackOverflow ou ailleurs, la réponse viendra très probablement sous la forme de commandes CLI. Si vous ne connaissez pas l'interface CLI, vos options pour obtenir de l'aide seront beaucoup plus limitées.
Les applications GUI s'appuient sur des interactions manuelles pour effectuer des comportements complexes. C'est idéal pour mettre en place des projets et développer de nouvelles choses.
Les avantages d'une interface de ligne de commande (CLI) proviennent de la possibilité de créer des scripts prédéterminés qui peuvent être automatisés. Toute l'interface graphique de GitHub est, est quelques beaux graphiques et boutons fantaisie qui appellent la CLI git.
Ce que l'application GUI ne fera pas pour vous est de mettre à jour automatiquement le tronc d'un dépôt sur un serveur tous les jours à 1h30, mais un travail cron qui appelle la CLI git est un moyen très simple de définir cela vers le haut.
De plus, lorsque vous travaillez sur un projet dans une équipe, il est pratique de configurer des scripts d'installation, de créer des scripts, de déployer des scripts, etc. pour que les coéquipiers puissent se concentrer sur la résolution de problèmes plutôt que sur des tâches répétitives fastidieuses.
Une autre raison pour laquelle la CLI pourrait être préférable est une question de flux de travail. De nombreux frameworks sont gérés via la ligne de commande. L'utilisation de git via la CLI m'a permis de rester concentré sur mon projet et dans ce répertoire de projet. Par exemple, je peux exécuter un test, puis décider de valider les nouvelles modifications à partir de la même interface et du même emplacement.
J'ai récemment dû vraiment creuser dans Git pour pouvoir aider avec une migration de SVN vers Git. Et ce que j'ai appris, c'est que les outils de ligne de commande Git sont pas la partie compliquée à apprendre.
Les concepts et les idées derrière Git sont la partie complexe (et ce n'est pas parce qu'ils sont mal conçus, mais simplement parce qu'ils sont étrangers à la plupart des gens qui viennent d'un autre VCS centralisé).
Une fois que j'ai saisi les concepts, les instructions de ligne de commande sont devenues relativement faciles. Cela signifie qu'une interface utilisateur n'aide pas vraiment comprendre Git (sauf pour les opérations les plus simples).
La connaissance de la CLI est utile lorsque (pas si) vous êtes dans un environnement où vous ne pouvez pas accéder à une application GUI.
Un scénario potentiel: on vous demande d'aider pendant seulement quelques jours sur un projet dans un endroit fermé où il est extrêmement difficile et long d'obtenir de nouveaux outils dans le système. Ils utilisent uniquement CLI. Votre productivité a juste pris un coup parce que vous devez tout réapprendre.
L'une des raisons d'apprendre git en ligne de commande est que la plupart de la documentation est écrite pour cet environnement. De plus, si vous posez une question: "comment faire X avec git?", Il est probable que la réponse contienne des commandes en ligne de commande.
L'un des principaux problèmes liés à l'utilisation d'une interface graphique par rapport à la ligne de commande est que vous ne pouvez pas avoir le même contrôle sur votre processus, dans la plupart des cas. Par exemple, l'application GitHub est excellente en termes de convivialité pour de nombreux flux de travail git, mais pourrait toujours être lourde pour les processus git avancés.
À titre d'exemple, voici certaines choses que je n'ai pas compris comment faire en utilisant l'application GitHub (une autre chose à noter est que chaque interface graphique a également une courbe d'apprentissage).
- Rebasing commits
- Push/Pull/Fetch individuellement (dans GitHub, ils sont regroupés dans une seule commande "sync" qui peut parfois causer des problèmes)
- Modification des validations
Enfin, les CLI permettent aux utilisateurs d'utiliser ces outils lors de l'écriture de scripts.
Je ne connais pas GitHub pour Mac, mais l'application Windows n'effectue que les tâches les plus courantes - ajouter, valider, pousser, tirer, etc. Tâches plus complexes comme git merge --no-ff doit être exécuté à partir de la ligne de commande.
En outre, il existe des cas avec git lorsque l'interface graphique n'est pas disponible, par exemple lors de la connexion SSH à des serveurs distants.
Mais sinon, si l'interface graphique vous donne tout ce dont vous avez besoin, l'apprentissage de la ligne de commande peut être une perte de temps. Mon travail utilise TortoiseSVN dans un environnement Windows uniquement, et je n'ai pas eu à toucher une seule fois à la ligne de commande SVN.
Je viens d'apprendre un cas dans lequel CLI peut être meilleur que GUI. Pour illustrer cela, j'ai pris un exemple d'un livre git - contrôle de version pour tout le monde.
Lorsque vous souhaitez partager sur un intranet, vous pouvez utiliser:
- Serveur Gitolite
- Répertoire de partage commun avec référentiels nus
Regardez les étapes de création d'un référentiel nu.
Création d'un référentiel nu en mode CLI
La commande de création d'un référentiel nu serait la même que celle que vous avez utilisée pour cloner un référentiel à l'exception du paramètre --bare, qui fait toute la différence. git clone --bare C:\Users\raviepic3\Desktop\Workbench C:\generic_share\ Bare_Workbench L'exécution du code précédent dans votre console devrait créer un clone nu de notre référentiel Workbench dans votre dossier partagé commun appelé generic_share.
Création d'un référentiel nu en mode GUI
La création d'un clone nu à partir d'un référentiel déjà existant à l'aide de l'interface graphique est un processus simple. Il vous suffit de:
Copiez le répertoire .git du référentiel existant et collez-le avec un autre_nom.git (quel que soit le nom que vous souhaitez donner à votre nouveau référentiel nu) en dehors du référentiel. Dans notre cas, nous avons un dépôt non nu appelé Workbench dans C:\Users\raviepic3\Desktop\à l'intérieur duquel nous avons content.docx. Et maintenant, je veux créer un nouveau référentiel nu à partir de cela en utilisant l'interface graphique. Je vais copier C:\Users\raviepic3\Desktop\Workbench.git et le coller sous C:\generic_share\Bare_Workbench.git.
Ouvrez le
config fileà l'intérieur de Bare_Workbench.git avec un éditeur de texte et recherchez la ligne qui ditbare = falseet remplacez la chaîne false par true.Sauvegarder et quitter.
Dans l'interface graphique, vous devez faire autant de clics et vous rappeler quel fichier doit être modifié. En CLI, une simple commande fait tout pour vous.