Por que aprender git quando existem aplicativos GUI para o GitHub?

Eu acho que esta questão é apenas um caso especial de "Por que eu deveria aprender qualquer CLI para o qual existe uma alternativa de GUI?". Eu suspeito que a última questão é tão antiga quanto GUIs, e presumo que houve muitas tentativas de respondê-la ao longo dos anos. Eu poderia tentar abalar o meu caminho através da minha própria resposta a esta questão, mas Neal Stephenson articulou o que eu concordo com a "resposta final" mais de dez anos atrás em seu ensaio notável No começo ... Era a linha de comando .

Enquanto o ensaio aborda muitos aspectos da computação, e enquanto o próprio Stephenson pensa que muito de agora é obsoleto, o ensaio explica de que maneira as CLIs são melhores GUIs de uma maneira extremamente convincente que literalmente mudou minha vida. É uma leitura longa (~ 40 páginas), mas não posso recomendar o suficiente para qualquer um que faça perguntas como as que você fez aqui.

Por fim, embora eu responda a qualquer tipo de pergunta de CLI vs GUI na mesma linha, acho que minha resposta se aplica especialmente à sua pergunta específica, já que todas as coisas de computador que você escolheu perguntam sobre git . O git é, indiscutivelmente, a ferramenta mais recente em uma lista não tão longa de ferramentas computacionais que são realmente dignas da metáfora do hawg, descrita no ensaio de Stephenson. git , como várias outras coisas Unix-ish, é uma razão para conhecer os CLIs por si só. Às vezes, apesar do seu errático 'porcelain' ; às vezes por causa disso.

Então, sim, você definitivamente pode ser produtivo com a GUI do github, seja para o OSX ou até mesmo apenas em seu site. Sim, é realmente muito elegante, eu uso os recursos do site com freqüência. Mas não, você nunca terá aquele sentimento Divino como o seu dedo mindinho direito paira acima de um comando git filter-branch insano por um ou dois ou dois. Se eu tivesse que guardar apenas uma coisa da minha experiência com computação - os desafios mentais, as amizades próximas formadas em um centro de dados às 2h, a escada infinita da competência para escalar, tocando a vida dos usuários e reinando sobre PBs de dados preciosos, empregos e vida confortável - mantenha apenas uma coisa - seria esse sentimento divino.

Se todas as suas necessidades são cobertas, impressionantes, não há necessidade de se aprofundar no git, seu tempo seria melhor gasto em aprender algo que você realmente precisa.

git é apenas uma ferramenta, quando você precisa fazer algo que não pode com um aplicativo GUI, você saberá. Apenas tenha em mente que github! = Git.

A maioria dos recursos somente CLI só entram em ação quando você acidentalmente coloca seu repositório em um estado estranho e quer consertá-lo. Por outro lado, a maneira mais comum de colocar seu repo em um estado estranho é usar recursos avançados que você não entende. Se você se ativer ao que a GUI oferece, isso cobrirá suas necessidades 99% do tempo.

A outra razão pela qual você pode querer aprender o CLI é que é a lingua franca do git. Isso significa que, embora muitas pessoas usem GUIs diferentes em plataformas diferentes, se você pedir ajuda no StackOverflow ou em outro lugar, a resposta provavelmente virá na forma de comandos da CLI. Se você não conhece o CLI, suas opções para obter ajuda serão muito mais limitadas.

Aplicativos GUI dependem de interações manuais para realizar comportamentos complexos. Isso é ótimo para configurar projetos e desenvolver coisas novas.

Os benefícios de uma interface de linha de comando (CLI) vêm da capacidade de criar scripts predeterminados que podem ser automatizados. Toda a GUI do GitHub é, são alguns bons gráficos e botões sofisticados que chamam o CLI do git.

O que o aplicativo GUI não faz para você é atualizar automaticamente o tronco de um repositório em um servidor diariamente às 1h30, mas um trabalho cron que chame a CLI git é uma maneira muito fácil para configurar isso.

Além disso, ao trabalhar em um projeto em equipe, é conveniente configurar scripts de instalação, criar scripts, implantar scripts e afins para que os colegas de equipe possam se concentrar na solução de problemas, em vez de tarefas repetitivas e tediosas.

Outra razão pela qual o CLI pode ser preferível é uma questão de fluxo de trabalho. Muitas estruturas são gerenciadas através da linha de comando. Usar o git através do CLI permite-me manter o foco no meu projeto e no diretório do projeto. Por exemplo, posso executar um teste e, em seguida, decidir confirmar as novas alterações, tudo a partir da mesma interface e localização.

Eu recentemente tenho que realmente me aprofundar no Git para poder ajudar com uma migração de SVN para Git. E o que aprendi é que as ferramentas de linha de comando do Git não são a parte complicada para aprender.

Os conceitos e idéias por trás do Git são a parte complexa (e isso não é porque eles são mal planejados, mas simplesmente porque são estranhos para a maioria das pessoas que vêm de algum outro VCS centralizado).

Depois de entender os conceitos, as instruções reais da linha de comando tornaram-se relativamente fáceis. Isso significa que uma UI realmente não ajuda em entender Git (exceto nas operações mais simples).

Conhecer o CLI é útil quando (não se) você estiver em algum ambiente em que você não pode acessar um aplicativo GUI.

Um cenário em potencial: você é solicitado a ajudar por apenas alguns dias em um projeto em um local fechado, onde é irritantemente difícil e demorado obter novas ferramentas no sistema. Eles só usam o CLI. Sua produtividade acabou de bater porque você precisa aprender tudo de novo.

Um motivo para aprender git de linha de comando é que a maioria das documentações é escrita para esse ambiente. Além disso, se você fizer uma pergunta: "como faço o X com o git?", Provavelmente a resposta conterá comandos da linha de comando.

Um dos principais problemas com o uso de uma GUI versus a linha de comando é que você não consegue ter o mesmo controle sobre o processo, na maioria dos casos. Por exemplo, o aplicativo GitHub é ótimo em termos de usabilidade para muitos fluxos de trabalho git, mas ainda pode ser complicado para processos git avançados.

Como exemplo, aqui estão algumas coisas que eu não descobri como fazer usando o aplicativo GitHub (outra coisa a notar é que cada GUI também possui uma curva de aprendizado).

• Rebasing confirma
• Pressione / Puxe / Busque individualmente (no GitHub eles são agrupados em um único comando "sync", o que pode causar problemas algumas vezes)
• Alterar os commits

Finalmente, as CLIs permitem que os usuários usem essas ferramentas ao criar scripts.

Eu não sei sobre o GitHub para Mac, mas o aplicativo do Windows executa apenas as tarefas mais comuns - adicionar, confirmar, enviar, extrair, etc. Tarefas mais complexas como git merge --no-ff precisam ser executadas a partir da linha de comando.

Além disso, há casos com git quando a GUI não está disponível, por exemplo, quando SSHing em servidores remotos.

Caso contrário, se a GUI fornecer tudo o que você precisa, a linha de comando de aprendizado pode ser uma perda de tempo. O meu trabalho usa o TortoiseSVN no ambiente apenas do Windows, e não tive que tocar na linha de comandos do SVN sequer uma vez.

Acabei de aprender um caso em que o CLI pode ser melhor que o GUI. Para ilustrar isso, peguei um exemplo de um livro git - version control para todos.

Quando você deseja compartilhar em uma intranet, você pode usar:

1. Servidor de gitolite
2. Diretório de compartilhamento comum com repositórios nus

Veja os passos para criar um repositório simples.

Criando um repositório nu no modo CLI

O comando para criar um repositório nu seria o mesmo que você usou para clone um repositório, exceto o parâmetro --bare, que faz toda a diferença. %código% Executar o código anterior em seu console deve criar um clone nu do nosso repositório Workbench em sua pasta compartilhada comum chamada generic_share.

Criando um repositório vazio no modo GUI

Criar um clone nu a partir de um repositório já existente usando a GUI é um processo fácil. Tudo o que você precisa fazer é:

1. Copie o diretório .git do repositório existente e cole-o com um different_name.git (qualquer que seja o nome que você queira dar ao seu novo repositório nu) fora do repositório. No nosso caso, temos um repositório não nu chamado Workbench em C: \ Users \ raviepic3 \ Desktop \ dentro do qual temos content.docx. E agora eu quero criar um novo repositório nu usando GUI. Vou copiar C: \ Users \ raviepic3 \ Desktop \ Workbench.git e colá-lo como C: \ generic_share \ Bare_Workbench.git.

2. Abra o git clone --bare C:\Users\raviepic3\Desktop\Workbench C:\generic_share\ Bare_Workbench dentro de Bare_Workbench.git com um editor de texto e encontre o line que diz config file e substitui a string false por true.

3. Salve e saia.

Na GUI, você precisa fazer muitos cliques e lembrar qual arquivo deve ser editado. Na CLI, um comando simples faz tudo para você.