Pourquoi apprendre git quand il y a des applications graphiques pour GitHub?

Étant donné que GitHub fournit des applications graphiques pour Mac et Windows , quels sont les avantages d'apprendre à utiliser git à partir de la ligne de commande?

J'utilise actuellement leur application mac pour mettre à jour mes référentiels, et jusqu'à présent, cela semble couvrir mes besoins. Que pourrais-je rater?

Je pense que cette question est juste un cas particulier de "Pourquoi devrais-je apprendre n'importe quelle CLI pour laquelle une alternative graphique existe?". Je soupçonne que cette dernière question a à peu près le même âge que les interfaces graphiques et je suppose que de nombreuses tentatives ont été menées pour y répondre au fil des ans. Je pourrais essayer de me débrouiller dans ma propre réponse à cette question, mais Neal Stephenson a articulé ce que je considère comme la "réponse ultime" il y a plus de dix ans dans son remarquable essai In the Beginning ... était la ligne de commande .

Tandis que l'essai aborde de nombreux aspects de l'informatique et que même Stephenson lui-même pense que beaucoup d'entre eux sont maintenant obsolètes, il explique en quoi les CLI sont de meilleures interfaces graphiques de manière extrêmement convaincante qui ont littéralement changé ma vie. La lecture est longue (environ 40 pages), mais je ne saurais trop le recommander à quiconque pose des questions comme celle que vous avez posée ici.

Enfin, bien que je réponde à toutes les questions de la CLI contre l’interface graphique de la même manière, je pense que ma réponse est particulièrement fidèle à votre question spécifique, étant donné toutes les choses que vous avez choisi de demander git. gitest sans doute le dernier outil d'une liste pas si longue d'outils informatiques qui sont vraiment dignes de la métaphore de trou-hawg telle que décrite dans l'essai de Stephenson. git, comme plusieurs autres choses Unix-ish, est une raison de connaître les CLI tout en soi. Parfois malgré sa «porcelaine» erratique ; parfois à cause de cela.

Alors oui, vous pouvez définitivement être productif avec l'interface graphique de github, que ce soit pour OSX ou même tout simplement sur leur site web. Oui, c’est plutôt élégant, j’utilise souvent les fonctionnalités du site. Mais non, vous n'aurez jamais ce sentiment divin lorsque votre petit doigt droit pendra au-dessus d'un git filter-branchordre insensé pendant un ou deux. Si je ne devais garder qu’une chose de mon expérience informatique, c’est les défis mentaux, les amitiés proches nées dans un datacenter à 2 heures du matin, l’échelle infinie des compétences pour grimper, toucher la vie des utilisateurs et régner sur des PB de données précieuses, le emplois et vie confortable - ne gardez qu'une chose - ce serait ce sentiment divin.

Si tous vos besoins sont couverts, génial, nul besoin de creuser plus profondément, ce serait mieux de passer votre temps à apprendre quelque chose dont vous avez réellement besoin.

git est juste un outil, quand vous aurez besoin de faire quelque chose que vous ne pouvez pas faire avec une application graphique, vous le savez. N'oubliez pas que github! = Git.

La plupart des fonctionnalités réservées à la CLI entrent en jeu uniquement lorsque vous mettez accidentellement votre référentiel dans un état étrange et que vous souhaitez le réparer. D'autre part, le moyen le plus courant de placer votre pension dans un état bizarre consiste à utiliser des fonctionnalités avancées que vous ne comprenez pas. Si vous vous en tenez à ce que l'interface graphique fournit, cela couvrira vos besoins 99% du temps.

L'autre raison pour laquelle vous voudrez peut-être apprendre la CLI est qu'il s'agit de la lingua franca de Git. Cela signifie que si de nombreuses personnes utilisent des interfaces graphiques différentes sur des plates-formes différentes, si vous demandez de l'aide sur StackOverflow ou ailleurs, la réponse est susceptible de se présenter sous la forme de commandes CLI. Si vous ne connaissez pas la CLI, vos options pour obtenir de l'aide seront beaucoup plus limitées.

Les applications graphiques utilisent des interactions manuelles pour effectuer des comportements complexes. C'est parfait pour la mise en place de projets et le développement 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 pouvant être automatisés. Toute l’interface graphique de GitHub contient de jolis graphismes et de fantastiques boutons qui appellent la CLI de git.

Ce que l'application graphique ne fera pas pour vous, c'est la mise à jour automatique du coffre d'un référentiel sur un serveur tous les jours à 1h30, mais un travail cron qui appelle la CLI git est un moyen très simple de le configurer.

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., afin que vos 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. Utiliser git à travers la CLI me permet de rester concentré sur mon projet et dans le répertoire de ce projet. Par exemple, je pourrais exécuter un test puis décider de valider les nouvelles modifications à partir de la même interface et du même emplacement.

Récemment, je dois vraiment creuser dans Git pour pouvoir aider à la migration de SVN à Git. Et ce que j’ai appris, c’est que les outils en ligne de commande de Git ne sont pas compliqués à 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 compris les concepts, les instructions en ligne de commande sont devenues relativement faciles. Cela signifie qu'une interface utilisateur n'aide pas vraiment à comprendre Git (à l'exception des opérations les plus simples).

Connaître l'interface de ligne de commande est utile lorsque (pas si) vous êtes dans un environnement où vous ne pouvez pas accéder à une application graphique.

Un scénario possible: vous êtes invité à apporter votre aide pendant quelques jours à un projet dans un lieu clos où il est extrêmement long et pénible d’intégrer de nouveaux outils dans le système. Ils utilisent uniquement CLI. Votre productivité vient de prendre un coup parce que vous devez tout apprendre à nouveau.

Une raison pour 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 puis-je faire X avec git?", Il y a de fortes chances que la réponse contienne des commandes en ligne de commande.

L’un des principaux problèmes de l’utilisation d’une interface graphique par rapport à la ligne de commande est qu’il vous est impossible d’avoir le même contrôle sur votre processus, dans la plupart des cas. Par exemple, l'application GitHub est excellente en termes de facilité d'utilisation pour de nombreux workflows git, mais peut néanmoins s'avérer fastidieuse pour les processus git avancés.

À titre d'exemple, voici certaines choses que je n'ai pas comprises comment utiliser l'application GitHub (une autre chose à noter est que chaque interface graphique a aussi une courbe d'apprentissage).

• Réinitialisation des commits
• Push / Pull / Fetch individuellement (dans GitHub, ils sont regroupés dans une seule commande "sync" pouvant parfois poser problème)
• Modification des commits

Enfin, les CLI permettent aux utilisateurs d’utiliser ces outils lors de la création 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, extraire, etc. Des tâches plus complexes, comme celles qui git merge --no-ffdoivent être exécutées à partir de la ligne de commande.

De plus, il y a des cas avec git quand l'interface graphique n'est pas disponible, par exemple lorsque SSHing sur des serveurs distants.

Mais sinon, si l'interface graphique vous donne tout ce dont vous avez besoin, alors apprendre la ligne de commande risque de vous faire perdre du temps. Mon travail utilise TortoiseSVN dans un environnement uniquement Windows et je n'ai pas eu à toucher à la ligne de commande SVN, même une fois.

Je viens d'apprendre un cas dans lequel la CLI peut être meilleure que l'interface graphique. Pour illustrer cela, j'ai pris un exemple dans un livre git - le contrôle de version pour tous.

Lorsque vous souhaitez partager sur un intranet, vous pouvez utiliser:

1. Serveur Gitolite
2. Répertoire de partage commun avec des référentiels nus

Regardez les étapes pour créer un rapport nu.

Création d'un référentiel nu en mode CLI

La commande permettant de créer un référentiel nu serait identique à celle 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 graphique

La création d'un clone nu à partir d'un référentiel existant à l'aide de l'interface graphique est un processus simple. Tout ce que vous devez faire c'est:

1. Copiez le répertoire .git à partir du référentiel existant et collez-le avec un nom différent (quel que soit le nom que vous souhaitez attribuer à votre nouveau référentiel) en dehors du référentiel. Dans notre cas, nous avons un référentiel non-dénommé appelé Workbench à l’adresse C: \ Users \ raviepic3 \ Desktop \ à l’intérieur de laquelle nous avons content.docx. Et maintenant, je veux créer un nouveau référentiel nu à partir de cette interface graphique. Je vais copier C: \ Users \ raviepic3 \ Desktop \ Workbench.git et le coller en tant que C: \ generic_share \ Bare_Workbench.git.

2. Ouvrez le config filefichier intérieur Bare_Workbench.git avec un éditeur de texte et recherchez la ligne qui dit bare = falseet remplacez la chaîne false par true.

3. Sauvegarder et quitter.

Dans l'interface graphique, vous devez faire autant de clics et vous rappeler quel fichier doit être édité. En CLI, une commande simple fait tout pour vous.