Зачем изучать git, когда есть приложения с графическим интерфейсом для GitHub?

Учитывая, что GitHub предоставляет приложения с графическим интерфейсом для Mac и Windows , каковы преимущества обучения использованию git из командной строки?

В настоящее время я использую их Mac-приложение для обновления своих репозиториев, и пока оно, похоже, покрывает мои потребности. Что я могу упустить?

Я думаю, что этот вопрос является лишь частным случаем «Почему я должен изучать любой CLI, для которого существует альтернатива GUI?». Я подозреваю, что последний вопрос примерно такой же старый, как GUI, и я предполагаю, что было много попыток ответить на него за эти годы. Я мог попытаться найти свой собственный ответ на этот вопрос, но Нил Стивенсон сформулировал то, с чем я согласен, как «окончательный ответ» более десяти лет назад в своем замечательном эссе « В начале ... Была командная линия» .

Хотя эссе затрагивает многие аспекты вычислительной техники, и хотя даже сам Стивенсон считает, что многие из них уже устарели, в эссе объясняется, каким образом CLI являются лучшими графическими интерфейсами в чрезвычайно убедительной манере, которая буквально изменила мою жизнь. Это долгое чтение (~ 40 страниц), но я не могу рекомендовать его всем, кто задает вопросы, подобные тем, которые вы задали здесь.

Наконец, хотя я и отвечал на любые вопросы типа CLI и GUI в том же духе, я думаю, что мой ответ особенно верен для вашего конкретного вопроса из всех компьютерных вещей, о которых вы решили спросить git. gitвозможно, это последний инструмент в небольшом списке компьютерных инструментов, которые действительно достойны метафоры «дырявого ястреба», как описано в эссе Стивенсона. gitКак и некоторые другие вещи в Unix, это причина знать CLI сами по себе. Иногда, несмотря на его неустойчивый «фарфор» ; иногда из-за этого.

Так что да, вы можете определенно работать с GUI GitHub, либо для OSX, либо даже просто на их сайте. Да, это на самом деле довольно гладко, я часто использую функции сайта. Но нет, у вас никогда не будет этого божественного чувства, когда ваш правый мизинец висит над безумной git filter-branchкомандой в течение эона или двух. Если бы мне пришлось утаить только одну вещь из моего опыта работы с компьютерами - умственные проблемы, близкие дружеские отношения, сложившиеся в центре обработки данных в 2 часа ночи, бесконечную лестницу умений, чтобы подняться, затрагивая жизнь пользователей и властвуя над ПБ ценных данных, удобные работа и комфортная жизнь - держите только одно - это было бы таким благочестивым чувством

Если все ваши потребности покрыты, круто, нет необходимости углубляться в git, ваше время будет лучше потрачено на изучение того, что вам действительно нужно.

git - это просто инструмент, когда вам нужно сделать что-то, что вы не можете сделать с помощью приложения с графическим интерфейсом, вы об этом узнаете. Просто имейте в виду, что github! = Git.

Большинство функций только для CLI вступают в действие, когда вы случайно переводите ваш репозиторий в странное состояние и хотите исправить его. С другой стороны, наиболее распространенный способ перевести репо в странное состояние - использовать расширенные функции, которые вы не понимаете. Если вы будете придерживаться того, что предоставляет графический интерфейс, это покроет ваши потребности в 99% случаев.

Другая причина, по которой вы можете захотеть изучить CLI, заключается в том, что это git's lingua franca. Это означает, что в то время как многие люди используют разные графические интерфейсы на разных платформах, если вы обратитесь за помощью в StackOverflow или в другом месте, ответ, скорее всего, придет в форме команд CLI. Если вы не знаете CLI, ваши возможности получения помощи будут гораздо более ограниченными.

Приложения GUI полагаются на ручные взаимодействия для выполнения сложных действий. Это отлично подходит для создания проектов и разработки новых вещей.

Преимущества интерфейса командной строки (CLI) заключаются в возможности создавать предопределенные сценарии, которые можно автоматизировать. Весь графический интерфейс GitHub - это приятная графика и красивые кнопки, которые вызывают git CLI.

То, что приложение GUI не сделает для вас, - это автоматическое обновление ствола репо на сервере ежедневно в 1:30, но задание cron, которое вызывает git CLI, - это действительно простой способ установить это.

Кроме того, при работе над проектом в команде удобно настраивать сценарии установки, создавать сценарии, развертывать сценарии и т. П., Чтобы товарищи по команде могли сосредоточиться на решении проблем, а не на утомительных повторяющихся задачах.

Другая причина, почему CLI может быть предпочтительнее, связана с рабочим процессом. Многие фреймворки управляются через командную строку. Использование git через CLI позволило мне сосредоточиться на своем проекте и в этом каталоге проекта. Например, я могу запустить тест и затем принять решение о внесении новых изменений с одного и того же интерфейса и местоположения.

Недавно мне пришлось по-настоящему покопаться в Git, чтобы иметь возможность помочь с миграцией из SVN в Git. И вот что я узнал, так это то, что инструменты командной строки Git не сложная часть для изучения.

Концепции и идеи, лежащие в основе Git, являются сложной частью (и это не потому, что они плохо спроектированы, а просто потому, что они чужды большинству людей, которые приходят из какой-то другой, централизованной VCS).

Как только я понял концепции, фактические операторы командной строки стали относительно простыми. Это означает, что пользовательский интерфейс на самом деле не помогает понять Git (за исключением самых простых операций).

Знание интерфейса командной строки полезно, когда (не если) вы находитесь в среде, где вы не можете получить доступ к приложению с графическим интерфейсом.

Один из возможных сценариев: вас просят помочь всего пару дней в проекте в закрытом месте, где досадно сложно и долго вводить новые инструменты в систему. Они используют только CLI. Ваша производительность просто пострадала, потому что вам нужно учить все заново.

Одна из причин изучения git из командной строки заключается в том, что большая часть документации написана для этой среды. Также, если вы зададите вопрос: «Как мне сделать X с git?», Скорее всего, ответ будет содержать команды командной строки.

Одна из основных проблем использования графического интерфейса пользователя по сравнению с командной строкой заключается в том, что в большинстве случаев вы не можете иметь одинаковый контроль над процессом. Например, приложение GitHub великолепно с точки зрения удобства использования для многих рабочих процессов git, но все же может быть громоздким для продвинутых процессов git.

В качестве примера, вот некоторые вещи, которые я не понял, как это сделать с помощью приложения GitHub (еще одна вещь, которую стоит отметить, это то, что у каждого GUI также есть кривая обучения).

• Ребазинг фиксирует
• Push / Pull / Fetch индивидуально (в GitHub они сгруппированы в одну команду «sync», которая может иногда вызывать проблемы)
• Внесение изменений

Наконец, CLI позволяют пользователям использовать эти инструменты при написании сценариев.

Я не знаю, что такое GitHub для Mac, но приложение Windows выполняет только самые распространенные задачи - добавление, принятие, нажатие, извлечение и т. Д. Более сложные задачи, такие git merge --no-ffкак выполнение из командной строки.

Кроме того, в git есть случаи, когда GUI недоступен, например, когда SSHing подключается к удаленным серверам.

Но в противном случае, если GUI дает вам все необходимое, изучение командной строки может быть пустой тратой времени. Моя работа использует TortoiseSVN в среде только для Windows, и мне не приходилось трогать командную строку SVN ни разу.

Я только что узнал один случай, когда CLI может быть лучше, чем GUI. Чтобы проиллюстрировать это, я взял пример из книги git - контроль версий для всех.

Если вы хотите поделиться через интранет, вы можете использовать:

1. Гитолит сервер
2. Общий общий каталог с пустыми репозиториями

Посмотрите на шаги для создания голого репо.

Создание чистого хранилища в режиме CLI

Команда для создания пустого репозитория будет такой же, как та, которую вы использовали для клонирования репозитория, за исключением параметра --bare, который имеет все значение. git clone --bare C:\Users\raviepic3\Desktop\Workbench C:\generic_share\ Bare_Workbench Выполнение предыдущего кода в вашей консоли должно создать чистый клон нашего репозитория Workbench в общей папке с именем generic_share.

Создание чистого репозитория в режиме GUI

Создание чистого клона из уже существующего репозитория с использованием графического интерфейса - это простой процесс. Все, что вам нужно сделать, это:

1. Скопируйте каталог .git из существующего репозитория и вставьте его с другим_имя.git (любое имя, которое вы хотите дать новому пустому репозиторию) вне репозитория. В нашем случае у нас есть не голое хранилище с именем Workbench в C: \ Users \ raviepic3 \ Desktop \, внутри которого у нас есть content.docx. И теперь я хочу создать новый пустой репозиторий из этого с использованием графического интерфейса. Я скопирую C: \ Users \ raviepic3 \ Desktop \ Workbench.git и вставлю его как C: \ generic_share \ Bare_Workbench.git.

2. Откройте config fileвнутри Bare_Workbench.git с помощью текстового редактора и найдите строку, которая говорит, bare = falseи замените строку false на true.

3. Сохранить и выйти.

В GUI вы должны сделать так много кликов и запомнить, какой файл нужно отредактировать. В CLI одна простая команда сделает все за вас.