Навіщо вивчати git, коли для GitHub є програми GUI?

84

Враховуючи, що GitHub надає графічні програми для Mac і Windows , які переваги можна навчитися використовувати git з командного рядка?

В даний час я використовую їхній додаток mac для оновлення моїх сховищ, і поки що, здається, він покриває мої потреби. Що я можу пропустити?

git github

— histelheim
джерело

15

Не забувайте gitk, який є gui для Linux.

— DeveloperDon

14

Вам не вистачає всього сценарію.

— SK-логіка

3

@KChaloux, так, є дуже вагома причина, чому більшість додатків GUI взагалі не піддаються написанню сценарію. А те, що написано на скрипті, просто жахливо (подумайте СОМ і подібні гидоти).

— SK-логіка

2

@KChaloux, ніяка причина - це не якість. Створити чистий графічний додаток із графічним сценарієм дуже важко. Усі розумні підходи, які я знаю, в основному побудовані при введенні певної форми інтерфейсу командного рядка - або в CLI-стилі Unix, або в текстовій мові команд, або в бінарному протоколі, який по суті є тим же, що і мова команди , див. COM. Але, найкращим підходом, звичайно, є спільне ядро, яке доступне як за допомогою різних інструментів CLI, так і від GUI. Останні також можуть бути побудовані на CLI для простоти.

— SK-логіка

13

Ви цього не робите. Таким же чином, вам не потрібно вивчати HTML / CSS, оскільки існують Dreamweaver та Frontpage (або все, що це зараз). Можливо, це допоможе вам у деяких справах, але коли хтось не краще знає, як це насправді працює.

— DorkRawk

116

Я думаю, що це питання є лише особливим випадком "Чому я повинен вивчити будь-який CLI, для якого існує альтернатива GUI?". Я підозрюю, що останнє питання є таким же старшим, як GUI, і я припускаю, що було багато спроб відповісти на нього протягом багатьох років. Я міг би спробувати пробитися шляхом власної відповіді на це запитання, але Ніл Стівенсон сформулював те, що я погоджуюсь як «остаточну відповідь» більше десяти років тому у своєму чудовому нарисі На початку ... Командний рядок .

У той час як есе торкається багатьох аспектів обчислень, і хоча навіть сам Стівенсон вважає, що багато з них зараз застаріло, есе пояснює, якими способами CLI є кращими графічними інтерфейсами в надзвичайно переконливій формі, що буквально змінило моє життя. Він довго читається (~ 40 сторінок), але я не можу його рекомендувати достатньо для тих, хто задає такі питання, як ви тут.

Нарешті, хоча я відповів би на будь-яке запитання CLI vs GUI подібним чином, я думаю, що моя відповідь особливо стосується вашого конкретного питання, оскільки всі комп'ютерні речі ви вирішили запитати git. gitМожливо, це найновіший інструмент у не надто довгому списку комп’ютерних інструментів, які справді варті метафори "дірка-хогг", як описано у нарисі Стівенсона. git, як і кілька інших речей Unix-ish, є приводом знати CLI всі самі по собі. Іноді, незважаючи на свій хаотичний «фарфор» ; іноді через це.

Так що так, ви точно можете бути продуктивними з графічним інтерфейсом github або для OSX, або навіть просто на їхньому веб-сайті. Так, це насправді досить гладко, я часто використовую функції сайту. Але ні, ви ніколи не матимете цього благочестивого почуття, як ваш правий рожевий висить над божевільною git filter-branchкомандою на еона чи двох. Якби мені довелося зберегти лише одне з мого досвіду роботи з обчисленнями - психічні виклики, тісні дружні стосунки, сформовані в датцентрі о 2 ранку, нескінченна драбинка компетентності підніматися, торкаючись життя користувачів і пануючи над ПБ цінних даних, легкий робота та комфортне життя - зберігайте лише одне - це було б богопочуття.

— Янів Акнін
джерело

5

Більш доступне посилання на початок ... Був командний рядок: pauillac.inria.fr/~weis/info/commandline.html

— Elias Zamaria

1

Re: застаріле: це була б частина "BeOS як Batmobile", правда?

— naught101

2

Гарретт Біркель оновив твір "На початку ... Був командний рядок", розшифровуючи свої коментарі до оригінального нарису Ніла Стівенсона. Про це можна прочитати тут .

— Мені подобається Код

2

... так, кому потрібен CLI, коли ви можете створити інтерфейс GUI за допомогою Visual Basic. Чудово підходить для таких речей, як відстеження IP-адреси.

— Ей,

3

Я не припускав, що «старше краще», я припускав, що CLI (для багатьох випадків використання хакерів) перевершують графічні інтерфейси. CLI також перевершують двійкові комутатори та патч-корди. Саме тому я використовую CLI. Стаття не є "доказом", оскільки "у статті", це проза з аргументами, які чітко формулюють те, що мені подобається в CLI. Це старе, але так є UNIX, так що. До речі, я працюю в Google, і переважна більшість розробників навколо мене використовує середовище розробки на базі CLI (але, звичайно, я не можу говорити про Google в цілому).

— Янів Акнін

108

Якщо всі ваші потреби охоплені, приголомшливі, не потрібно заглиблюватися в git, ваш час краще витратити на вивчення чогось, що вам потрібно.

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

— яніс
джерело

1

Я погоджуюся з вами, але можуть бути речі, про які я зараз не знаю, які можуть бути корисними мені, якби я був про них відомий. Немає?

— histelheim

28

@AronLindberg Так, напевно, є. Але ви задаєте неправильне запитання, на що вам слід витратити час на дослідження - це робочі процеси та концепції git, а не командний рядок. Навіть якщо хтось перераховує вам всю функціональність, якої програми GUI відсутні, то як би ви дізналися, чи потрібна вона? (також це те, що ви дуже легко можете зробити самостійно, просто переглянувши документацію git)

— yannis

//, CLI змусить вас подумати над робочими процесами та концепціями трохи більше, тому що вся організація, вибір та потік відбуватимуться у вашій голові, а не в Wizards та випадаючих меню.

— Натан Басанес

57

Більшість функцій, що стосуються лише CLI, вступають у дію лише тоді, коли ви випадково перебуваєте у сховищі у дивному стані та хочете його виправити. З іншого боку, найпоширеніший спосіб перевести репо в дивний стан - це використовувати розширені функції, які ви не розумієте. Якщо ви дотримуєтесь того, що надає графічний інтерфейс, це покриватиме ваші потреби 99% часу.

Інша причина, з якої ви можете дізнатися CLI - це те, що це лінгва франка. Це означає, що багато людей використовують різні графічні інтерфейси на різних платформах, якщо ви попросите допомоги в StackOverflow або в іншому місці, відповідь, швидше за все, надійде у вигляді команд CLI. Якщо ви не знаєте CLI, ваші варіанти отримання допомоги будуть набагато обмеженішими.

— Карл Білефельдт
джерело

Однозначно найкраща відповідь тут. Не бла-бла-бла-філософія.

— John cj

//, Це була моя перша думка, і хоча філософські відповіді мені сподобалися, головна причина, що я використовую CLI, полягає в тому, що вони набагато простіше міркувати, стандартизувати та спілкуватися з іншими над текстом. Ми, можливо, не всі знаємо, як малювати, але всі ми знаємо, як друкувати.

— Натан Басанес

9

Програми GUI розраховують на ручну взаємодію для виконання складних способів поведінки. Це чудово підходить для створення проектів та розробки нових речей.

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

Те, що додаток GUI не зробить для вас, - це автоматично оновлювати ствол репо на сервері щодня о 1:30 ранку, але робота cron, яка викликає CLI git, - це дійсно простий спосіб налаштувати це.

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

— zzzzBov
джерело

стовбур? Я думаю, ти маєш на увазі господар.

— jpmc26

@ jpmc26, я писав це, коли я був новачок у Git, що надходить із SVN, пробачте про термінологію.

— zzzzBov

6

Ще одна причина, чому CLI може бути кращим - це питання робочого процесу. Багато кадрів керуються за допомогою командного рядка. Використання git через CLI дозволить мені зосередитися на моєму проекті та в цьому каталозі проектів. Наприклад, я можу запустити тест, а потім вирішити здійснити нові зміни, все з того самого інтерфейсу та місця розташування.

— Шигар Кензе
джерело

+1; і чим простішим / доступнішим є його використання, тим більше шансів я використовувати його, коли у відповідний час (tap tap git commit tap tap tap) замість (tap tap start GUI git commit 'кінець тижня')

— Абе

5

Нещодавно мені доводиться справді копатись у Git, щоб мати змогу допомогти з міграцією SVN до Git. І те, що я дізнався, - це те, що інструменти командного рядка Git не є складною частиною для вивчення.

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

Після того, як я зрозумів ці поняття, фактичні заяви командного рядка стали відносно легкими. Це означає, що інтерфейс користувача не дуже допомагає зрозуміти Git (за винятком найпростіших операцій).

— Йоахім Зауер
джерело

3

Насправді поняття gitнастільки прості, що люди не можуть їх зрозуміти - вони шукають щось складніше.

— gahooa

4

Знання CLI стане в нагоді, коли (не, якщо) ви знаходитесь в якомусь середовищі, де ви не можете потрапити в GUI-додаток.

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

— grumpasaurus
джерело

Відповіді на одне речення рідко надають великої цінності. Чи можете ви, будь ласка, розширити відповідь?

— Вальтер

//, Він @grumpasaurus. Що ти очікував, сонник?

— Натан Басанес

2

Однією з причин дізнатися git командного рядка є те, що більшість документації написано для цього середовища. Крім того, якщо ви задасте питання: "як мені зробити X з git?", Ймовірно, відповідь буде містити команди командного рядка.

— Неманя Трифунович
джерело

1

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

Як приклад, ось кілька речей, які я не зрозумів, як це зробити за допомогою програми GitHub (ще одна річ, яку слід зазначити, кожен графічний інтерфейс також має криву навчання).

Звільнення зобов’язань
Push / Pull / Fetch окремо (в GitHub вони згруповані в одну команду "синхронізація", яка може викликати проблеми кілька разів)
Внесення змін до комісій

Нарешті, CLI дозволяють користувачам використовувати ці інструменти під час створення сценаріїв.

— KLee1
джерело

Остання точка для мене досить ключова. Сценарії, інструменти та сервери для побудови рідко мають один із них, який використовує gui для контролю версії доступу до gui. Натомість потрібно використовувати командний рядок.

0

Я не знаю про GitHub для Mac, але додаток Windows виконує лише найпоширеніші завдання - додавати, здійснювати, натискати, тягнути тощо. Більш складні завдання, такі як git merge --no-ff , потрібно виконувати з командного рядка.

Також є випадки з git, коли GUI недоступний, наприклад, коли SSHing на віддалені сервери.

Але в іншому випадку, якщо GUI дає вам все необхідне, то вивчення командного рядка може бути марною витратою часу. У моїй роботі використовується TortoiseSVN в середовищі лише для Windows, і мені не довелося жодного разу торкатися командного рядка SVN.

— іх
джерело

0

Щойно я дізнався один випадок, коли CLI може бути кращим за GUI. Щоб проілюструвати це, я взяв приклад із книги git - управління версіями для всіх.

Коли ви хочете поділитися через інтранет, ви можете використовувати:

Гітоліт-сервер
Загальний каталог спільних ресурсів із голими сховищами

Подивіться на кроки створення голого репо.

Створення голого сховища в режимі CLI

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

Створення голого сховища в режимі GUI

Створення голого клону з уже наявного сховища за допомогою GUI - це простий процес. Все, що вам потрібно зробити:

Скопіюйте каталог .git із наявного сховища та вставте його з файлом different_name.git (незалежно від того, яке ім’я ви хочете дати новому голому сховищу) поза сховищем. У нашому випадку у нас є не голе репо, що називається Workbench на C: \ Users \ raviepic3 \ Desktop \, в якому у нас є content.docx. А тепер я хочу створити новий голий сховище з цього за допомогою GUI. Я скопіюю C: \ Users \ raviepic3 \ Desktop \ Workbench.git і вставлю його як C: \ generic_share \ Bare_Workbench.git.
Відкрийте config fileвнутрішній Bare_Workbench.git за допомогою текстового редактора і знайдіть рядок, який говорить bare = falseі замініть рядок false на істинний.
Збережіть і вийдіть.

У графічному інтерфейсі потрібно зробити стільки кліків і запам'ятати, який файл потрібно редагувати. У CLI одна проста команда робить це все для вас.

— Сід Сміт
джерело