Comments 195
Собственно, моя первая работа началась с изучения этой книги. Потом пару месяцев активно применял полученные знания, периодически в неё подглядывая и все фичи из поста отложились в подкорке.
Но должен заметить что та же Idea сокращает явную работу с гитом до минимума. Коммиты, пуши, ребазы, чекауты, новые ветки, стэши… Да и CVS>Log очень удобен, когда явно видишь все коммиты, их взаимосвязи и изменения в каждом из них. Единственное, чего не хватает — add -p, ну или я ещё не нашёл как оно делается.
Ну вообще отчасти это верно, просто я эти команды набираю в менюшке, выскакивающей по Ctrl+Shift+A, где доступны вообще все действия IDE. Ну и пока вроде всё действует по методу наименьшего удивления, так что угадывать ничего не приходится.
Ну и сохранение пароля жизнь упрощает, хотя оно конечно и в консоли настраивается. В общем-то, главный плюс IDE в том, что не происходит никакого переключения контекста, даже терминал открытым держать не надо.
Соглашусь, но отчасти: в QtC, к примеру, мне удобно:
- делать комиты, в том числе интерактивно выбирая то, что на комит добавить (add -p)
- переключаться между ветками: в QtC используется трюк со stash: он добавляет метку и можно переключиться на другую ветку автоматически скрыв изменения в stash и восстановить их по возвращению на ветку.
Ну и диффы и история, куда без этого.
В командной строке нужно для того-же самого 32 нажатия клавиши.
Не знаю кому 32 нажатия проще чем 3.
Ну вообще говоря еще сообщение коммита нужно на клавиатуре набирать.
Кстати можно выбрать из шаблонов и даже надиктовать, не всё так однозначно.
Проверял неоднократно.
У меня это выглядит таким образом:
Переколючаемся в консоль (Если я в этот момент в IDE от Intellij, то клац по кнопке терминала, если в Vim — то Ctrl-Z). — Одна секунда максимум.
Потом gca и ввод.
Пишем сообщение и выходим. (помимо сообщения тоже секунда максимум)
Так что по времени это будет не дольше чем три клика. Вопрос привычек и удобства.
P.S. Я пытаюсь показать альтернативный сценарий, а не переубедить. Вы же мышкой всё равно продолжите, а я в консоли.
У меня вопрос. У вас вообще скорость набора хотя бы 200-300 символов в минуту есть? Три клика в разных местах экрана это не тройной клик.
А вызов алиаса может быть например 1-2 буквы, таб (автодополнение) и enter, что даже на слух воспринимается как короткая трель.
Use case:
1. Вы что-то там себе в ветке fix-foo делали
2. Потом переключились на dev и продолжили работу.
3. А теперь вас попросили пушнуть ветку fix-foo только под нормальным именем, типа bug/proj-1567-fix-foo
Из консоли это можно сделать одной командой и не будет путаницы в «понимании поведения интерфейса».
В итоге бывает проще выучить 1 инструмент (git cli), чем несколько. Конечно, это не отменяет того, что GUI — удобная штука.
Кстати, пункт 4: пушнуть ветку fix-foo без последнего коммита (потому, что там ерунда) — это всё ещё одна команда.
gi[tab]com[tab]-am "[commit message]"[enter]
gi[tab]pus[tab][enter]
Я насчитал 22 без алиасов.
С алиасами…
,g "[commit message]"[Enter]
6 нажатий
К счастью я не занимаюсь такими глупостями как экономия на клавишах и бессмысленые алиасы.
За то часто приходиться:
1) Фиксировать не все изменения а только часть.
2) Ребейсить коммиты (зачастую — сквошить).
3) Работать не на своей машине c гитом.
По моему опыту чаще пользуються приблудами для git программисты под Win (где нажатие [tab] в сygwin вызивает боль). И в этом нет ничего плохого, но обобщать подобный опыт не стоит.
1 и 2 есть в TortoiseGit. Там вообще удобный интерактивный ребейз. Есть команда «Rebase onto this» для коммита, не надо отдельную ветку создавать.
3 можно и потерпеть, никто не спорит, что основные команды надо знать. Но локальной работы все-таки больше, так что лучше пользоваться тем, что удобнее для нее.
А режим редактирования истории без перенесения есть? Когда возникла такая задача для консоли был написан alias git ri
:
[alias]
ri = "!dash -c 't=\"${1:-master}\"; s=\"${2:-HEAD}\"; mb=\"$(git merge-base \"$t\" \"$s\")\"; if test \"x$mb\" = x ; then o=\"$t\"; else lm=\"$(git log -n1 --merges \"$t..$s\" --pretty=%H)\"; if test \"x$lm\" = x ; then o=\"$mb\"; else o=\"$lm\"; fi; fi; test $# -gt 0 && shift; test $# -gt 0 && shift; git rebase --interactive \"$o\" \"$@\"'"
Он длинный, но позволяет работать как hg histedit
.
Проблемы, решаемые таким вариантом:
- Выполнив
git ri
вы не получите внезапно неработающие изменения, потому что вmaster
немного поменяли API чего‐то, использующегося в новом коде, а слияния от такого конфликты обычно не ловит. - Во время rebase легко словить серию конфликтов: коммит 1 конфликтует с новыми измемениями в master, коммиты 2, 3, … модифицируют код из первого, и, соответственно, попытка их применения вызывает конфликты, если первый был изменён в ходе решения конфликта. При merge конфликты вы решаете только один раз, но…
- … иногда хочется взять и исправить несколько опечаток где‐то в середине ветки, замеченных ближе к концу во время тестирования, но не хочется при этом получать 1 или 2 и вообще делать merge до получения первой рабочей версии.
Если забыть про merge, то мой alias можно заменить на такой вариант: при начальном создании ветки feature создавать две: feature и feature-base (вторая соответствует master во время создания ветки). Потом вносить изменения в feature, rebase делать на feature-base, а не на master, а feature-base не двигать никуда (если не забывать про merge, то она двигается на последний merge commit).
(Ну или просто использовать hg-git и hg histedit
.)
Я это к чему: предположим, что такого режима в tortoisegit нет (а реально я не знаю, есть ли он или нет). Вопрос: насколько сложно будет его туда внести? git ri
вносится в файл настроек одной командой. Альтернативный вариант с feature-base будет работать везде, но точно потребует минимум по два hook’а (post-merge, post-checkout) на каждый репозиторий, где это хочется видеть, ещё больше кода на shell, добавит мусора в список веток и сделает обычный rebase, если он всё же понадобится, немного сложнее.
Ребейз в TortoiseGit работает через cherry-pick. Поэтому все полностью контролируется TortoiseGit. Любой коммит можно отредактировать как нужно через графические инструменты, и сообщение и файлы.
Не вижу большого смысла в возможности добавлять свои команды в GUI. Для сложных вещей есть консоль. А GUI нужен для облегчения повседневной работы.
В консоли по‐умолчанию rebase
идёт на master (точнее, на что‐то настраиваемое, но это «что‐то» — ветка, см. второй абзац раздела «DESCRIPTION» git help rebase
). А alias делает именно это: rebase на начало ветки (пока нет слияний, rebase на последнее слияние, если есть). В tortoisegit есть простой способ найти эту точку?
А про «сложные вещи»: если консоль непривычна, то сложные вещи будет сделать очень сложно. А как она будет привычна, если используется в основном GUI?
В TortoiseGit выпадающие списки со значением по умолчанию. Там не надо ничего искать, всё в интерфейсе показывается.
Кстати, в статье есть команда git rebase -i HEAD~3
. Я так понимаю, она берет последние 3 коммита. Зачем что-то искать, если можно указать?
Сложные вещи делаются редко, можно и потерпеть.
git ri
не требует знания количества коммитов в той части истории, которую нужно изменить, а git rebase -i HEAD~3
требует. Когда их число достигает хотя бы пяти (а я легко могу сделать такую серию только из fixup!
изменений) считать становится уже неудобно; если PR большой, то опечатки приходится исправлять и за десяток полноценных коммитов.
А каким именно образом указывается основание для rebase в tortoisegit я не знаю, пока что он мне был нужен исключительно чтобы сделать git clone
, в случаях, когда мне неохота ставить babun (сборка на основе cygwin), в котором git также есть (для новых проектов, за редким исключением, всегда использую mercurial). В консоли приходится искать, или отряжать скрипт, чтобы он искал. Если в tortoisegit такой скрипт написали за вас, то это отлично.
Там нет скрипта, по крайней мере специально для этого. Есть лог коммитов, в контекстном меню коммита пункт "Rebase onto this". Ничего искать не надо, что хотим то и указываем.
а git rebase -i HEAD~3
требует
А git rebase -i abcdef
не требует.
Т.е. всё же надо искать, где начиналась ваша ветка, или хотя бы предка первого изменяемого изменения. Журнал не в тему: искать удобнее и несколько быстрее, но с git ri
ничего искать не нужно.
git rebase -i abcdef
, внезапно, сделает rebase, если изменения не основаны на abcdef. А нужно изменение истории без rebase.
Что значит "изменение истории без rebase"? У вас команда заканчивается на git rebase --interactive "$o" "$@"
.
Зачем указывать abcdef, если вам не нужно делать на него rebase? По ошибке? Вот поэтому я предпочитаю GUI, там не надо это за каждым символом следить. Ну и да, разговор был что "нужно знать количество коммитов". А это не так.
Журнал не в тему: искать удобнее и несколько быстрее, но с git ri ничего искать не нужно.
Почему не в тему, если вопрос в том, что искать сложно? В консоли сложно, в GUI лог и так постоянно используется. Тыкнуть мышкой в коммит это недолго. У вас была проблема, вы ее решили. А когда лог под рукой, такой проблемы не возникает.
И что, что заканчивается? У git полно универсальных команд: тот же checkout берёт на себя и создание ветки, и переключение на ветку с обновлением рабочего каталога, и обновление каталога без переключения, и частичное применение изменений из другой ветки. У mercurial это всё разные команды (правда, последнего в таком виде как у git нет, или требуется plugin). Изменение истории — это у меня было
A-D'-E-D'' (feature)
|
s-+-B-C (master)
Я хочу объединить D'
и D''
:
A-D-E (feature)
|
s-+-B-C (master)
. Но по‐умолчанию git rebase -i master
сделает
s-B-C (master)-A-D-E (feature)
Взамен вы получили постоянно висящее окно (или лог будет настолько же «под рукой» как у меня в терминале), специализированное практически под одну задачу. А вопрос был не в том, как бы искать попроще, а в том как бы не искать вообще.
git rebase -i master
, если можно написать git rebase -i s
?Взамен вы получили постоянно висящее окно (или лог будет настолько же «под рукой» как у меня в терминале)В терминале выводится только текст, который можно только посмотреть. В графическом интерфейсе из этого окна можно выполнить кучу разных команд. Поэтому не «специализированное практически под одну задачу», а совсем наоборот.
Насчет поиска в GUI. Что в этом сложного?
В терминале можно пускать компиляцию, тесты, посмотреть результаты с travis, … А в tortoisegit только git. Впрочем, это только альтернативный workflow: терминал с tmux и Vim плюс браузер в принципе заменяются на браузер+IDE+tortoisegit, особенно учитывая, что в IDE терминал часто есть.
А сложное: сравните
- Переключиться на черепашку, посмотреть на лог, найти там нужное изменение, навести мышку, нажать ПКМ, навести мышку и нажать ЛКМ, дальше что‐то ещё.
- Переключиться на терминал, напечатать
git ri<CR>
, дальше что‐то ещё.
В терминале можно пускать компиляцию, тесты, посмотреть результаты с travis, …
В одном терминале нельзя увидеть все это одновременно.
Та же компиляция крупных проектов своим логом "затирает" всю информацию на терминале.
Ознакомьтесь с такой штукой как tmux.
Можно делить терминал на "панели", переключаться между "вкладками" (там они называются окна), можно листать вывод, копировать, вставить и, внимание (!!), все это без использования мыши и с помощью сочетаний клавиш emacs/vim (полагаю, что вимовские намного удобнее в контексте тмукса, но я emacs-юзер, поэтому пользуюсь ими).
Даже если Вам не нужны эти фичи, то все равно ознакомьтесь. Это серверное приложение и можно восстанавливать сессии. Очень удобно, если вы работаете по ssh и получаете обрыв связи
Так пускайте, кто мешает) Я говорю конкретно про использование git.
А сложное: сравните
Я к тому, что это настолько сложно, что нужно стремиться вместо этого писать кастомные скрипты в консоли? Мне вот неохота прогонять 10 коммитов с начала ветки, если надо поменять только 2 последних. Не говоря уже о том, что у вас гораздо больше времени уйдет на редактирование файла для ребейза. Это экономия на спичках.
Ну и да. "Переключиться на терминал, нажать G, нажать I, нажать T, нажать Space, нажать R, нажать I, проверить, что нет опечаток, нажать Enter". Обнаружить опечатку "get", переместить туда курсор, убрать символ, добавить символ, или нажать Ctrl+C и набрать все заново. А потом в "git log" проверить, все ли правильно получилось, не забыл ли чего.
Я к тому, что это настолько сложно, что нужно стремиться вместо этого писать кастомные скрипты в консоли?
Нет, именно это — не настолько. Я к консоли «стремлюсь», потому что их там можно писать, и потому что часть вещей там универсальна: к примеру, когда вы не знаете точного вида регулярного выражения проще и быстрее искать что‐то в git log --patch | less
или hg log -v --patch | less
(Про автоматически используемый git’ом pager не говорите, я их всегда отключаю.), чем, во‐первых, вспоминать что поиск по патчам в одном месте git log -G
, в другом hg grep
, во‐вторых, учитывать, что регулярные выражения в одном месте вроде POSIX ERE, а в другом, кажется, Python re, в‐третьих, тратить время на перезапуск — поиск в less быстрее, чем повторный запуск с необходимостью повторно сформировать diff’ы.
Мне вот неохота прогонять 10 коммитов с начала ветки, если надо поменять только 2 последних.
Зависит от редактора: переместить курсор в конец списка изменений в Vim требует нажатия всего одной клавиши.
Не говоря уже о том, что у вас гораздо больше времени уйдет на редактирование файла для ребейза. Это экономия на спичках.
На редактирование файла для rebase у меня зачастую уходит столько же времени, сколько потребуется, чтобы пройти по списку действий из 1, исключая последнее («дальше что‐то ещё»).
Ну и да. "Переключиться на терминал, нажать G, нажать I, нажать T, нажать Space, нажать R, нажать I, проверить, что нет опечаток, нажать Enter". Обнаружить опечатку "get", переместить туда курсор, убрать символ, добавить символ, или нажать Ctrl+C и набрать все заново. А потом в "git log" проверить, все ли правильно получилось, не забыл ли чего.
Слишком долго печатаете для программиста: за следующей клавишей можно и нужно тянуться одновременно с набором предыдущей (даже без слепого набора, но с двумя руками), поэтому делить на отдельные нажатия смысла не имеет. Опечатки тоже проверяются по мере набора (если смотреть не на клавиатуру). А мышка так не параллелится: «найти нужное изменение» и «навести мышку» вы, скорее всего, будете делать одновременно, а с остальным из моего списка так не получится. И ускорить сложнее: про методы ускорения набора я слышал, про методы ускорения взаимодействия с GUI я слышал только «выучите клавиатурные сочетания и используйте методы ускорения набора» (возможно, что‐то иное знают «профессиональные» игроки в некоторые RTS).
(Кстати, такой вопрос: а в tortoisegit часом не получится всё делать с клавиатуры?)
GUI получается вообще универсальнее некуда — везде есть кнопки, списки, текстовые поля.
Про методы ускорения вы не слышали, потому что и так скорость взаимодействия максимальная. Можно сказать, взаимодействие со скоростью света. Поэтому улучшение переносится на этап проектирования UI/UX. Быстрее только сразу запустить нужное действие хоткеем, без взаимодействия с графикой.
Никто как‐то ещё не может похвастаться идеальной, да ещё и универсальной программой, поэтому скорость взаимодействия максимальной быть не может. На этапе проектирования интерфейса ускорены могут быть и консольные, и GUI программы, но GUI намного сложнее подпилить самому под свою задачу, тренировками того же слепого набора можно ускориться ровно настолько, насколько автор покрыл всё клавиатурными сочетаниями. Т.е. если вас не устраивает скорость взаимодействия с GUI приложением или его интерфейс, то вы не сможете сделать ничего, не будучи самому разработчиком GUI приложений.
Универсальности никакой никогда не было, есть некоторые общие соглашения насчёт ограниченного набора действий, но и они часто нарушаются. В тех же полях ввода <S-Left>
почти наверняка что‐то выделит, а уже <C-S-Home>
может и переход сделать. <Tab>
может увести вас куда‐то не туда, вставить что‐то в поле ввода или просто ничего не сделать. До сих пор не могу привыкнуть к тому, что делает <S-перетаскивание>
и <C-перетаскивание>
в Altium: почти везде второе копирует объект, в Altium — перетаскивает с сохранением соединений, а копирует первое. Если автор GUI заранее не предположил, что данные с некоего элемента интерфейса понадобится куда‐то скопировать, то единственным доступным обычному пользователю способом это всё же сделать будет скриншот (и последующее распознавание текста, скорее всего, ручное, — если нужен именно текст) — в GUI я такое вижу постоянно, особенно в сообщениях об ошибках (их очень не любят тестировать). В консоли я такого не видел никогда, технология не позволяет запретить мне скопировать текст.
Конечно, я не жду, что что‐то вроде Altium вдруг окажется консольным приложением — даже если такое существует, под терминал такие приложения не подходят никак. Но универсальности в GUI меньше, чем в консоли: нарушаемые соглашения есть и там, и там, но в консоли часть ожиданий пользователя нарушить нельзя в принципе из‐за ограничений технологии.
Да даже если 22 — это гораздо больше 3 кликов.
На винде лично мне нравятся Git Extensions. Аналог add -p в интерфейсе подготовки коммита делается одной кнопкой (S, от Stage). Там же можно сделать отдельным строкам Unstage или Reset.
git-cola
под linux с примерно таким же функционалом
Idea сокращает явную работу с гитом до минимума
Это как сказать. Не всегда она работает ожидаемо, например при создании ветки она автоматически переключает HEAD на неё. Это очень неожиданно, когда создаёшь ветку, ресетишь текущую, переключаешься на созданную. Возможно я просто привык к TortoiseGit, но тем не менее.
Плюс к этому Idea не всегда показывает всю историю изменений файла, и это не зависит ни от отображения бранчей, ни от текущего HEAD. А git log и TortoiseGit отображает всё верно.
Галочку соответствующую уберите :)
Курсором? Мышку двигать??
Слишком сложно, до свидания.
(хотя, возможно, все не так плохо и можно использовать tab, space и enter)
Видите подчеркнутую "C"? Это означает что Alt+C переключит этот чекбокс. С Idea, я подозреваю, мышку вообще можно не использовать.
Через несколько часов я смог его закрыть
А у меня, примерно в 1993, не было под рукой интернета. Так что я тупо перезагрузил систему. :)
Впрочем, спустя лет 10, мы с vim всё-таки подружились, и с тех пор неразлучны.
а у меня развились фобия и ненависть. Так что я в emacs-лагере:)
Почему тогда не юзаете magit? Шикарнейшая же вещь
Пробовал, не понравилось. Но не скажу, что я очень пытался, даже демо-видео не особо зацепили.
Пересматривал сейчас пост, т.к. не помнил некоторые штуки, а man использовать было бы дольше.
Спустя 3 года я все-таки использую magit и уже довольно редко пишу в консоли (именно поэтому и пришлось открыть собственный пост). Достаточно было перетерпеть недельку :)
Добавлять изменения в старый коммит проще через git commit --fixup ...
с последующим git rebase -i --autosquash origin/master
Этим удобно пользоватья из `gut gui`.
Почему? А потому что я хочу видеть что я там закоммичу. В удобном окне, где можно увидеть список измененных файлов; увидеть список новых файлов и добавить некоторые под контроль версий; откатить изменения в файлах, измененных случайно; добавить игнорируемые по маске в ignores, посмотреть историю изменений и т.д. Все делается сразу в удобном виде в GUI.
Мне не нужно помнить ни одной команды и не одного параметра — все есть в визуальном интерфейсе.
Почему народ так цепляется за консоль мне непонятно… она должна была занять очень узкоспециализированную нишу уже с тех пор, как появились первые TUI тип Нортона под DOS (а было это 20 лет назад). Не говоря уже о GUI.
Я как раз-таки и работаю с гитом из консольки, чтобы полностью иметь контроль над ситуацией. Да, смотреть изменения в консоли, которые ты написал, не очень удобно. Поэтому пользуюсь либо gitk либо средствами, встроенными в IDE.
Консоль хороша, для разруливания нетривиальных ситуаций, но не как ежедневный воркфлоу с переключением контекста.
Корзина — это не какая-то особенная фича графических интерфейсов:)
И в чем заключается переключение контекста? Смена текстового редактора/IDE одного цвета, на консоль другого?
Вы даже в рамках IDE переключаете контекст: вот ты писали код, а вот вы переставляете руку на мышь (мне, например, очень неприятно это делать) и начинаете кликать по менюшкам версионирования.
Несколько раз встречал такое. Те кто работает в консоли, часто добавляют не глядя через git add .
. Из-за этого иногда бывают коммиты с кучей лишних файлов — временные, бэкапы редакторов итд. А потом реверты, или так и остается мусор. Один раз человек то ли удалил каталог, то ли из другой ветки скопировал, и закоммитил случайно, потом при мерже много конфликтов было.
В GUI сразу видно каждый файл, что надо отмечаешь, что не надо отменяешь. Полный контроль над ситуацией)
Ну и, собственно, никто не отменял GUI клиенты с командной строкой. Надо сделать что-то нестандартное — взял и сделал в консоли.
Почему народ так цепляется за консоль мне непонятно…
Помогает лучше понять механизмы работы, что все таки иногда полезно и вероятно некоторым просто любопытно знать детали. За одним кликом мыши в GUI часто скрывается десяток CLI команд.
Ну и статья с использование GUI клиента мотрелась бы глупо.
PS SmartGit получше TortoiseGit будет, хотя бы из-за кроссплатформенности (Java).
Почему народ так цепляется за консоль мне непонятно
Текстовый интерфейс проще визуального. Именно проще. Не всегда легче.
По той же самой причине во всяких IDE есть куча хоткеев — они банально быстрее и проще, чем тыканье мышкой.
По той же самой причине люди цепляются за вим и имакс — их тяжелее выучить, но в них быстрее работать
Не хочу начинать холивар, но, справедливости ради, есть третий путь – fuzzy-поиск по всему доступному, пример реализации – Sublime Text. Не нужно заучивать команды/шоткаты, не нужно искать кнопки/менюшки в GUI: один шоткат для вызова меню, далее пишется нужная команда или её часть, enter.
ИМХО, намного быстрее GUI в использовании, намного удобнее и быстрее vim/emacs в плане освоения. К сожалению, больше нигде не встречал настолько интуитивной и полной реализации данной фичи, часто встречаются лишь частичные реализации (например, fuzzy-поиск по файлам проекта, но нет поиска по командам IDE).
Не пользовался их IDE, хотя постоянно слышу хвалебные отзывы… Что мне нравится в Саблайм, так то, что там этот подход используется для всего: поиск по командам редактора и плагинов, по файлам проекта, по методам внутри файла; из той же строки поиска доступен переход на конкретную строку файла… Возможно, что-то ещё упустил.
И Shift-Shift для поиска везде.
В spacemacs'е есть подобный поиск. Если я не ошибаюсь, за это отвечает или Helm, или fzf.
Не хочу начинать холивар, но emacs умеет это:) можно автокомплитом искать точную команду, можно посмотреть байндинги для определенного сочетания клавиш, можно искать команду по описанию (не гугл-поиск, конечно, но все же). + плагины
Но лично я поиск по описанию использовал только пару раз.
А вообще, теоретически, эта функциональность может быть и в IDE при желании.
Не особо понимаю Atom и Sublime Text, но имакс и вим будут жить еще очень долго, т.к. их функциональность просто никогда не будте реализована в IDE ибо слишком сложно: у вима уникальный принцип работы с текстом, а имакс — это вообще по сути интерпретатор лиспа с встроенным текстовым редактором)
Даже в Atom эта фича реализована не настолько удобно и полно, как в Саблайме. Да и самому Саблайму есть куда стремиться. Например, по-факту, сейчас в Саблайме как минимум 2 разных поиска – по файлам проекта и по коммандам редактора, то есть нужно запомнить, как минимум, два шотката для вызова этих поисков. А их вполне можно было бы объединить в один.
И получить кашу из разнотиповых результатов поиска, которые ещё неплохо бы отображать по‐разному? Вы часто не знаете, ищете ли вы файл или команду? Поиск по тегам, именам файлов и их содержимому иногда имеет смысл объединить: получится что‐то для варианта «коллега упомянул о существовании понятия X, где бы мне посмотреть что это такое?». Вроде то ли в sublime, то ли ещё где их реально объединили. Но искать файл и команду в одном поиске — зачем?
Если для SVN, HG все клиенты нативны, компактны и шустры, то все GUI для Git — это просто оболочки над консольным Git, и скорость работы гита в этом случае совсем не радует. Есть, кстати, компактный нативный клиент для MSVC, но фактически он умеет только локально коммитить, бранчить и мёрджить.
Есть библиотека libgit2, она нативная, компактная и шустрая. Но это C’шная библиотека, а не замена консольному git.
Привязок у библиотеки ну очень много, вроде все популярные языки с поддержкой вызова C’шных функций есть (не знаю, насколько полные и поддерживаемые). А замены консольному git почему‐то нет, а UI основаны на нём. TortoiseGit вроде имеет настройку «UseLibgit2» (если не ошибаюсь, включена по‐умолчанию), но я как‐то недавно установил tortoisegit, забыв git и он всё равно потребовал git, а не просто заблокировал часть операций, которые libgit2 пока не умеет, вместо этого.
Да и локально в 98% случаев я использую только git add, git commit и git push и только для задач которые вовлекают diff использую какой-нибудь гуй. И то не всегда.
И я не понимаю, почему вам непонятно, по какой причине консоль популярна. Может по той причине, что вы никогда не пользовались ею активно, следовательно нашли способы делать нужные для ВАС вещи без нее. Ведь для того, чтобы чем-то эффективно пользоваться, сперва нужно потратить время и освоить инструмент на уровне выше среднего?
Из аргументов:
Консоль кастомизируется под себя гораздо больше, чем GUI
Консоль автоматизируется гораздо проще, чем GUI
Консоль позволяет объединять разные инструменты гораздо проще, чем GUI
Консоль кастомизируется под себя гораздо больше, чем GUIНа практике — да, но теоретически никто не запрещает реализовать все три пункта на нужном уровне в GUI.
Консоль автоматизируется гораздо проще, чем GUI
Консоль позволяет объединять разные инструменты гораздо проще, чем GUI
В то время, как консолевские продукты очень легко обернуть любыми скриптами, алиасами, просто если вы знакомы с консолью на средненьком уровне. А если вы разработчик, то можно даже написать любую удобную вам гуишную оболочку, которая будет вызывать консольные команды.
А я специально на консоль переключаюсь, вообще на отдельное окно. Имхо, смена контекста даже помогает сделать более осознанный коммит, чем тыц-тыц в гуи. Пока команды наберу в кли, глядишь подсознание еще какую мыслишку подкинет :)
git branch -a --contains 9263de3a03cb8b8b79d59fda1883efe9cf7f33e1
молчу, очень мало гуёв предлагают такой функционал.Как финал, у меня стоят гит хуки которые на переключение веток и пулл запускают вебпак. Когда я точно знаю, что ничего не менялось (git checkout -b например), то я в консоли могу сделать ctrl+c и продолжить заниматься своими делами, гуй же виснет, потому что он не знает, что гит хуки запускает и их можно приостановить.
Такой вот флоу у меня. Особого переключения контекста не больше, чем между разными окнами в IDE.
Вообще-то, у гита есть свои алиасы, но я понятия не имею, как их добавлять, т.к. мне лень изучать вопрос.
Добавлять алиасы в гит нужно командой:
git config --global alias.d 'diff' # git d = git diff
Если первый символ команды — !
, то остальная часть сткроки считается, как bash- (ну или что там у вас) команда:
git config --global alias.dc '!git d --cached' # git dc = git d --cached
Приходится использовать '!git', так как без !
не учитываются другие алиасы:
$ git config --global alias.dc 'd --cached'
$ git dc
git: 'dc' is not a git command. See 'git --help'.
git log --graph — просто он забавный. Не знаю, есть ли практическое применение.
Он не забавный, он прекрасен. Он выводит коммиты по-настоящему, показывает мерджи, места, где ветки расходятся, и т. д. Сам использую зловещее выражение, добытое где-то на хабре:
log --graph --abbrev-commit --decorate --all --format=format:\"%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(dim white) - %an%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n %C(white)%s%C(reset)\"
И легко можно понять, что 3f5c093 — мердж, что были смерджены изменения в DropDown и master-ветка, что 5a88259 — продолжение 62f349f, то есть ветка dropdown
. А когда ветки разного цвета (на самом деле так и есть, просто в markdown нет цветов), еще понятнее.
| | Pages: Make Pages.sections object of objects instead of object of arrays
* | 95874bc - Fri, 16 Jun 2017 21:44:19 +0300 - Ivanq (2 months ago)
|\ \ Merge branch 'dropdown' into design
| |/
| * 5a88259 - Fri, 16 Jun 2017 21:23:03 +0300 - Ivanq (2 months ago)
| | DropDown: Don't make users use <select> and <option>
* | 09334af - Fri, 16 Jun 2017 21:28:27 +0300 - Ivanq (2 months ago)
| | Includes: Get rid of <for>
* | 3b69065 - Fri, 16 Jun 2017 18:22:49 +0300 - Ivanq (3 months ago)
| | UI.Page: Move section-specific styles to inc/{{section}}/index.css
| | UI.Post: Show download button
* | 5c8ce85 - Fri, 16 Jun 2017 15:00:25 +0300 - Ivanq (3 months ago)
| | UI.Post: Show additional info
* | 3921890 - Fri, 16 Jun 2017 15:00:12 +0300 - Ivanq (3 months ago)
| | UI.Column: Pass platform, place and demoparty to <include>
* | f555f9f - Fri, 16 Jun 2017 14:59:30 +0300 - Ivanq (3 months ago)
| | Includes: Allow passing objects to <include>
* | 3f5c093 - Fri, 16 Jun 2017 14:58:43 +0300 - Ivanq (3 months ago)
|\ \ Merge branch 'dropdown' into design
| |/
| * 62f349f - Fri, 16 Jun 2017 14:58:32 +0300 - Ivanq (3 months ago)
| | DropDown: Pass native <select> to constructor instead of <div>
* | c14f018 - Fri, 16 Jun 2017 14:56:50 +0300 - Ivanq (3 months ago)
| | Translate: Implement Translate::place() and Translate::ordinal()
* | c984efc - Fri, 16 Jun 2017 12:19:27 +0300 - Ivanq (3 months ago)
| | UI.News: Update news font
* | 3463a02 - Fri, 16 Jun 2017 11:05:11 +0300 - Ivanq (3 months ago)
|\ \ Merge branch 'dropdown' into design
| |/
| * 6b5d202 - Fri, 16 Jun 2017 10:55:35 +0300 - Ivanq (3 months ago)
| | DropDown: Fire 'change' event
| * 8864ea3 - Thu, 15 Jun 2017 21:57:41 +0300 - Ivanq (3 months ago)
|/ DropDown: Add
* ac2380d - Thu, 15 Jun 2017 19:19:46 +0300 - Ivanq (3 months ago)
| UI.Column: Show section name
* 5faebfa - Thu, 15 Jun 2017 19:19:34 +0300 - Ivanq (3 months ago)
| Translate: Add Translate::section()
Одна из причин, по которым я не хочу разбиратся с гитовыми алиасами — мне все равно придется писать git <something>
.
Т.к. автокомплит настраивается и для башевых алиасов, я предпочту gdiff
, а не git d
(не люблю нажимать пробел без причины)
Мне нравится граф в bitbucket. А так я заметил, что многие практикуют ребейз.
Спасибо за интересный ответ:)
[alias]
co = checkout
ci = commit
st = status
br = branch
hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
type = cat-file -t
dump = cat-file -p
lg1 = log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(black)%s%C(reset) %C(dim black)- %an%C(reset)%C(bold red)%d%C(reset)' --all
lg2 = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold red)%d%C(reset)%n'' %C(black)%s%C(reset) %C(dim black)- %an%C(reset)' --all
lg = !"git lg1"
SOLO@DESKTOP-ZA MINGW64 ~/Documents/Repos/sodev (feature/SOdo)
$ log --graph --abbrev-commit --decorate --all --format=format:\"%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(dim white) - %an%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n %C(white)%s%C(reset)\"
bash: syntax error near unexpected token `('
git log
вместоlog
.- В моей команде нужно экранирование кавычек, так как используется алиас. Вам нужно заменить
\"
на"
, тогда заработает.
Если понравится, просто скопируйте мой команду.
добавляю префикс[to_squash]
и переношу этот коммит
В справке git rebase --help написано, что гит умеет менять порядок автоматически, если использовать префикс squash! сообщение коммита
Спасибо! Добавил в избранное, буду осваивать.
«я пользуюсь командной строкой», а я пользуюсь Волков Коммандер и нечаянно нажал F8 и все удалил. :D
"я что-то нажала и все исчезло"
Я во время написания статьи, похоже, задел cmd+z, и у меня часть текста испарилась. Долго искал, что и где
Far Manager решает эту проблему (F8 удаляет в корзину). Поэтому чтобы нечаянно удалить приходится нажимать Shift+Del :-)
alias git-uncommit='git reset --soft $(git log --format=%H -2 | tail -1)'
а не проще как-нибудь вот так:
alias git-uncommit='git reset --soft HEAD~1'
Абсолютно!
Еще проще:
alias git-uncommit='git reset --soft HEAD~'
(единица опциональна)
Этому алиасу уже пара лет. Работает — не трогаю:)
Попробуйте с таким алиасом сделать uncommit два раза подряд :-)
С другой стороны, такой алиас, в отличие от варианта с git log, умеет отменять amend...
А то я чуть было не написал абсолютно такой же комментарий, как и выше :)
Для текущей ветки лучше использовать __git_ps1
Для просмотра диффа в индексе git diff --staged там и новые файлы показываются
У меня такой функции нет:( Видимо, слишком старый комплишн-скрипт.
--staged
и --cached
тождественны, разве нет?
--staged
— это синоним --cached
. Вопрос предпочтения.единственный удобный GUI для Git под Linux
А встроенный в WebStorm? Хотя я все-равно во всех ОС предпочитаю консоль для работы, только конфликты резолвлю в гуи.
Если пользуетесь Emacs, рекомендую посмотреть на magit. Крайне удобная штука.
git stash
git stash branch new-branch-name
Есть пострашнее история:
Как-то раз опытный программист хотел впервые закоммитить код на свежеустановленной системе, а гит открыл ему nano!
Чем нано не угодил? Там есть информация об основных действиях: закрыть, сохранить, вырезать и пр. Имхо, лучше бы по-умолчанию открывался всегда он.
Его можно не любить, но невозможно отрицать, что он лучше всего подходит на роль "общего" редактора.
а гит открыл ему nano!
nano — это ладно, а как-то мне гит vim открыл, пришлось новый комп покупать.
Вообще-то, у гита есть свои алиасы, но я понятия не имею, как их добавлять, т.к. мне лень изучать вопрос.
Уже за это хочется поставить минус. Лень прочитать документацию — зачем вообще тогда берёшься за инструмент? Эта инфа есть в man git-config
.
Лично я в указанной ситуации (а у меня она часто возникает) делаю так: создаю коммит, где в сообщении добавляю префикс[to_squash], заканчиваю работу над веткой, делаю полный ребейз ветки на мастер (git rebase -i master) и переношу этот коммит под тот, к которому данная правка относится, с пометкой s (squash).
Открой для себя autosquash! Почитай про git rebase --autosquash
и git commit --fixup/--squash
. Всё есть в man git-rebase
и man git-commit
. Если не лень изучать, кочнечно.
#!/bin/bash
while true; do
echo -n "git shell# ";
read command;
git $command;
done
git stash, сменить ветку, ..., вернуть ветку, git stash pop
Опасно! У нас так один разработчик случайно потерял все, что он сделал за день, теперь использует:
git stash apply
Перемещался по веткам, что-то срочно правил, возвратился на свою, применил stash не там, откатился на правильную ветку… а в stash уже пусто.
Содержимое squash ничем принципиально не отличается от обычного коммита (кроме того, что этот squash-коммит обычно недостижим из именованных веток). В этой ситуации нужно было просмотреть вывод git reflog
, найти там хеш нужного коммита и вернуть его содержимое в рабочую копию при помощи git checkout
.
А нет, простите, это не настолько просто, но всё равно возможно.
alias glod='git log --oneline --decorate'
забирайте! бесплатно без регистрации
oh-my-zsh — просто ставлю по дефолту везде (если приходится что-то под виндой делать тут babun неплох) потому что подсказка по истории операций на основе ввода это просто божественно.
я могу обновить последний коммит в 3 нажатия на клавиатуру "g" + up + enter,
а если операция не из последних то нажать up несколько раз, или уточнить запрос.
Про алиасы к гиту
https://github.com/GitAlias/gitalias
я чаще всего пользую g st, и g ca (commit --amend)
С момента как перешел с Win на lin 6 лет назад (а потом и на mac) — я обожаю консоль.
Особенно я ее люблю когда работаю с ноута лежа на диване, потому что клавиатура всегда клавиатура а тачпад совсем не мышка, целиться не так удобно.
Мне вообще кажется что владение консолью(также как и английским) является обязательным для программиста(хотяб на уровне базовых команд).
У меня на одной из работ тимлид был из gui-любов, а весь остальной отдел из маководов -консольводов… холивар не стихал — трудно ему приходилось, интересно он осознал или продолжает целиться мышкой в кнопочки.
1) Сделать временный коммит
2) git stash, сменить ветку, ..., вернуть ветку, git stash pop
А потом забыть про всё это и воспользоваться git worktree
git log --graph — просто он забавный. Не знаю, есть ли практическое применение.
git log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%C(bold blue)<%an>%Creset' --abbrev-commit
Так же дает очень интересный эффект с подсветкой, наименованием коммита, временем и автором.
создаю коммит, где в сообщении добавляю префикс[to_squash], заканчиваю работу над веткой, делаю полный ребейз
У меня сложилась такая система для ненужных коммитов.
'.'
— дополнить предыдущий коммит, используется вместо amend если могут понадобиться изменения с прошлого шага — просто посмотреть или откатить только их.
'.. <message>'
— сделать squash с одним из предыдущих.
'... <message>'
или '. <message>'
— временный коммит, который надо будет отредактировать — разделить на несколько, пропустить, или просто сообщение поправить.
Может кто-то уже обратил внимание(не читал все комменты). Однако код ниже не выглядит очень хорошо:
function git-current-branch {
git branch --no-color 2> /dev/null | grep \* | colrm 1 2
}
Можно сделать например так:
git rev-parse --abbrev-ref HEAD
"Работает — не трогай".
Этот код в моем конфиге уже 3 года. Как часто Вы рефакторите свои конфиги?:)
По существу: спасибо, но если вы выполните эту команду на каком-то отдельно взятом коммите (не ветке или теге), то выводом будет просто HEAD
. Уверен, можно это дело усложнить и решить вопрос, но зачем?
По моему, в IDE удобно только логи и диффы смотреть. Для всего остального набрать команду намного проще, чем искать какую-то кнопку и пытаться угадать как реально производимое действие легло на фантазии разработчика GUI.Если вы постоянно работаете с конкретной IDE, запомнить пару хоткеев и использовать их гораздо эффективней набора команд.
Года 4 назад перешли с SVN на GIT. Знающие ребята все твердили о важности консоли и о проблемах GUI. Через полгода перевел продукт на другую модель ветвления(сильно проще), и как-то надобность в консоли совсем отпала. За последние 3 года git-консоль использовал только в билд скриптах. Intellij IDEA за 4 года хорошо добавила в VCS функционале (правда до сих пор нет сквоша одной кнопкой), она же позволяет пользоваться шорткатами и в 90% действительно не трогать мыш при коммите, пуше, создании бранча и других "типичных" операциях. Но самое главное для меня это богоподный DIFF от IDE. Кто бы и что не говорил, но проверить 30+ файлов перед коммитом в GUI намного проще, чем в самой навороченной консоле.
Выше был пример "создал ветку fix-foo, а надо закоммитить fix-bug-123-dialog" — у меня все ветки создаются из Jira и потом в Bitbucket потом мержаться со сквошем через PR. Зачем создавать ветку руками, с именем, оторванным от предметной задачи?
В Intellij IDEA, например, интеграция с GIT много шире, чем просто комманды. Та же история доступна не только списокм с разными фильтрами, но интегрирована прямо в класс через "Annotations": https://plugins.jetbrains.com/plugin/8514-vcs-annotations-preloader
-f — обязательная опция, без нее гит попросту откажется что-либо удалять (уж не знаю, зачем она)
-f
--force
If the Git configuration variable clean.requireForce is not set to false, git clean will refuse to delete files or directories unless given -f, -n or -i. Git will refuse to delete directories with .git sub directory or file unless a second -f is given.
Зато, хоть, вроде не перевод! ;)
Вы, конечно, большой молодец, что скопировали кусок мануала, но ничего нового мне не сообщили (Вы удивитесь, но я читал мануал по гиту, а не методом тыка узнавал какие-то фичи) :)
Ответа на мой вопрос "зачем" этот кусок так и не дает.
раньше, (до 2122591b3b5c6d93d3052a3151afcfa3146ede84), я так понимаю, она была деструктивной, удаляла файлы без предупреждения, а среди этих файлов могли быть и нужные, но не добавленные в репозиторий…
вот из списка рассылки:
How is it useful to abort completely? Wouldn't it be better to behave
like -n unless -f is given?
I don't think so, for a couple of reasons.
* I want to make it really obvious that git-clean did nothing. Spewing piles
of output quickly obscures the error message, and doesn't convey «git-clean
did nothing» at a glance.
* -n takes time, especially with a large working copy. Doing nothing takes
very little time. The original use case motivating this patch came from the
idea of a git $HOME, and wanting to make sure git-clean won't delete
everything untracked in $HOME. git-clean -n would take a long time here,
and I don't want to do it implicitly, particularly if I meant to clean a git
repository *under* $HOME.
— Josh Triplett
Josh Triplett — автор патча
Кто где находит инфу по Гиту. Всегда есть >> Первоисточник + Альтернативы…
Но команды, методологии, способы, тулзы, где мы про них не узнали — всегда буду полезны.
Автору спасибо за статью.
Для меня эта статья выглядела "как из git сделать mercurial". Например скрипт для просмотра текущей ветки выглядит… диковато.
У гита вроде есть дополнение (к сожалению, не могу вспомнить название), которое дает кучу алиасов и делает все "проще".
Дополните?
git gc — сборщик мусора, помогает существенно уменьшить занимаемое место на диске
Git. Быстрый старт. Назначение и возможности. Урок 1 [GeekBrains], не сочтите за рекламу, но понимать проще.
Как я использую git