Комментарии 93
2) поддерживает все воркфлоу
3) удобно структурированные действия. Работа реализована в форме диалога — сначала ты запрашиваешь основное действие, потом magit просит тебя уточнить параметры.
4) очень просто коммитить один файл кусочно. Просто выделяешь текст, который хочешь закоммитить и коммитишь только его.
5) в качестве вишенки на торте — автосейв в git. При этом создаётся отдельный индекс, не связанный ни с какой веткой, чтобы не засирать их.
Мне кажется, что интеграция Gitd семейство IDE от JetBrains уже имеет подход гораздо ближе к Gitless. Все эти staging/stashing и правда весьма сложно понять изначально.
То, что предлагается делать при помощи git reset --hard можно сделать и при помощи git checkout -f (git clean -xfd в случае необходимости).
Для команды git reset --hard выбран почему-то один из частных случаев использования, который совпадает (или почти совпадает) с git checkout -f. Кроме того, команда не предназначена и никогда не используется для манипуляции с файлами, по крайней мере в таком режиме (soft/hard/mixed).
В документации описано следующее: как создавать репозиторий, сохранять изменения; как работать с ветками; как пользоваться тэгами, работать с удаленными репозиториями.
Зачем всё это, когда давно есть графические оболочки. Для нубов они обеспечивают простое освоение, для продвинутых пользователей сохраняют широкие возможности?
Про SourceTree согласен, для меня он оказался наиболее приятным клиентом. Приятно также то, что он не является надстройкой консольного гита, а stand-alone клиентом.
Лично я поступаю именно таким образом. Приходится вести параллельно много проектов, время от времени возвращаться к старым чтобы что-то исправить. Вспоминать названия, держать всё в голове для меня просто пытка.
Во вторых начинающих эти консоли просто пугают.
Система контроля версий полезна не только для суперпродвинутых профи. Поэтому тут я за политику тысячи цветов. Пусть каждый пользуется тем, чем ему удобнее.
В моих условиях, которые я описал выше с окном работать удобнее.
Линуксоидам и тем кто работает с ограниченным количеством проектов консоль может быть удобнее, не буду спорить.
Не консолью единой, безусловно гуи имеет право на существование, каждому своё, но вот что консоль именно пугает — не аргумент в данном случае. Не нравиться может, пугать — вон отсюда и не оборачивайся.
Вот только я как-то упустил момент когда мы вовремя дискуссии в этой ветке успели перейти на ты.
Вы сказали, что каких-то там новичков пугает, и это моё обращение было к ним. И вот оно было на ты.
И, повторю, я не говорю, что каждый программист должен любить консоль. Но иметь навыки работы с ней, вроде как прокрутка, редактирование командной строки (в том числе обращение к ранее выполненным командам), перенаправление вывода — обязан.
Более чем странного подхода к разделению людей на программистов и не программистов в зависимости от влюблённости с консоль я не встречал.
Полностью согласен. В 99.9% случаев для операций с репозиторием использую графический клиент (SmartGit). В остальных 0.1% случаев гуглю "how to X in git". С удивлением смотрю, как бородатые дядьки в консоли по 30 секунд делают то, что я бы сделал в графическом клиенте за 3 секунды. С ещё большим удивлением смотрю как некоторые джуниоры пытаются пользоваться консолью, потому что "круто", "кроссплатформенно" и "не ограничивает возможности".
Так что запускаем утилиту с ключом --help и получаем либо справку, либо имя параметра для получения справки. Угадывать не нужно.
При этом надо не забывать, что программист — тоже пользователь. Сегодня человек как пользователь не читает маны, а завтра он как программист не пишет их. Например, вместо этого снимает видео урок и выкладывает на ютуб.
1. листать ман в консоли и удобно браузить по десятку вкладок — две большие разницы.
2. чтобы почитать локальную справку нужно хотя бы знать какой утилитой пользоваться а затем её установить, если её нет. Чтобы понять что и как устанавливать — нужен браузер.
3. некоторые утилиты имеют гигантское количество параметров и опций, и вам возможно придется просмотреть их все, вместо того чтобы найти в браузере готовое решение своей задачи
2. Чо? А чтобы найти подходящую графическую утилиту — браузер не нужен? А уж установить — ну хватит, apt-get install или emerge или yum и всё. Кстати, так вообще и утилиту поискать можно, часто даже находится, браузер оказывается не нужен.
3. Команды с гигантским числом параметров обычно рассчитаны на какие-то менеджеры для автоматизированного запуска. Например, gcc имеет очень дофига параметров, но вообще обычно руками его не вызывают, а используют make.
Кстати, так вообще и утилиту поискать можно, часто даже находится, браузер оказывается не нужен.это как?
К тому же я например программист для встраиваемых систем. у меня перед глазами часто кроме IDE для программирования микроконтроллеров ещё мануал по MCU, пара мануалов по чипам, работающим под управлением микроконтроллера, и AltiumDesigher Мне только ещё консоли с мануалом не хватает. У меня и так на столе три монитора стоит — на третий виртуальный осциллограф выведен.
Здесь не всё так однозначно… В сети лежит огромное количество информации, в том числе разжёванных 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. некоторые утилиты имеют гигантское количество параметров и опций, и вам возможно придется просмотреть их все, вместо того чтобы найти в браузере готовое решение своей задачи
Для этого есть поиск по локальной справке, в том числе нечёткий.
Вот, например, для тех, кто не любит читать маны в консоли, есть опция
-H
, которая сгенерирует HTML и откроет его в браузере.man -Hfirefox 2 open
Или, например, если у вас есть какая-то объявленная через define константа в C-коде, но вы не знаете, какой заголовочный файл вам подключить, можно выполнить полнотекстовый поиск по man'ам:man -K O_DSYNC
Как об этом узнать, не читая man man целенаправленно?cc: 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
Никак =) Вроде бы такого канонического документа «по общим вопросам» нет.
Самое близкое, что я знаю, — это проект tldp.org. Но, как правило, по конкретной утилите или системному компоненту в интернете всегда можно быстро найти хороший вводный курс. Я сам грешен тем, что вместо мануалов порой гуглю быстрые howto от сторонних авторов.
куда чаще приходится делать совершенно разные вещи единственный раз в жизни.Странно, мне, наоборот, куда чаще приходится делать весьма небольшое подмножество вещей.
В случае с git это init / add / commit / push / pull / rebase / merge / diff / difftool / mergetool / reset / cherry-pick.
Синтаксис запоминается довольно быстро, в крайнем случае есть локальная справка.
Вот никогда этого не понимал. Сделай коммит локальный, можно --amend прикрутить. Не хочешь забыть изменения — сделать коммит а потом резет, изменения снова станут показываться.
Куда хуже когда изменения из стека внезапно применяются не туда. Без всяких мержей.
Также обратный случай, иногда начинаю фиксить в неправильной ветке. С git checkout легко просто переключиться на правильную, все изменения останутся на месте. Тут Gitless поступит как проще для новичка, но при этом лишаешься гибкости.
Это нужно, когда вы работаете в одной ветке и в ней все в беспорядочном состоянии, а нужно срочно переключиться на другую ветку.А почему бы не вытащить исходники другой ветки в отдельную папку и в ней спокойно работать?
Ну, вообще, я не знаю. Когда перешел с меркуриала на гит, первые несколько дней, конечно, плевался и чертыхался, но потом и сам не заметил, как привык. Просто надо понимать, как гит устроен — тогда и с командами проблем не будет. Ну, да, гит достаточно «низкоуровневый», но в этом есть и плюсы.
На примере Gitless становится очевидно, что подход упрощения возможно применять и к другим сложным системам. Например, Google Inbox и Dropbox.
Нет, это как-то совсем не очевидно. И что не так с инбоксом?
Если вывод не придумывается, можно и без него.
А где наука? Чем это лучше git + alias? Или опять сидеть алиасы перепиливать, но уже под Gitless? Скажите честно, учоные, это чей-то бакалавр «на отвались»?
В мире тысячи команд, в каждой своя культура и способы работать сообща. То, что один очкарик мержит себе в линукс патчи, ещё не делает софт УДОБНЫМ и непротиворечивым. Собственно, потому Mercurial и применяется не менее широко, что сделан по-человечески.
100% вопросов и недостатков git обсуждаемых выше решается надстройками — gui интерфейсами вроде tortoisegit и веб версиями вроде github.
Остальное — велосипеды с квадратными колесами, на 99% копирующими оригинал(в том числе логику\исходные коды) с ничтожными изменениями, в надежде «выехать» на этом.
Ну а родовую травму гита с коммитами не привязанными к веткам они побороли? А то все эти костыли с добавлением имени ветки в сообщение коммита, через хук порядком надоели.
Странно, что умолчали о замене интерактивным командам git, типа git add -i
, git rebase -i
.
Я вообще без них workflow в git не представляю.
> git reset --hard // отбросить все изменения во всех файлах с последней выгрузки в систему
> Две разные команды для одной функции с одной разницей в том, что одна для одиночного файла, а вторая — для множества файлов.
Команда для отбрасывания изменений во многих файлах или в целом каталоге проста и логична и ничем не отличается от отбрасывания изменений в одном файле: git checkout file1 file2 dir3 dir4… То, что другие команды (например git reset --hard или git checkout -f) способны произвести тот же эффект, не значит, что «в гит изменение в одном файле откатывается одной командой, а изменение во всех файлах — другой!11». В общем, кто-то ниасилил git checkout --help.
Разработчики, которые пользуются системой, ее или любят, или ругают за сложный интерфейс и баги.
За какие это баги ругают git?
Из личного опыта (под Windows):
- В какой-то версии, ещё в 2012 году, вместо системной кодировки (cp1251 которая) имён файлов стала использоваться UTF-8. Репозиторий пришлось конвертировать, благо на тот момент мы git серьёзно не использовали (в hg подобная проблема, кажется, и позже была, но только при переходе linux<->windows).
- Где-то год назад git перестал адекватно воспринимать старые DOS-овские имена наподобие ABC~1.TXT (закрыли какую-то уязвимость). Были проблемы с добавлением/удалением/checkout-ом этих файлов, то есть файл был отмечен как изменённый, и ничего с этим поделать нельзя. Переименовать тоже просто так нельзя.
- Регистрозависимость имён файлов. "Любимый" баг. Git на Windows и сегодня не подозревает, что ABC и abc — одно и то же. Если где-то в диффе изменений встречается переименование ABC->abc, git при слиянии этих изменений в другую ветку не может сделать это переименование, и в дереве файлов появляются оба. А затем — проблемы с checkout-ом и с удалением "лишних" файлов.
Не уверен, что ругают именно за эти баги, но проблемы бывают.
Проблемы бывают у всех, но "ругают за баги" подразумевает, что программа глючная и пользователи постоянно сталкиваются с проблемами. В случае гита, это не так.
На примере Gitless становится очевидно, что подход упрощения возможно применять и к другим сложным системам. Например, Google Inbox и Dropbox.
Что сложного в этих системах?
1) А почему не указано что перевод?
Вот, честно, обсмотрел везде со всех сторон пост и не нашёл плашки перевода. Опять замечательные улучшения интерфейса от ТМ или её и вправду нет?
2) Пока читал, то и дело возникал баттхёрт от непонимания автором (кем бы он ни был) ни специфики работы vcs, ни конкретно git'а, ни даже что какие команды делают.
ИМХО, такое чтиво вредно для здоровья.
Сделано в МТИ: система контроля версий Gitless