Pull to refresh

Comments 195

UFO just landed and posted this here

Собственно, моя первая работа началась с изучения этой книги. Потом пару месяцев активно применял полученные знания, периодически в неё подглядывая и все фичи из поста отложились в подкорке.


Но должен заметить что та же Idea сокращает явную работу с гитом до минимума. Коммиты, пуши, ребазы, чекауты, новые ветки, стэши… Да и CVS>Log очень удобен, когда явно видишь все коммиты, их взаимосвязи и изменения в каждом из них. Единственное, чего не хватает — add -p, ну или я ещё не нашёл как оно делается.

UFO just landed and posted this here

Ну вообще отчасти это верно, просто я эти команды набираю в менюшке, выскакивающей по Ctrl+Shift+A, где доступны вообще все действия IDE. Ну и пока вроде всё действует по методу наименьшего удивления, так что угадывать ничего не приходится.
Ну и сохранение пароля жизнь упрощает, хотя оно конечно и в консоли настраивается. В общем-то, главный плюс IDE в том, что не происходит никакого переключения контекста, даже терминал открытым держать не надо.

UFO just landed and posted this here

Ну да, ей я всегда и пользуюсь. Только всё равно это переключение в другую парадигму, тут не так важно, в отдельном окне терминал или в том же.

UFO just landed and posted this here

Соглашусь, но отчасти: в QtC, к примеру, мне удобно:


  • делать комиты, в том числе интерактивно выбирая то, что на комит добавить (add -p)
  • переключаться между ветками: в QtC используется трюк со stash: он добавляет метку и можно переключиться на другую ветку автоматически скрыв изменения в stash и восстановить их по возвращению на ветку.

Ну и диффы и история, куда без этого.

В Tortoise Git для отправки изменений нужно сделать 3 клика мышью.
В командной строке нужно для того-же самого 32 нажатия клавиши.
Не знаю кому 32 нажатия проще чем 3.

Ну вообще говоря еще сообщение коммита нужно на клавиатуре набирать.

Не забыл, но это одинаковое кол-во нажатий как в консоли, так и без консоли.
Кстати можно выбрать из шаблонов и даже надиктовать, не всё так однозначно.
Помимо одинакового кол-ва нажатий, в GUI есть ещё затраты на переключение с клавиатуру на мышь и обратно. Про шаблоны и надиктовать — используйте нормальный $GIT_EDITOR (vim, emacs) вместо дефолтного vi и у вас будут и шаблоны и что угодно, ограниченное только вашей фантазией в скриптовании редактора. В GUI в любом случае у вас будет банальная textarea.
Это всё теория. На практике я в любом случае 3 клика сделаю быстрее чем вы введёте несколько команд, независимо от алиасов, табов и прочего.
Проверял неоднократно.
Даже и не знаю.
У меня это выглядит таким образом:
Переколючаемся в консоль (Если я в этот момент в IDE от Intellij, то клац по кнопке терминала, если в Vim — то Ctrl-Z). — Одна секунда максимум.
Потом gca и ввод.
Пишем сообщение и выходим. (помимо сообщения тоже секунда максимум)
Так что по времени это будет не дольше чем три клика. Вопрос привычек и удобства.
P.S. Я пытаюсь показать альтернативный сценарий, а не переубедить. Вы же мышкой всё равно продолжите, а я в консоли.
Это у вас теория. Если вы пользуетесь например энтерпрайз битбакетом, то пока откроется страничка, пока вы сделаете пулл реквест, пока выпадающий список считает новые бренчи… А в консоли точное название бренча написал, команду куда мержить написал, нажал enter и пошел делать другую задачу.
У вас видимо либо узкий интернет-канал, либо тормозные рабочие станции.
Кроме того, при чём тут страничка?
У вас есть десктопный GUI к битбакету, дженкинсу, тимсити?
Из консоли можно запускать необходимые действия с минимальными навыками продвинутого юзера. Как это все автоматизировать/ускорить в GUI?
Не особо обоснованный аргумент. Очевидно, что алиас будет быстрее нескольких кликов с диалогами и ожиданием завершения команд. CUI по своей природе кастомизируется лучше, чем GUI.
«На практике я в любом случае 3 клика сделаю быстрее чем вы введёте несколько команд, независимо от алиасов, табов и прочего.»

У меня вопрос. У вас вообще скорость набора хотя бы 200-300 символов в минуту есть? Три клика в разных местах экрана это не тройной клик.
А вызов алиаса может быть например 1-2 буквы, таб (автодополнение) и enter, что даже на слух воспринимается как короткая трель.
А я то тут при чём? Я ж не сам с собой соревновался.
Чтобы добавить хоть чуточку объективности в ваш эксперимент (=
Алиасы и авто дополнение в консоли никто не отменял. А вы забыли про то что мышку еще нужно до этих пунктов довести. Так что не все так однозначно.
Я соревновался как-то специально, и всегда выигрывал, с отрывом причём.
Для стандартных действий — да, кнопку нажать быстрее. Для более менее нестандартных ситуаций — нет. И тут начинается: из gui это сделать вообще можно? Есть там такая фишка? А где? Сколько минут будете лазить пока найдёте?
Use case:
1. Вы что-то там себе в ветке fix-foo делали
2. Потом переключились на dev и продолжили работу.
3. А теперь вас попросили пушнуть ветку fix-foo только под нормальным именем, типа bug/proj-1567-fix-foo

Из консоли это можно сделать одной командой и не будет путаницы в «понимании поведения интерфейса».
В итоге бывает проще выучить 1 инструмент (git cli), чем несколько. Конечно, это не отменяет того, что GUI — удобная штука.

Кстати, пункт 4: пушнуть ветку fix-foo без последнего коммита (потому, что там ерунда) — это всё ещё одна команда.

А теперь вас попросили пушнуть ветку fix-foo только под нормальным именем, типа bug/proj-1567-fix-foo


И в чём проблема?

image

Два клика, никакой путаницы.
Интересно откуда цифра 32?
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 вызивает боль). И в этом нет ничего плохого, но обобщать подобный опыт не стоит.
Это не просто 22, их надо проверять, чтобы все правильно было. Это дополнительное внимание и время на исправление если ошибся, особенно в середине. В GUI значения уже подставлены, если команда стандартная, то просто тыкаешь в район кнопки. Если не попал, то ничего не произойдет.

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.


Проблемы, решаемые таким вариантом:


  1. Выполнив git ri вы не получите внезапно неработающие изменения, потому что в master немного поменяли API чего‐то, использующегося в новом коде, а слияния от такого конфликты обычно не ловит.
  2. Во время rebase легко словить серию конфликтов: коммит 1 конфликтует с новыми измемениями в master, коммиты 2, 3, … модифицируют код из первого, и, соответственно, попытка их применения вызывает конфликты, если первый был изменён в ходе решения конфликта. При merge конфликты вы решаете только один раз, но…
  3. … иногда хочется взять и исправить несколько опечаток где‐то в середине ветки, замеченных ближе к концу во время тестирования, но не хочется при этом получать 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, если он всё же понадобится, немного сложнее.

Так не надо ребейзить на master. Надо ребейзить на начало своей ветки. Тогда эти проблемы в принципе не появляются.

Ребейз в 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 терминал часто есть.


А сложное: сравните


  1. Переключиться на черепашку, посмотреть на лог, найти там нужное изменение, навести мышку, нажать ПКМ, навести мышку и нажать ЛКМ, дальше что‐то ещё.
  2. Переключиться на терминал, напечатать 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 нет) Я например не знаю, как в git отключается pager, как-то не было необходимости интересоваться.

GUI получается вообще универсальнее некуда — везде есть кнопки, списки, текстовые поля.

Про методы ускорения вы не слышали, потому что и так скорость взаимодействия максимальная. Можно сказать, взаимодействие со скоростью света. Поэтому улучшение переносится на этап проектирования UI/UX. Быстрее только сразу запустить нужное действие хоткеем, без взаимодействия с графикой.

Никто как‐то ещё не может похвастаться идеальной, да ещё и универсальной программой, поэтому скорость взаимодействия максимальной быть не может. На этапе проектирования интерфейса ускорены могут быть и консольные, и GUI программы, но GUI намного сложнее подпилить самому под свою задачу, тренировками того же слепого набора можно ускориться ровно настолько, насколько автор покрыл всё клавиатурными сочетаниями. Т.е. если вас не устраивает скорость взаимодействия с GUI приложением или его интерфейс, то вы не сможете сделать ничего, не будучи самому разработчиком GUI приложений.


Универсальности никакой никогда не было, есть некоторые общие соглашения насчёт ограниченного набора действий, но и они часто нарушаются. В тех же полях ввода <S-Left> почти наверняка что‐то выделит, а уже <C-S-Home> может и переход сделать. <Tab> может увести вас куда‐то не туда, вставить что‐то в поле ввода или просто ничего не сделать. До сих пор не могу привыкнуть к тому, что делает <S-перетаскивание> и <C-перетаскивание> в Altium: почти везде второе копирует объект, в Altium — перетаскивает с сохранением соединений, а копирует первое. Если автор GUI заранее не предположил, что данные с некоего элемента интерфейса понадобится куда‐то скопировать, то единственным доступным обычному пользователю способом это всё же сделать будет скриншот (и последующее распознавание текста, скорее всего, ручное, — если нужен именно текст) — в GUI я такое вижу постоянно, особенно в сообщениях об ошибках (их очень не любят тестировать). В консоли я такого не видел никогда, технология не позволяет запретить мне скопировать текст.


Конечно, я не жду, что что‐то вроде Altium вдруг окажется консольным приложением — даже если такое существует, под терминал такие приложения не подходят никак. Но универсальности в GUI меньше, чем в консоли: нарушаемые соглашения есть и там, и там, но в консоли часть ожиданий пользователя нарушить нельзя в принципе из‐за ограничений технологии.

А git add?

Да даже если 22 — это гораздо больше 3 кликов.
Ctrl+Shift+K в любимой IDE.
Еще и проверит не забыл ли TODO, проведет анализ кода и при необходимости сделает деплой.
А если линукс или ssh? Да здравствует Oh My Zsh!

На винде лично мне нравятся Git Extensions. Аналог add -p в интерфейсе подготовки коммита делается одной кнопкой (S, от Stage). Там же можно сделать отдельным строкам Unstage или Reset.

git-cola под linux с примерно таким же функционалом

Тоже пользуюсь Git Extensions на винде. Интерфейс информативен в достаточной мере.
Согласен, на мой взгляд там можно сделать практически всё, что может понадобиться, плюс интуитивный интерфейс. Из консоли делаю только команды вроде git remote add origin, одной командой проще, чем через окна.
Idea сокращает явную работу с гитом до минимума

Это как сказать. Не всегда она работает ожидаемо, например при создании ветки она автоматически переключает HEAD на неё. Это очень неожиданно, когда создаёшь ветку, ресетишь текущую, переключаешься на созданную. Возможно я просто привык к TortoiseGit, но тем не менее.
Плюс к этому Idea не всегда показывает всю историю изменений файла, и это не зависит ни от отображения бранчей, ни от текущего HEAD. А git log и TortoiseGit отображает всё верно.

Галочку соответствующую уберите :)

Курсором? Мышку двигать??
Слишком сложно, до свидания.


(хотя, возможно, все не так плохо и можно использовать tab, space и enter)

Видите подчеркнутую "C"? Это означает что Alt+C переключит этот чекбокс. С Idea, я подозреваю, мышку вообще можно не использовать.

Интересно, а переназначить такое можно? У меня лично все <A- зарезервированы под оконный менеджер. Конкретно <A-c> был заменой <A-F4> (закрытие текущего окна) пока я был на fluxbox, когда переписывал сокращения под i3, то решил, что я слишком часто нажимаю <A-c> случайно и надо бы добавить shift.

Как вы там в конце статьи написали? Know your tools?
IDE это хорошо ровно до тех пор, пока что-то не сломалось
Через несколько часов я смог его закрыть

А у меня, примерно в 1993, не было под рукой интернета. Так что я тупо перезагрузил систему. :)


Впрочем, спустя лет 10, мы с vim всё-таки подружились, и с тех пор неразлучны.

Просто интересно, переключать консоль вы тогда тоже не умели (Alt+F1-F8)? Или ОС не поддерживала?

ЗЫ Я в аналогичных случаях обычно жал Ctrl+Z и убивал процесс руками :)

а у меня развились фобия и ненависть. Так что я в emacs-лагере:)

А разве в кофеварке есть текстовый редактор?

Почему тогда не юзаете magit? Шикарнейшая же вещь

Пробовал, не понравилось. Но не скажу, что я очень пытался, даже демо-видео не особо зацепили.

Пересматривал сейчас пост, т.к. не помнил некоторые штуки, а man использовать было бы дольше.


Спустя 3 года я все-таки использую magit и уже довольно редко пишу в консоли (именно поэтому и пришлось открыть собственный пост). Достаточно было перетерпеть недельку :)

Добавлять изменения в старый коммит проще через git commit --fixup ... с последующим git rebase -i --autosquash origin/master

А еще можно использовать комментарии коммитов вида `fixup! комментарий коммита в истории`, и при `rebase -i --autosquash` коммит так-же переедет в нужное место.
Этим удобно пользоватья из `gut gui`.
дык,
 git commit --fixup sha-1

как раз делает
комментарии коммитов вида
 fixup! комментарий коммита sha-1 в истории
С гитом лучше работать в zsh, а не в bash. Он (в виде плагина oh_my_zsh) умеет делать автокомплит для бранчей и показывает текущий бранч изкаропки.
автокомплит для бранчей

Ну так башевый гит-комлишн тоже это могёт. Какие-то другие преимущества помимо самого bash vs zsh есть?:)


Лично я не пользуюсь zsh по двум причинам:


1) почти везде баш
2) один раз случайно его запустил (зашел в терминал на чужой машине) и испугался

Я вам честно скажу, использую гит равно как и другие системы контроля версий только через GUI оболочки типа TortoiseGit, TortoiseHG или RabbitVCS.
Почему? А потому что я хочу видеть что я там закоммичу. В удобном окне, где можно увидеть список измененных файлов; увидеть список новых файлов и добавить некоторые под контроль версий; откатить изменения в файлах, измененных случайно; добавить игнорируемые по маске в ignores, посмотреть историю изменений и т.д. Все делается сразу в удобном виде в GUI.
Мне не нужно помнить ни одной команды и не одного параметра — все есть в визуальном интерфейсе.
Почему народ так цепляется за консоль мне непонятно… она должна была занять очень узкоспециализированную нишу уже с тех пор, как появились первые TUI тип Нортона под DOS (а было это 20 лет назад). Не говоря уже о GUI.
Я был знаком с программистом, работающим в GUI и потерявшем все изменения по задаче за 4 часа, из-за того что случайно куда-то не туда нажал и не знал что делать дальше.

Я как раз-таки и работаю с гитом из консольки, чтобы полностью иметь контроль над ситуацией. Да, смотреть изменения в консоли, которые ты написал, не очень удобно. Поэтому пользуюсь либо gitk либо средствами, встроенными в IDE.
Я был знаком с программистом(каждый день в зеркале вижу), который в консоли удалил файлы по ошибке. Как легко и просто восстановить их там? В GUI — это корзина, 2 клика для восстановления.

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

Корзина — это не какая-то особенная фича графических интерфейсов:)


И в чем заключается переключение контекста? Смена текстового редактора/IDE одного цвета, на консоль другого?


Вы даже в рамках IDE переключаете контекст: вот ты писали код, а вот вы переставляете руку на мышь (мне, например, очень неприятно это делать) и начинаете кликать по менюшкам версионирования.

Несколько раз встречал такое. Те кто работает в консоли, часто добавляют не глядя через git add .. Из-за этого иногда бывают коммиты с кучей лишних файлов — временные, бэкапы редакторов итд. А потом реверты, или так и остается мусор. Один раз человек то ли удалил каталог, то ли из другой ветки скопировал, и закоммитил случайно, потом при мерже много конфликтов было.


В GUI сразу видно каждый файл, что надо отмечаешь, что не надо отменяешь. Полный контроль над ситуацией)

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

Ну и, собственно, никто не отменял GUI клиенты с командной строкой. Надо сделать что-то нестандартное — взял и сделал в консоли.
UFO just landed and posted this here
Это вопрос кривизны реализации Эклипса (безотносительно VCS, эта IDE весьма кривая сама по себе). В Tortoise* добавление в ignore list более-менее грамотное: никаких абсолютных путей, предалагается несколько вариантов (например фрагмент относительного пути, например "/Debug/", или расширение "*.obj" или имя файла с расширением). Еще одно преимущество графических утилит — добавляя маску в ignore list, я сразу вижу как исчезает группа файлов в списке кандидатов на добавление; список уменьшается и я обращаю внимание на следующие файлы, которые нужно добавить в игнорируемые или наоборот добавить под контроль версий. То есть прежде чем коммитить я получу готовый список без единого лишнего файла, который я буду видеть заранее.
UFO just landed and posted this here
Для линукса вообще беда: куча DE и файловых менеджеров, под многие из которых просто не реализован доступ к конкретным VCS-GUI-утилитам из контекстного меню. А если и реализован то с какими-то глюками.
UFO just landed and posted this here
Почему народ так цепляется за консоль мне непонятно…

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

Ну и статья с использование GUI клиента мотрелась бы глупо.

PS SmartGit получше TortoiseGit будет, хотя бы из-за кроссплатформенности (Java).
Может всё же стоит оценивать инструменты по показателям удобства, ну или количеству фич? Лично мне совершенно без разницы кроссплатформенная тулза или нет, если она есть на моей платформе. Тем более если это всего лишь GUI к гиту.
Почему народ так цепляется за консоль мне непонятно

Текстовый интерфейс проще визуального. Именно проще. Не всегда легче.


По той же самой причине во всяких IDE есть куча хоткеев — они банально быстрее и проще, чем тыканье мышкой.


По той же самой причине люди цепляются за вим и имакс — их тяжелее выучить, но в них быстрее работать

Не хочу начинать холивар, но, справедливости ради, есть третий путь – fuzzy-поиск по всему доступному, пример реализации – Sublime Text. Не нужно заучивать команды/шоткаты, не нужно искать кнопки/менюшки в GUI: один шоткат для вызова меню, далее пишется нужная команда или её часть, enter.


ИМХО, намного быстрее GUI в использовании, намного удобнее и быстрее vim/emacs в плане освоения. К сожалению, больше нигде не встречал настолько интуитивной и полной реализации данной фичи, часто встречаются лишь частичные реализации (например, fuzzy-поиск по файлам проекта, но нет поиска по командам IDE).

Все IDE от JetBrains это умеют: там с незапамятных времён есть Find Action (Cmd/Ctrl+Shift+A), который ищет по командам. Действительно очень полезная штука.

Не пользовался их IDE, хотя постоянно слышу хвалебные отзывы… Что мне нравится в Саблайм, так то, что там этот подход используется для всего: поиск по командам редактора и плагинов, по файлам проекта, по методам внутри файла; из той же строки поиска доступен переход на конкретную строку файла… Возможно, что-то ещё упустил.

И Shift-Shift для поиска везде.

В spacemacs'е есть подобный поиск. Если я не ошибаюсь, за это отвечает или Helm, или fzf.

Не хочу начинать холивар, но emacs умеет это:) можно автокомплитом искать точную команду, можно посмотреть байндинги для определенного сочетания клавиш, можно искать команду по описанию (не гугл-поиск, конечно, но все же). + плагины
Но лично я поиск по описанию использовал только пару раз.


А вообще, теоретически, эта функциональность может быть и в IDE при желании.
Не особо понимаю Atom и Sublime Text, но имакс и вим будут жить еще очень долго, т.к. их функциональность просто никогда не будте реализована в IDE ибо слишком сложно: у вима уникальный принцип работы с текстом, а имакс — это вообще по сути интерпретатор лиспа с встроенным текстовым редактором)

Даже в Atom эта фича реализована не настолько удобно и полно, как в Саблайме. Да и самому Саблайму есть куда стремиться. Например, по-факту, сейчас в Саблайме как минимум 2 разных поиска – по файлам проекта и по коммандам редактора, то есть нужно запомнить, как минимум, два шотката для вызова этих поисков. А их вполне можно было бы объединить в один.

И получить кашу из разнотиповых результатов поиска, которые ещё неплохо бы отображать по‐разному? Вы часто не знаете, ищете ли вы файл или команду? Поиск по тегам, именам файлов и их содержимому иногда имеет смысл объединить: получится что‐то для варианта «коллега упомянул о существовании понятия X, где бы мне посмотреть что это такое?». Вроде то ли в sublime, то ли ещё где их реально объединили. Но искать файл и команду в одном поиске — зачем?

К списку оболочек можно добавить SourceTree от Atlassian.
Поддерживаю. Единственный известный мне клиент для Windows, который адекватно работает с Git-svn (уж приходится пользоваться такими извращениями). Недавно Tower for Win выпустили, но он не умеет(
У Git под Windows есть одна проблема: отсутствие компактных нативных портов. Git работает исключительно под MinGW и тянет с собой все её кишки — в итоге получается больше 5000 файлов и 200 мегабайт. А Windows мелкие файлы очень не любит.

Если для SVN, HG все клиенты нативны, компактны и шустры, то все GUI для Git — это просто оболочки над консольным Git, и скорость работы гита в этом случае совсем не радует. Есть, кстати, компактный нативный клиент для MSVC, но фактически он умеет только локально коммитить, бранчить и мёрджить.
В Windows 10 для работы с Git очень удобен Bash on Windows. Причём терминал из состава Git for Windows показался более удобным, так что настроил Mintty и перенёс в него старые настройки.

Есть библиотека libgit2, она нативная, компактная и шустрая. Но это C’шная библиотека, а не замена консольному git.

Собственно, эта библиотека (только libgit2sharp) и используется в Git-плагине в Visual Studio.

Привязок у библиотеки ну очень много, вроде все популярные языки с поддержкой вызова C’шных функций есть (не знаю, насколько полные и поддерживаемые). А замены консольному git почему‐то нет, а UI основаны на нём. TortoiseGit вроде имеет настройку «UseLibgit2» (если не ошибаюсь, включена по‐умолчанию), но я как‐то недавно установил tortoisegit, забыв git и он всё равно потребовал git, а не просто заблокировал часть операций, которые libgit2 пока не умеет, вместо этого.

Ну например мне не редко приходится логиниться по ssh на какие-то удаленные машины, а чтобы настроить какой-то GUI для git через ssh придется потратить немало сил. Но т.к. я вполне могу выполнить все необходимые операции только в терминале, то никакой проблемы нет.
Да и локально в 98% случаев я использую только git add, git commit и git push и только для задач которые вовлекают diff использую какой-нибудь гуй. И то не всегда.
У меня git commit — алиас на git commit -v. А gc — алиас на git commit. Так что две буквы и мне видно что я собираюсь закоммитить. Но мне удобно читать nuified diff'ы, да.
Разработка универсального консольного UI, пригодного для автоматизации значительно проще, чем разработка аналогичного GUI. Отсюда и популярность консоли — для многих вещей не существует качественного GUI.
Я активно пользуюсь программами с GUI и активно пользуюсь консолью.

И я не понимаю, почему вам непонятно, по какой причине консоль популярна. Может по той причине, что вы никогда не пользовались ею активно, следовательно нашли способы делать нужные для ВАС вещи без нее. Ведь для того, чтобы чем-то эффективно пользоваться, сперва нужно потратить время и освоить инструмент на уровне выше среднего?

Из аргументов:
Консоль кастомизируется под себя гораздо больше, чем GUI
Консоль автоматизируется гораздо проще, чем GUI
Консоль позволяет объединять разные инструменты гораздо проще, чем GUI
Консоль кастомизируется под себя гораздо больше, чем GUI
Консоль автоматизируется гораздо проще, чем GUI
Консоль позволяет объединять разные инструменты гораздо проще, чем GUI
На практике — да, но теоретически никто не запрещает реализовать все три пункта на нужном уровне в GUI.
Только теоретически. И для этого вы должна быть разработчиком этого продукта. И даже если это опенсорс продукт — не факт, что вы достаточно квалифицированы.

В то время, как консолевские продукты очень легко обернуть любыми скриптами, алиасами, просто если вы знакомы с консолью на средненьком уровне. А если вы разработчик, то можно даже написать любую удобную вам гуишную оболочку, которая будет вызывать консольные команды.
Я например параллельно использую GUI (в read-only режиме), а любого рода изменения через консоль, т.к. имхо через консоль быстрее (если есть конечно уже написанные всякие скрипты/алиасы/и т.д.) + точно знаешь что происходит.

А я специально на консоль переключаюсь, вообще на отдельное окно. Имхо, смена контекста даже помогает сделать более осознанный коммит, чем тыц-тыц в гуи. Пока команды наберу в кли, глядишь подсознание еще какую мыслишку подкинет :)

Сижу праллельно как в консоли, так и интерфейсе. Дифы/ветки/историю смотрю в гуе. Коммичу/бранчуюсь из консоли. Почему? Ну во-первых через гуй нельзя сделать stash, что часто нужно. Более того, нет вообще возможностей сделать что-то окромя стандартного флоу pull/push/merge. Ну тот же cherry-pick. Про сложные вещи типа 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. А так я заметил, что многие практикуют ребейз.

ну тут на вкус и цвет. Мне, например, наоборот не хочется увеличивать количество команд, которые начинаются с g.
ps. Этот способ можно добавить в статью, вместе с ручной правкой .gitconfig, комментарием ниже.

Спасибо за интересный ответ:)

Или просто добавить в домашнюю папку пользователя папку .gitconfig и в ней объявить алиасы
Заголовок спойлера
[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 `('
  1. git log вместо log.
  2. В моей команде нужно экранирование кавычек, так как используется алиас. Вам нужно заменить \" на ", тогда заработает.

Если понравится, просто скопируйте мой команду.

Magic :) Работает, спасибо
git 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)"
добавляю префикс[to_squash]
и переношу этот коммит

В справке git rebase --help написано, что гит умеет менять порядок автоматически, если использовать префикс squash! сообщение коммита

Да, припоминаю такое. Спасибо


Но я не пользуюсь автосквошем, т.к. часто объединяю не в один коммит, а несколько.
Интерактивный ребейз лично мне нужен будет в любом случае, т.к. использую его не только для сквоша:)

Спасибо! Добавил в избранное, буду осваивать.

Комментарии напомнили времена использования Norton Commander.
«я пользуюсь командной строкой», а я пользуюсь Волков Коммандер и нечаянно нажал 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...

Не совсем понял, о чем Вы.
По-моему, оба варианта почти идентичны (вариант с логом, теоретически, может быть проблемным при наличии слияний, когда коммиты до кучи в логе указаны, и то я не уверен).


И выполнение команды дважды работает одинаково.

Извиняюсь, я почему-то перепутал HEAD~1 и HEAD@{1}.

Вы бы добавили это дополнение в статью, маленькое увеличение её полезности.
А то я чуть было не написал абсолютно такой же комментарий, как и выше :)

Для текущей ветки лучше использовать __git_ps1
Для просмотра диффа в индексе git diff --staged там и новые файлы показываются

У меня такой функции нет:( Видимо, слишком старый комплишн-скрипт.


--staged и --cached тождественны, разве нет?

Поделюсь опытом с теми, кто не хочет страдать в терминале и работать с репозиторием вслепую: Git Kraken — единственный удобный GUI для Git под Linux.
А если хочется страдать? А если любовь к консоли очень сильна и безгранична? :)
Тогда поможет только хороший психоаналитик :)
SmartGIT чем не устраивает?
Не находил его. Он платный, похоже? И на Java.
Это я к тому, что делать утверждения «единственно удобный» — очень смело.
SmartGIT бесплатный для личного использования. Да и с каких пор платность — критерий оценки качества?

P.S.
«И на Java.» — это приговор?
«И на Java.» — это приговор?
Ага. Как рак. Может и обойдётся, но в среднем печально…
Плюсую это гражданина. Единственное на маке (и только на на нём), что ручной резолв конфликтов роняет приложение
единственный удобный GUI для Git под Linux

А встроенный в WebStorm? Хотя я все-равно во всех ОС предпочитаю консоль для работы, только конфликты резолвлю в гуи.

Ребейз часто делают перед слиянием с мастером, чтобы история выглядела красиво.


Я делаю интерактивный ребейз после того, как работа над веткой завершена — чтобы коммиты выглядели красиво.

Как большинство здесь, люблю работать в консоли, где так же добавил удобные алиасы для себя. Но хочу обратить внимание на прикольную консольную программку «tig». Очень удобно и наглядно просматривать изменения и делать коммиты.

Если пользуетесь Emacs, рекомендую посмотреть на magit. Крайне удобная штука.

Пробовал. Не понравилось. Использую гит по-старинке

Емакс даже без magit умеет много простых действий c контролем версий и слияниями в рамках встроенного плагина vc и ediff соответственно. vc-diff, vc-version-diff, vc-print-log, ediff-merge-buffers ит.д.
Еще один вариант сменить ветку, не теряя текущих незакоммиченных правок:

git stash
git stash branch new-branch-name
> Как-то раз молодой неопытный программист хотел впервые закоммитить код, а гит открыл ему vim!

Есть пострашнее история:
Как-то раз опытный программист хотел впервые закоммитить код на свежеустановленной системе, а гит открыл ему nano!

Чем нано не угодил? Там есть информация об основных действиях: закрыть, сохранить, вырезать и пр. Имхо, лучше бы по-умолчанию открывался всегда он.


Его можно не любить, но невозможно отрицать, что он лучше всего подходит на роль "общего" редактора.

Мне иногда снится кошмар, что в системе есть только Nano, а на клавиатуре отсутствует Ctrl (с)
а гит открыл ему 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. Если не лень изучать, кочнечно.

уже писали об этом. Отвечаю повторно: про автосквош знаю и намеренно не использую по определенным причинам

Помимо алиасов есть ещё одно клёвое средство сокращения команд — интерактивный git шелл. У него разные названия (git REPL, git shell,...) и несколько реализаций (например gitsh), но суть одна — окно команд, в который вводятся сразу команды git, без слова git перед ними (как в баше). Простейший git shell на баше:

#!/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.

Статья про то, как использовать git со словами «в гите вообще-то есть алиасы, но я без понятия, как их использовать».
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, запомнить пару хоткеев и использовать их гораздо эффективней набора команд.
UFO just landed and posted this here

Года 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

Не хватает упоминания git cherry-pick. Почему-то много разработчиков не знают про эту возможность перенесения любого коммита в любую ветку. Обычно этой командой пользуются для исправления факапов: кто-то случайно влил свой хотфикс в develop и удалил ветку. А в develop-e есть другие задачи и в master его вливать до тестирования нельзя. Выход: перенести покоммитно нужные изменения командой cherry-pick.

Да, совсем забыл про нее. Но на ежедневной основе я ее не использую.


Anyway, добавлю в пост, спасибо

Оффтоп. У нас на одной работе было слово «черрипикнуться». Употребляется в любом переносном смысле, например «там такой код, что черрипикнуться можно».
UFO just landed and posted this here

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

Не знал об этом. Спасибо, буду иметь в виду

Прежде чем писать статью про git, стоит почитать про git

-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 — сборщик мусора, помогает существенно уменьшить занимаемое место на диске
По мне так нормальный путь освоения от GUI к CLI, когда ты уже все, что тебе нужно знаешь и как это сделать быстрее и эффективнее в консоли тоже. А вот начать проще:
Git. Быстрый старт. Назначение и возможности. Урок 1 [GeekBrains], не сочтите за рекламу, но понимать проще.
Sign up to leave a comment.

Articles

Change theme settings