Comments 93
Если выбирать консольные клиенты для git, то я предпочту magit.
Скажите, в чем его плюсы? Только начинаю работать с git и хочется знать.
1) псевдотерминальный интерфейс с читабельным представлением веток
2) поддерживает все воркфлоу
3) удобно структурированные действия. Работа реализована в форме диалога — сначала ты запрашиваешь основное действие, потом magit просит тебя уточнить параметры.
4) очень просто коммитить один файл кусочно. Просто выделяешь текст, который хочешь закоммитить и коммитишь только его.
5) в качестве вишенки на торте — автосейв в git. При этом создаётся отдельный индекс, не связанный ни с какой веткой, чтобы не засирать их.
2) поддерживает все воркфлоу
3) удобно структурированные действия. Работа реализована в форме диалога — сначала ты запрашиваешь основное действие, потом magit просит тебя уточнить параметры.
4) очень просто коммитить один файл кусочно. Просто выделяешь текст, который хочешь закоммитить и коммитишь только его.
5) в качестве вишенки на торте — автосейв в git. При этом создаётся отдельный индекс, не связанный ни с какой веткой, чтобы не засирать их.
К слову о консольных клиентах, есть прекрасный stand-alone клиент tig. Управление stashing'ом и интерактивное индексирование присутствует, ну и еще много всяких плюшек есть)
Я предпочитаю TortoiseHg, правда он не совсем консольный, скорее уже графический. Но очень удобен для новичков
Также пользуюсь им иногда. Еще очень удобен встроенный графический интерфейс Git/Github в PhpStorm / WebStorm. Также, в случае глюков Git, неудачных merge и прочего, изменения можно восстановить с помощью встроенного в PhpStorm / WebStorm дополнительного локального контроля версий (Local history).
Может вы имели в виду tortoisegit? TortoiseHg применяется только для Mercurial
Magit только для Emacs.
не понял, в чём «научный подход» заключается? gl — переключайся между задачами чаще, не концентрируйся и отвлекайся постоянно в 50 веток! Забей на фикс конфликтов, брось и иди делай другую задачу, вперёд)
Мне кажется, что интеграция Gitd семейство IDE от JetBrains уже имеет подход гораздо ближе к Gitless. Все эти staging/stashing и правда весьма сложно понять изначально.
Постоянно пользуюсь функцией stashing (Stash / Unstash) в JetBrains PhpStorm, когда нужно срочно переключить ветку. Не совсем понимаю, что вы имеете в виду под 'ближе к Gitless', но вроде бы там вообще нет stashing, а в PhpStorm без этой функции было бы довольно проблематично работать с git проектом.
Команды git checkout и git reset делают всё-таки разные вещи.
То, что предлагается делать при помощи git reset --hard можно сделать и при помощи git checkout -f (git clean -xfd в случае необходимости).
Для команды git reset --hard выбран почему-то один из частных случаев использования, который совпадает (или почти совпадает) с git checkout -f. Кроме того, команда не предназначена и никогда не используется для манипуляции с файлами, по крайней мере в таком режиме (soft/hard/mixed).
То, что предлагается делать при помощи git reset --hard можно сделать и при помощи git checkout -f (git clean -xfd в случае необходимости).
Для команды git reset --hard выбран почему-то один из частных случаев использования, который совпадает (или почти совпадает) с git checkout -f. Кроме того, команда не предназначена и никогда не используется для манипуляции с файлами, по крайней мере в таком режиме (soft/hard/mixed).
А почему сделано в МТИ я так и не понял
В документации описано следующее: как создавать репозиторий, сохранять изменения; как работать с ветками; как пользоваться тэгами, работать с удаленными репозиториями.
Зачем всё это, когда давно есть графические оболочки. Для нубов они обеспечивают простое освоение, для продвинутых пользователей сохраняют широкие возможности?
Сколько ни пробовал различных графических клиентов, ничего нормального не нашел. Они все были ужасны. Гит – такая штука, для которой трудно сделать столь же гибкий интерфейс, как тот, что дает командная строка.
Сейчас SourceTree приблизился по функциональности к TortoiseHg и избавился от жёстких багов, которыми грешил пару лет назад. Использую уже с полгода — доволен, хотя раньше тоже — только командная строка.
Я вообще считаю, что минимальный функционал по работе с Git должен присутствовать в IDE — программист должен по минимуму отвлекаться при рутинной работе (add/delete/commit/branch).
Про SourceTree согласен, для меня он оказался наиболее приятным клиентом. Приятно также то, что он не является надстройкой консольного гита, а stand-alone клиентом.
Про SourceTree согласен, для меня он оказался наиболее приятным клиентом. Приятно также то, что он не является надстройкой консольного гита, а stand-alone клиентом.
Сделать гибкий интерфейс поддерживающий все функции конечно сложно, но приличные клиенты имеют возможность работы с командной строкой. Они автоматизируют применение наиболее простых и частых операций, а специфические команды, которыми обычно пользуешься крайне редко, вполне можно вводить ручками.
Лично я поступаю именно таким образом. Приходится вести параллельно много проектов, время от времени возвращаться к старым чтобы что-то исправить. Вспоминать названия, держать всё в голове для меня просто пытка.
Лично я поступаю именно таким образом. Приходится вести параллельно много проектов, время от времени возвращаться к старым чтобы что-то исправить. Вспоминать названия, держать всё в голове для меня просто пытка.
У нас в команде у любителей графических клиентов прижился gitKraken — вполне симпатичная штука.
А зачем графические оболочки, когда есть консоль? Для нубов обеспечивает дополнительный опыт работы с консолью, тем самым повышает скорость их обучения, для продвинутых пользователей сохраняет возможность работы в одном интерфейсе, нет нужды в излишнем мышко-кликинге.
Во первых не уверен что консоль быстрее, ну скажем не для всех это быстрее и удобнее.
Во вторых начинающих эти консоли просто пугают.
Система контроля версий полезна не только для суперпродвинутых профи. Поэтому тут я за политику тысячи цветов. Пусть каждый пользуется тем, чем ему удобнее.
В моих условиях, которые я описал выше с окном работать удобнее.
Линуксоидам и тем кто работает с ограниченным количеством проектов консоль может быть удобнее, не буду спорить.
Во вторых начинающих эти консоли просто пугают.
Система контроля версий полезна не только для суперпродвинутых профи. Поэтому тут я за политику тысячи цветов. Пусть каждый пользуется тем, чем ему удобнее.
В моих условиях, которые я описал выше с окном работать удобнее.
Линуксоидам и тем кто работает с ограниченным количеством проектов консоль может быть удобнее, не буду спорить.
Если тебя пугает консоль, даже не думай начинать заниматься программированием. Я серьёзно.
Не консолью единой, безусловно гуи имеет право на существование, каждому своё, но вот что консоль именно пугает — не аргумент в данном случае. Не нравиться может, пугать — вон отсюда и не оборачивайся.
Не консолью единой, безусловно гуи имеет право на существование, каждому своё, но вот что консоль именно пугает — не аргумент в данном случае. Не нравиться может, пугать — вон отсюда и не оборачивайся.
Спасибо за ценный совет, но во первых я не из пугливых, во вторых не пугает, в третьих он запоздал поскольку уже много лет зарабатываю себе этим на жизнь.
Вот только я как-то упустил момент когда мы вовремя дискуссии в этой ветке успели перейти на ты.
Вот только я как-то упустил момент когда мы вовремя дискуссии в этой ветке успели перейти на ты.
О-го-го, какой баттхёрт. Хотя, возможно, действительно непонятно. Нет, я с вами на ты не переходил. Вы неправильно поняли.
Вы сказали, что каких-то там новичков пугает, и это моё обращение было к ним. И вот оно было на ты.
И, повторю, я не говорю, что каждый программист должен любить консоль. Но иметь навыки работы с ней, вроде как прокрутка, редактирование командной строки (в том числе обращение к ранее выполненным командам), перенаправление вывода — обязан.
Вы сказали, что каких-то там новичков пугает, и это моё обращение было к ним. И вот оно было на ты.
И, повторю, я не говорю, что каждый программист должен любить консоль. Но иметь навыки работы с ней, вроде как прокрутка, редактирование командной строки (в том числе обращение к ранее выполненным командам), перенаправление вывода — обязан.
Я успел за свою жизнь повидать как немало отставших от жизни лузеров, которые любили пользоваться консоль, так и хороших в своей области программистов которые пользовались ей в случае крайней необходимости.
Более чем странного подхода к разделению людей на программистов и не программистов в зависимости от влюблённости с консоль я не встречал.
Более чем странного подхода к разделению людей на программистов и не программистов в зависимости от влюблённости с консоль я не встречал.
Полностью согласен. В 99.9% случаев для операций с репозиторием использую графический клиент (SmartGit). В остальных 0.1% случаев гуглю "how to X in git". С удивлением смотрю, как бородатые дядьки в консоли по 30 секунд делают то, что я бы сделал в графическом клиенте за 3 секунды. С ещё большим удивлением смотрю как некоторые джуниоры пытаются пользоваться консолью, потому что "круто", "кроссплатформенно" и "не ограничивает возможности".
Некоторые вещи в графическом виде делать действительно проще, например, просмотр дерева файлов с индикацией статуса каждого файла вместо спама консольных команд, различные операции с файлами типа переноса ветки из одного места в другое.
Думаю, это исключительно вопрос холивара «IDE против консоли». И те, и другие чувствуют себя вполне комфортно: нормальные IDE имеют встроенные функции систем контроля версий, а сторонники дзена используют плагины для vim, чтобы не переключаться в консоль лишний раз.
Разобраться с командной строкой намного проще и быстрее, чем угадать то, в какую дыру очередной формошлёп засунул нужную функцию и реализована ли поддержка этой функции вообще или же всё время ушло на впиливание анимации, эмодзи и нескучных обоев.
Ну уж нет, иной раз быстрее полазить по менюшкам, чем угадать, как очередной очкарик назвал эту функцию и как тут вообще получить справку по имеющимся функциям. A то у одних --help и --longhelp, другие не умеют --help — только -h и всё тут, третьи по -h/--help выдают невнятный бриф и посылают в man, четвёртые в info — поубивал бы таких, у пятых вообще документация только на сайте онлайн, а у шестых — только оффлайн, в pdf, и не покрывает функционал полностью — копайся в сырцах, это же тебе надо.
Практически все консольные утилиты при запуске с ошибочными параметрами указывают ключ, по которому можно получить справку. Я, во всяком случае, с ходу исключений вспомнить не могу.
Так что запускаем утилиту с ключом --help и получаем либо справку, либо имя параметра для получения справки. Угадывать не нужно.
Так что запускаем утилиту с ключом --help и получаем либо справку, либо имя параметра для получения справки. Угадывать не нужно.
Знаете что меня убивает в консольных утилитах? Чтобы ими пользоваться нужно постоянно иметь графический интерфейс в виде браузера с быстрым интернетом и сотней вкладок, где можно прочитать как что-то сделать в этой самой консоли. Да, если ты там делаешь одно и то же — можно и запомнить, но куда чаще приходится делать совершенно разные вещи единственный раз в жизни. Вот и выходит что пользуешься графическим интерфейсом (Google->Stackoverflow->мануалы) а потом руками переносишь это в консоль. Не самый эффективный метод.
Готов подписаться под каждым словом.
Обычно есть локальная справка. У привычки лезть за любой справкой в сеть есть и негативный эффект, особенно он наблюдается среди *nix пользователей в последние годы — люди вообще разучиваются пользоваться локальными man страницами и программами info/man в принципе.
> он наблюдается среди *nix пользователей в последние годы
При этом надо не забывать, что программист — тоже пользователь. Сегодня человек как пользователь не читает маны, а завтра он как программист не пишет их. Например, вместо этого снимает видео урок и выкладывает на ютуб.
При этом надо не забывать, что программист — тоже пользователь. Сегодня человек как пользователь не читает маны, а завтра он как программист не пишет их. Например, вместо этого снимает видео урок и выкладывает на ютуб.
обычно да, но:
1. листать ман в консоли и удобно браузить по десятку вкладок — две большие разницы.
2. чтобы почитать локальную справку нужно хотя бы знать какой утилитой пользоваться а затем её установить, если её нет. Чтобы понять что и как устанавливать — нужен браузер.
3. некоторые утилиты имеют гигантское количество параметров и опций, и вам возможно придется просмотреть их все, вместо того чтобы найти в браузере готовое решение своей задачи
1. листать ман в консоли и удобно браузить по десятку вкладок — две большие разницы.
2. чтобы почитать локальную справку нужно хотя бы знать какой утилитой пользоваться а затем её установить, если её нет. Чтобы понять что и как устанавливать — нужен браузер.
3. некоторые утилиты имеют гигантское количество параметров и опций, и вам возможно придется просмотреть их все, вместо того чтобы найти в браузере готовое решение своей задачи
1. Очень удобно, у меня часто два окна консоли рядом: одно с маном, в другом команду пишу. Какой браузер?
2. Чо? А чтобы найти подходящую графическую утилиту — браузер не нужен? А уж установить — ну хватит, apt-get install или emerge или yum и всё. Кстати, так вообще и утилиту поискать можно, часто даже находится, браузер оказывается не нужен.
3. Команды с гигантским числом параметров обычно рассчитаны на какие-то менеджеры для автоматизированного запуска. Например, gcc имеет очень дофига параметров, но вообще обычно руками его не вызывают, а используют make.
2. Чо? А чтобы найти подходящую графическую утилиту — браузер не нужен? А уж установить — ну хватит, apt-get install или emerge или yum и всё. Кстати, так вообще и утилиту поискать можно, часто даже находится, браузер оказывается не нужен.
3. Команды с гигантским числом параметров обычно рассчитаны на какие-то менеджеры для автоматизированного запуска. Например, gcc имеет очень дофига параметров, но вообще обычно руками его не вызывают, а используют make.
2. Нужен конечно, это и есть использование графического интерфейса, которое я предпочитаю консоли.
Кстати, так вообще и утилиту поискать можно, часто даже находится, браузер оказывается не нужен.это как?
С таким же успехом можно иметь перед вместо «мана» графический интерфейс.
К тому же я например программист для встраиваемых систем. у меня перед глазами часто кроме IDE для программирования микроконтроллеров ещё мануал по MCU, пара мануалов по чипам, работающим под управлением микроконтроллера, и AltiumDesigher Мне только ещё консоли с мануалом не хватает. У меня и так на столе три монитора стоит — на третий виртуальный осциллограф выведен.
К тому же я например программист для встраиваемых систем. у меня перед глазами часто кроме IDE для программирования микроконтроллеров ещё мануал по MCU, пара мануалов по чипам, работающим под управлением микроконтроллера, и AltiumDesigher Мне только ещё консоли с мануалом не хватает. У меня и так на столе три монитора стоит — на третий виртуальный осциллограф выведен.
> 1. листать ман в консоли и удобно браузить по десятку вкладок — две большие разницы.
Здесь не всё так однозначно… В сети лежит огромное количество информации, в том числе разжёванных howto и т.д., а веб-поиск очень интерактивен и прост («ок гугл, git stash unmerged files»), но на этом преимущества веба кончаются.
groff (aka «man-страница») и info — сто лет существующие форматы, давно ставшие стандартом документации в юниксах, я могу смотреть их на машине без подключения к сети, в какой захочу программе (man и info это далеко не единственные программы просмотра man/info, я например пользуюсь другим просмотрщиком), могу индексировать их, производить сложный поиск, производить поиск только в открытых файлах, делать что угодно, а ещё в юниксы традиционно кладут кучу локальных howto и примеров в довесок к man-страницам (собственно, веб-поиск обычно и приводит просто-напросто на выложенную в сеть man- или howto-страницу).
Справка в виде веб-страницы в сети: требует наличия интернет-подключения и запуска одного из самых тяжеловесных приложений — веб-браузера, а возможности навигации/поиска ограничены тем, что заложено в веб-страницу, браузер и поисковик. Для демонстрации возможностей своего браузера в этой области попробуйте решить задачу «из 30 открытых вкладок быстро найти те, заголовок или содержимое которых содержат слово git».
> 2. чтобы почитать локальную справку нужно хотя бы знать какой утилитой пользоваться а затем её установить, если её нет. Чтобы понять что и как устанавливать — нужен браузер.
Если речь идёт именно о «консольных» форматах, info и встроенной помощи, то нагуглить, что man-страницы открываются утилитой man, info-страницы открываются утилитой info, а консольный вывод смотрится less и т.д., достаточно один раз в жизни.=))) То же самое с изучением этих утилит: требуется потратить некоторое время, но это действие, выполняемое 1 раз в жизни. Эти утилиты как правило есть в системе и ничего ставить не надо.
> 3. некоторые утилиты имеют гигантское количество параметров и опций, и вам возможно придется просмотреть их все, вместо того чтобы найти в браузере готовое решение своей задачи
Для этого есть поиск по локальной справке, в том числе нечёткий.
Здесь не всё так однозначно… В сети лежит огромное количество информации, в том числе разжёванных howto и т.д., а веб-поиск очень интерактивен и прост («ок гугл, git stash unmerged files»), но на этом преимущества веба кончаются.
groff (aka «man-страница») и info — сто лет существующие форматы, давно ставшие стандартом документации в юниксах, я могу смотреть их на машине без подключения к сети, в какой захочу программе (man и info это далеко не единственные программы просмотра man/info, я например пользуюсь другим просмотрщиком), могу индексировать их, производить сложный поиск, производить поиск только в открытых файлах, делать что угодно, а ещё в юниксы традиционно кладут кучу локальных howto и примеров в довесок к man-страницам (собственно, веб-поиск обычно и приводит просто-напросто на выложенную в сеть man- или howto-страницу).
Справка в виде веб-страницы в сети: требует наличия интернет-подключения и запуска одного из самых тяжеловесных приложений — веб-браузера, а возможности навигации/поиска ограничены тем, что заложено в веб-страницу, браузер и поисковик. Для демонстрации возможностей своего браузера в этой области попробуйте решить задачу «из 30 открытых вкладок быстро найти те, заголовок или содержимое которых содержат слово git».
> 2. чтобы почитать локальную справку нужно хотя бы знать какой утилитой пользоваться а затем её установить, если её нет. Чтобы понять что и как устанавливать — нужен браузер.
Если речь идёт именно о «консольных» форматах, info и встроенной помощи, то нагуглить, что man-страницы открываются утилитой man, info-страницы открываются утилитой info, а консольный вывод смотрится less и т.д., достаточно один раз в жизни.=))) То же самое с изучением этих утилит: требуется потратить некоторое время, но это действие, выполняемое 1 раз в жизни. Эти утилиты как правило есть в системе и ничего ставить не надо.
> 3. некоторые утилиты имеют гигантское количество параметров и опций, и вам возможно придется просмотреть их все, вместо того чтобы найти в браузере готовое решение своей задачи
Для этого есть поиск по локальной справке, в том числе нечёткий.
Предполагаю, это потому, что нет действительно хорошей документации по первоначальной работе с Linux. Небольшой, до 100 страниц, где бы описывались возможности стандартных утилит, их предназначение, какие-то широко используемые технологии и подсистемы (DKMS, systemd).
Вот, например, для тех, кто не любит читать маны в консоли, есть опция
cc: merlin-vrn, Cheater
Вот, например, для тех, кто не любит читать маны в консоли, есть опция
-H, которая сгенерирует HTML и откроет его в браузере.man -Hfirefox 2 openman -K O_DSYNCcc: merlin-vrn, Cheater
Вот, например, для тех, кто не любит читать маны в консоли, есть опция -H, которая сгенерирует HTML и откроет его в браузере.
И вот, что она выдала:
man -Hfirefox 2 open man: command exited with status 3: /usr/bin/zsoelim | /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl | groff -mandoc -Thtml
Никак. И не нужно. Хочешь использовать все возможности — прочитай весь ман. Потом решай, что из этого тебе нужно.
> Как об этом узнать, не читая man man целенаправленно?
Никак =) Вроде бы такого канонического документа «по общим вопросам» нет.
Самое близкое, что я знаю, — это проект tldp.org. Но, как правило, по конкретной утилите или системному компоненту в интернете всегда можно быстро найти хороший вводный курс. Я сам грешен тем, что вместо мануалов порой гуглю быстрые howto от сторонних авторов.
Никак =) Вроде бы такого канонического документа «по общим вопросам» нет.
Самое близкое, что я знаю, — это проект tldp.org. Но, как правило, по конкретной утилите или системному компоненту в интернете всегда можно быстро найти хороший вводный курс. Я сам грешен тем, что вместо мануалов порой гуглю быстрые howto от сторонних авторов.
куда чаще приходится делать совершенно разные вещи единственный раз в жизни.Странно, мне, наоборот, куда чаще приходится делать весьма небольшое подмножество вещей.
В случае с git это init / add / commit / push / pull / rebase / merge / diff / difftool / mergetool / reset / cherry-pick.
Синтаксис запоминается довольно быстро, в крайнем случае есть локальная справка.
Это нужно, когда вы работаете в одной ветке и в ней все в беспорядочном состоянии, а нужно срочно переключиться на другую ветку.
Вот никогда этого не понимал. Сделай коммит локальный, можно --amend прикрутить. Не хочешь забыть изменения — сделать коммит а потом резет, изменения снова станут показываться.
Куда хуже когда изменения из стека внезапно применяются не туда. Без всяких мержей.
Вот никогда этого не понимал. Сделай коммит локальный, можно --amend прикрутить. Не хочешь забыть изменения — сделать коммит а потом резет, изменения снова станут показываться.
Куда хуже когда изменения из стека внезапно применяются не туда. Без всяких мержей.
Также обратный случай, иногда начинаю фиксить в неправильной ветке. С git checkout легко просто переключиться на правильную, все изменения останутся на месте. Тут Gitless поступит как проще для новичка, но при этом лишаешься гибкости.
Это нужно, когда вы работаете в одной ветке и в ней все в беспорядочном состоянии, а нужно срочно переключиться на другую ветку.А почему бы не вытащить исходники другой ветки в отдельную папку и в ней спокойно работать?
[irony]Они сделали из гита меркуриал![/irony]
Ну, вообще, я не знаю. Когда перешел с меркуриала на гит, первые несколько дней, конечно, плевался и чертыхался, но потом и сам не заметил, как привык. Просто надо понимать, как гит устроен — тогда и с командами проблем не будет. Ну, да, гит достаточно «низкоуровневый», но в этом есть и плюсы.
Ну, вообще, я не знаю. Когда перешел с меркуриала на гит, первые несколько дней, конечно, плевался и чертыхался, но потом и сам не заметил, как привык. Просто надо понимать, как гит устроен — тогда и с командами проблем не будет. Ну, да, гит достаточно «низкоуровневый», но в этом есть и плюсы.
На примере Gitless становится очевидно, что подход упрощения возможно применять и к другим сложным системам. Например, Google Inbox и Dropbox.
Нет, это как-то совсем не очевидно. И что не так с инбоксом?
ps
Если вывод не придумывается, можно и без него.
> на научном подходе
А где наука? Чем это лучше git + alias? Или опять сидеть алиасы перепиливать, но уже под Gitless? Скажите честно, учоные, это чей-то бакалавр «на отвались»?
А где наука? Чем это лучше git + alias? Или опять сидеть алиасы перепиливать, но уже под Gitless? Скажите честно, учоные, это чей-то бакалавр «на отвались»?
Все ходят вокруг этого git с такими умными лицами, будто это нечто гениальное! Эй, люди, опомнитесь — это писал тот же троечник, что наковырял Линукс! Причём написал git ДЛЯ СЕБЯ (ну и for fun, конечно! :) ). С чего вы вдруг решили, что ЭТИМ можно пользоваться для серьёзных продуктов?
В мире тысячи команд, в каждой своя культура и способы работать сообща. То, что один очкарик мержит себе в линукс патчи, ещё не делает софт УДОБНЫМ и непротиворечивым. Собственно, потому Mercurial и применяется не менее широко, что сделан по-человечески.
В мире тысячи команд, в каждой своя культура и способы работать сообща. То, что один очкарик мержит себе в линукс патчи, ещё не делает софт УДОБНЫМ и непротиворечивым. Собственно, потому Mercurial и применяется не менее широко, что сделан по-человечески.
Git задумывался как «тупой трекер контента», и реализовывался соответственно. Но внезапно стал фактически отраслевым стандартом, обойдя всех конкурентов (можете погуглить современные рейтинги систем контроля версий — раз, два). И это при достаточно невменяемом интерфейсе, от которого плюются все новички.
Вот, что бывает когда гуманитарий берется за рассуждения над сугубо техническими деталями…
100% вопросов и недостатков git обсуждаемых выше решается надстройками — gui интерфейсами вроде tortoisegit и веб версиями вроде github.
Остальное — велосипеды с квадратными колесами, на 99% копирующими оригинал(в том числе логику\исходные коды) с ничтожными изменениями, в надежде «выехать» на этом.
100% вопросов и недостатков git обсуждаемых выше решается надстройками — gui интерфейсами вроде tortoisegit и веб версиями вроде github.
Остальное — велосипеды с квадратными колесами, на 99% копирующими оригинал(в том числе логику\исходные коды) с ничтожными изменениями, в надежде «выехать» на этом.
Ну а родовую травму гита с коммитами не привязанными к веткам они побороли? А то все эти костыли с добавлением имени ветки в сообщение коммита, через хук порядком надоели.
На какие только извращения люди не идут ради того, чтобы не читать документацию.
Странно, что умолчали о замене интерактивным командам git, типа git add -i, git rebase -i.
Я вообще без них workflow в git не представляю.
> git checkout < file > // отбросить все изменения в одном файле с последней выгрузки в систему
> git reset --hard // отбросить все изменения во всех файлах с последней выгрузки в систему
> Две разные команды для одной функции с одной разницей в том, что одна для одиночного файла, а вторая — для множества файлов.
Команда для отбрасывания изменений во многих файлах или в целом каталоге проста и логична и ничем не отличается от отбрасывания изменений в одном файле: git checkout file1 file2 dir3 dir4… То, что другие команды (например git reset --hard или git checkout -f) способны произвести тот же эффект, не значит, что «в гит изменение в одном файле откатывается одной командой, а изменение во всех файлах — другой!11». В общем, кто-то ниасилил git checkout --help.
> git reset --hard // отбросить все изменения во всех файлах с последней выгрузки в систему
> Две разные команды для одной функции с одной разницей в том, что одна для одиночного файла, а вторая — для множества файлов.
Команда для отбрасывания изменений во многих файлах или в целом каталоге проста и логична и ничем не отличается от отбрасывания изменений в одном файле: git checkout file1 file2 dir3 dir4… То, что другие команды (например git reset --hard или git checkout -f) способны произвести тот же эффект, не значит, что «в гит изменение в одном файле откатывается одной командой, а изменение во всех файлах — другой!11». В общем, кто-то ниасилил git checkout --help.
Разработчики, которые пользуются системой, ее или любят, или ругают за сложный интерфейс и баги.
За какие это баги ругают git?
Я думаю имелось ввиду, что некоторые операции в git заведомо опасны и могут необратимо сломать локальный индекс. Это сделано не зря, поскольку для больших проектов (в первую очередь ядро Линукс) это необходимо, но для новчиков это минное поле: нашел инструкцию в интернете, ошибся, клонируйся заново. На StackOverflow это распространненый класс вопросов по git.
Из личного опыта (под Windows):
- В какой-то версии, ещё в 2012 году, вместо системной кодировки (cp1251 которая) имён файлов стала использоваться UTF-8. Репозиторий пришлось конвертировать, благо на тот момент мы git серьёзно не использовали (в hg подобная проблема, кажется, и позже была, но только при переходе linux<->windows).
- Где-то год назад git перестал адекватно воспринимать старые DOS-овские имена наподобие ABC~1.TXT (закрыли какую-то уязвимость). Были проблемы с добавлением/удалением/checkout-ом этих файлов, то есть файл был отмечен как изменённый, и ничего с этим поделать нельзя. Переименовать тоже просто так нельзя.
- Регистрозависимость имён файлов. "Любимый" баг. Git на Windows и сегодня не подозревает, что ABC и abc — одно и то же. Если где-то в диффе изменений встречается переименование ABC->abc, git при слиянии этих изменений в другую ветку не может сделать это переименование, и в дереве файлов появляются оба. А затем — проблемы с checkout-ом и с удалением "лишних" файлов.
Не уверен, что ругают именно за эти баги, но проблемы бывают.
Еще бывает, когда есть сразу 2 файла ABC и abc. Висит один измененный файл, через stash не убирается, ни merge ни rebase не сделать. Исправить можно, если отключить в реестре флаг obcaseinsensitive, примонтировать диск в cygwin с опцией posix=1, и сделать git reset --hard в git, установленном из репозиториев cygwin.
Проблемы бывают у всех, но "ругают за баги" подразумевает, что программа глючная и пользователи постоянно сталкиваются с проблемами. В случае гита, это не так.
Ну да, ломать — не строить. Для отдельного файла можно отдельную ветку сделать. Может быть я в чём-то не прав, но по-моему самого базового функционала git уже за глаза, если аккуратно его использовать. А дезть в дебри — усложнять себе работу.
Это MIT, эти парни не могут ошибаться! Если NIH разработка имеет солидный бренд, то это наверняка очень крутая штука.
На примере Gitless становится очевидно, что подход упрощения возможно применять и к другим сложным системам. Например, Google Inbox и Dropbox.
Что сложного в этих системах?
Промптом переводил?
1) А почему не указано что перевод?
Вот, честно, обсмотрел везде со всех сторон пост и не нашёл плашки перевода. Опять замечательные улучшения интерфейса от ТМ или её и вправду нет?
2) Пока читал, то и дело возникал баттхёрт от непонимания автором (кем бы он ни был) ни специфики работы vcs, ни конкретно git'а, ни даже что какие команды делают.
ИМХО, такое чтиво вредно для здоровья.
Sign up to leave a comment.
Сделано в МТИ: система контроля версий Gitless