Intro
Основам git мне пришлось научиться на своем первом месте работы (около трех лет назад).
С тех пор я считал, что для полноценной работы нужно запомнить всего-лишь несколько команд:
git add <path>git commitgit checkout <path/branch>git checkout -b <new branch>
И дополнительно:
git push/pullgit merge <branch>git rebase master(а что, можно еще и на другие ветки ребейзить? О_о)
В принципе, я и сейчас во многом так считаю, но со временем волей-неволей начинаешь узнавать интересные трюки.
Вообще, имеет смысл подробнее разузнать о понятиях гита. Лучше подробнее ознакомиться с концепцией коммитов, что такое ветка, что такое тег и пр.
Некоторые настройки для удобной работы
Автодополнение
Удивительно, но не у всех оно есть. Отправляемся в гугл по запросу "git_completion", скачиваем скрипт и действуем по инструкции к нему.
Выводим текущую ветку в строке bash
Данный код нужно добавить в .bashrc. Он со мной с некоторыми изменениями путешествует еще с того самого первого места работы.
function git-current-branch {
git branch --no-color 2> /dev/null | grep \* | colrm 1 2
}
function set_prompt_line {
local BLUE="\[\033[0;34m\]"
# OPTIONAL - if you want to use any of these other colors:
local RED="\[\033[0;31m\]"
local LIGHT_RED="\[\033[1;31m\]"
local GREEN="\[\033[0;32m\]"
local LIGHT_GREEN="\[\033[1;32m\]"
local WHITE="\[\033[1;37m\]"
local LIGHT_GRAY="\[\033[0;37m\]"
# END OPTIONAL
local DEFAULT="\[\033[0m\]"
export PS1="$BLUE\w $LIGHT_RED[\$(git-current-branch)]$DEFAULT \$ "
}
set_prompt_lineДля справки: за внешний вид командной строки баша отвечает переменная PS1. Have fun.
Алиасы
Вообще-то, у гита есть свои алиасы, но я понятия не имею, как их добавлять, т.к. мне лень изучать вопрос и не нравится использование команды git. Я пользуюсь башем:
#
# Git
#
alias current-branch='git-current-branch'
alias git-uncommit='git reset --soft $(git log --format=%H -2 | tail -1)'
alias gst='git status'
alias glog='git log'
alias gcheck='git checkout'
alias gamend='git commit --amend'
__git_complete gcheck _git_checkout
alias gcom='git commit'
__git_complete gcom _git_commit
alias gdiff='git diff'
__git_complete gdiff _git_diff
alias gadd='git add'
__git_complete gadd _git_addОбратите внимание на __git_complete <something> <another>. Эта команда включает гитовое автодополнение для алиаса.
Редактируем сообщения к коммитам в своем любимом текстовом редакторе
Для начала небольшая страшилка, основанная на реальных событиях:
Как-то раз молодой неопытный программист хотел впервые закоммитить код, а гит открыл ему vim!
Да, история произошла со мной. Через несколько часов я смог его закрыть и начал коммитить только с однострочными комментариями через git commit -m.
Git, как и некоторые другие утилиты (crontab, например) проверяют наличие переменной EDITOR.
В конфиге баша (~/.bashrc) можно добавить вот такую строчку:
export EDITOR=<команда, открывающая ваш текстовый редактор>У меня это emacsclient, раньше был subl (Sublime Text). Я не проверял, но я полагаю, что очень важно, чтобы команда не возвращала управление терминалу, пока текстовый файл не будет закрыт.
Сменить ветку, не теряя текущих незакоммиченных правок
Иногда можно просто сменить ветку, но иногда возникают конфликты. Я знаю два варианта:
1) Сделать временный коммит
2) git stash, сменить ветку, ..., вернуть ветку, git stash pop
Первый вариант надежнее, второй удобнее (имхо).
Посмотреть, что я уже наредактировал
git diffПоказывает ваши изменения относительно текущего коммита + stage (важное уточнение). Замечание: в дифф не попадают новые файлы
Посмотреть, что я добавил в stage
git diff --cachedЗамечание: сюда новые файлы попадают.
Удалить лишние файлы
Т.е. файлы, которые не относятся к репозиторию
git clean -df-d— удаляет еще и директории-f— обязательная опция, без нее гит попросту откажется что-либо удалять (уж не знаю, зачем она)
Отменить последний коммит
У меня на это дело есть alias в баше:
alias git-uncommit='git reset --soft $(git log --format=%H -2 | tail -1)'git reset --soft <commit/branch/tag> переносит ветку на коммит, но код не меняет. Разница заносится в stage.
$(<whatever>) — баш выполняет содержимое скобочек и подставляет результат выполнения вместо всего выражения. Например, cat $(ls | tail -1) выдаст содержимое последнего файла из ls.
git log --format=%H -2 выдаст хеши двух последних коммитов.
В общем, вся команда сводится к тому, что текущая ветка переносится на один коммит назад, а изменения, внесенные коммитом, попадают в stage
upd. Как многие справедливо заметили, того же результата можно добиться намного проще: git reset --soft HEAD~ — данная команда берет предыдущий коммит от "головы" и "ресетит" гит на него. В свое оправдание могу сказать, что этому алиасу пара лет и в то время я не знал о том, что такое HEAD и тем более HEAD~
Объединить несколько коммитов
Когда я работаю на своей ветке, периодически я делаю несколько коммитов, которые совсем не имеют смысла по отдельности (а делаю я это просто для того, чтобы коммитить почаще и не терять мысль), поэтому перед вливанием их в мастер имеет смысл их объединить
Решение:
Интерактивный rebase!
git rebase -i masterЭто откроет текстовый редактор, в котором списком будут указаны коммиты.
Вы можете:
- Менять порядок их применения (очень часто пригождается)
- "Сквошить" — объединять несколько коммитов в один
- редактировать — гит будет останавливаться, чтобы вы могли делать изменения с помощью --amend
- менять сообщение — в общем-то, частный случай редактирования
- не применять коммит в принципе
В данной ситуации нужно взять нужные коммиты, расставить их друг за другом и всем, кроме первого, поставить пометку squash.
Вообще я после каждой фичи делаю интерактивный ребейз и смотрю, какие коммиты я хочу объединить, какие переставить для красоты, какие поправить. Это позволяет сохранять красоту в версионировании.
Добавить что-нибудь в предыдущий коммит
git add <forgotten changes>
git commit --amendЕще стоит упомянуть:
git commit --amend --no-edit # Не редактировать сообщение
git commit --amend -m 'my commit message' # работает так, как вы ожидаете Добавить изменения в старый коммит (когда для --amend уже поздно)
Ситуация:
3 коммита назад допустил опечатку, не хочу, чтобы это позорище кто-то увидел отдельным коммитом.
Решение:
Интерактивный rebase!
git rebase -i HEAD~3Лично я в указанной ситуации (а у меня она часто возникает) делаю так: создаю коммит, где в сообщении добавляю префикс[to_squash], заканчиваю работу над веткой, делаю полный ребейз ветки на мастер (git rebase -i master) и переношу этот коммит под тот, к которому данная правка относится, с пометкой s (squash).
Закоммитить части файла по отдельности
Коммиты желательно делать максимально простыми (антоним слову "сложными"). Хочу вот я на гитхабе посмотреть, какая история у файла hello_world.rb, смотрю историю, а там среди прочих коммит "create super-booper feature", в котором в файле hello_world.rb у одной переменной изменено имя, хотя она к фиче совсем отношения не имеет. Лучше было бы наличие коммита "rename variable x to y in hello_world.rb".
Собственно, например, у меня есть код:
def kvadrat(x)
x * x
end
puts kvadrat(n)Мне нужно добавить фичу: выводить удвоенное n. Изи! Но пока я пишу фичу, на автомате меняю некрасивое имя функции.
Пишем:
def square(x)
x * x
end
def double(x)
x + x
end
puts square(n)
puts double(n)Как теперь коммитить? Можно быстро вернуть старое название, закоммитить новый функционал, а потом уже переименовать, но это не всегда уместно, т.к. изменения могут быть достаточно крупными. Можно честно признать, что коммит сложный и написать сообщение в духе "добавил фичу + переименовал метод", но мы ведь стараемся делать коммиты простыми, верно?
Но у гита есть отличная команда:
git add -pОна интерактивная. Поочередно берет изменения кусками (hunk) и спрашивает, что с данным куском делать: игнорировать, добавить, изменить и добавить. Третий вариант достаточно мощный, можно по отдельности добавлять изменения даже в рамках одной строчки (kvadrat(x) + kub(x) => square(x) + cube(x) в 2 коммита).
Я не буду приводить пример, просто зайдите в любой ваш проект с гитом, отредактируйте пару файлов в разных местах и введите эту команду. Иногда лучше один раз попробовать, чем сто раз услышать (при работе команды можно ввести ? для краткой справки)
Заслуживают внимания
git reflog— меня это спасло, когда я случайно удалил ветку, не смерджив и не запушив ееgit rebase -i— в посте указан лишь частный случай применения.git log --graph— просто он забавный. Не знаю, есть ли практическое применение.git cherry-pick <commit>— пытается применить изменения коммита к текущему- Дополните?
Outro
Я указал здесь всего-лишь парочку "трюков" работы с git, но их я использую на ежедневной основе.
Смысл данного поста (помимо того, чтобы ублажить свое ЧСВ и оставить заметку для себя самого) в том, чтобы еще раз подчеркнуть известную (относительно) фразу: Know your tools!.
В гите (да и в принципе во всех ваших инструментах для работы) есть множество деталей, которые могут сделать вашу жизнь проще. Например, я видел репозитории, в которых стояли валидации для коммитов: нельзя было ничего закоммитить, если не проходили тесты или тесты не покрывают изменения.
Комментарии (188)
powerman
30.08.2017 05:16+6Через несколько часов я смог его закрыть
А у меня, примерно в 1993, не было под рукой интернета. Так что я тупо перезагрузил систему. :)
Впрочем, спустя лет 10, мы с vim всё-таки подружились, и с тех пор неразлучны.
mayorovp
30.08.2017 06:05+3Добавлять изменения в старый коммит проще через
git commit --fixup ...с последующимgit rebase -i --autosquash origin/master
RSATom
31.08.2017 09:50А еще можно использовать комментарии коммитов вида `fixup! комментарий коммита в истории`, и при `rebase -i --autosquash` коммит так-же переедет в нужное место.
Этим удобно пользоватья из `gut gui`.ashumkin
31.08.2017 17:50дык,
git commit --fixup sha-1
как раз делает
комментарии коммитов вида
fixup! комментарий коммита sha-1 в истории
KoCMoHaBT61
30.08.2017 06:20+1С гитом лучше работать в zsh, а не в bash. Он (в виде плагина oh_my_zsh) умеет делать автокомплит для бранчей и показывает текущий бранч изкаропки.
Nondv Автор
30.08.2017 08:24+2автокомплит для бранчей
Ну так башевый гит-комлишн тоже это могёт. Какие-то другие преимущества помимо самого bash vs zsh есть?:)
Лично я не пользуюсь zsh по двум причинам:
1) почти везде баш
2) один раз случайно его запустил (зашел в терминал на чужой машине) и испугался
NeoCode
30.08.2017 07:53+23Я вам честно скажу, использую гит равно как и другие системы контроля версий только через GUI оболочки типа TortoiseGit, TortoiseHG или RabbitVCS.
Почему? А потому что я хочу видеть что я там закоммичу. В удобном окне, где можно увидеть список измененных файлов; увидеть список новых файлов и добавить некоторые под контроль версий; откатить изменения в файлах, измененных случайно; добавить игнорируемые по маске в ignores, посмотреть историю изменений и т.д. Все делается сразу в удобном виде в GUI.
Мне не нужно помнить ни одной команды и не одного параметра — все есть в визуальном интерфейсе.
Почему народ так цепляется за консоль мне непонятно… она должна была занять очень узкоспециализированную нишу уже с тех пор, как появились первые TUI тип Нортона под DOS (а было это 20 лет назад). Не говоря уже о GUI.dmirogin
30.08.2017 08:12Я был знаком с программистом, работающим в GUI и потерявшем все изменения по задаче за 4 часа, из-за того что случайно куда-то не туда нажал и не знал что делать дальше.
Я как раз-таки и работаю с гитом из консольки, чтобы полностью иметь контроль над ситуацией. Да, смотреть изменения в консоли, которые ты написал, не очень удобно. Поэтому пользуюсь либо gitk либо средствами, встроенными в IDE.pudovMaxim
30.08.2017 08:22+13Я был знаком с программистом(каждый день в зеркале вижу), который в консоли удалил файлы по ошибке. Как легко и просто восстановить их там? В GUI — это корзина, 2 клика для восстановления.
Консоль хороша, для разруливания нетривиальных ситуаций, но не как ежедневный воркфлоу с переключением контекста.Nondv Автор
30.08.2017 08:33+1Корзина — это не какая-то особенная фича графических интерфейсов:)
И в чем заключается переключение контекста? Смена текстового редактора/IDE одного цвета, на консоль другого?
Вы даже в рамках IDE переключаете контекст: вот ты писали код, а вот вы переставляете руку на мышь (мне, например, очень неприятно это делать) и начинаете кликать по менюшкам версионирования.
vakimov
30.08.2017 18:30Есть github.com/andreafrancia/trash-cli для пользования корзиной через консоль.
michael_vostrikov
30.08.2017 20:54+3Несколько раз встречал такое. Те кто работает в консоли, часто добавляют не глядя через
git add .. Из-за этого иногда бывают коммиты с кучей лишних файлов — временные, бэкапы редакторов итд. А потом реверты, или так и остается мусор. Один раз человек то ли удалил каталог, то ли из другой ветки скопировал, и закоммитил случайно, потом при мерже много конфликтов было.
В GUI сразу видно каждый файл, что надо отмечаешь, что не надо отменяешь. Полный контроль над ситуацией)
DistortNeo
30.08.2017 22:00+2Да, основное преимущество GUI заключается в том, что на экран выводится сразу много информации, а в случае консоли же приходится либо открывать несколько окон (неудобно), либо развивать память.
Ну и, собственно, никто не отменял GUI клиенты с командной строкой. Надо сделать что-то нестандартное — взял и сделал в консоли.
Crandel
31.08.2017 11:37Не раз приходилось чистить за сотрудниками, которые используют эклипс, и временные файли и простыни файлов с путями в гитигнор, вместо *<название файла>, так что тут вопрос внимательности, а не консоль/GUI. В консоли можно добавить все файлы, с расширением например
*.cppи они добавятся со всех вложенных директорий, не надо будет мышкой кликать и выбирать. Так что тут спорное утверждениеNeoCode
01.09.2017 08:40Это вопрос кривизны реализации Эклипса (безотносительно VCS, эта IDE весьма кривая сама по себе). В Tortoise* добавление в ignore list более-менее грамотное: никаких абсолютных путей, предалагается несколько вариантов (например фрагмент относительного пути, например "/Debug/", или расширение "*.obj" или имя файла с расширением). Еще одно преимущество графических утилит — добавляя маску в ignore list, я сразу вижу как исчезает группа файлов в списке кандидатов на добавление; список уменьшается и я обращаю внимание на следующие файлы, которые нужно добавить в игнорируемые или наоборот добавить под контроль версий. То есть прежде чем коммитить я получу готовый список без единого лишнего файла, который я буду видеть заранее.
Crandel
01.09.2017 09:22После Intellij IDEA тоже чистил. Для линукса нету Tortoise, поэтому ваш вариант не может быть использован в моей ситуации вообще
NeoCode
01.09.2017 11:51Для линукса вообще беда: куча DE и файловых менеджеров, под многие из которых просто не реализован доступ к конкретным VCS-GUI-утилитам из контекстного меню. А если и реализован то с какими-то глюками.
Crandel
01.09.2017 13:05-1В линуксе как раз все в порядке с гитом, он там нативный)
Это просто другой вид работы, где можно обойтись без мышки. Я, например, уже пользуюсь GUI в исключительных случаях, только по требованию работодателя. Меня он просто бесит из-за медлительности
serf
30.08.2017 08:19Почему народ так цепляется за консоль мне непонятно…
Помогает лучше понять механизмы работы, что все таки иногда полезно и вероятно некоторым просто любопытно знать детали. За одним кликом мыши в GUI часто скрывается десяток CLI команд.
Ну и статья с использование GUI клиента мотрелась бы глупо.
PS SmartGit получше TortoiseGit будет, хотя бы из-за кроссплатформенности (Java).
Ardanay
31.08.2017 10:16+2Может всё же стоит оценивать инструменты по показателям удобства, ну или количеству фич? Лично мне совершенно без разницы кроссплатформенная тулза или нет, если она есть на моей платформе. Тем более если это всего лишь GUI к гиту.
Nondv Автор
30.08.2017 08:30+2Почему народ так цепляется за консоль мне непонятно
Текстовый интерфейс проще визуального. Именно проще. Не всегда легче.
По той же самой причине во всяких IDE есть куча хоткеев — они банально быстрее и проще, чем тыканье мышкой.
По той же самой причине люди цепляются за вим и имакс — их тяжелее выучить, но в них быстрее работать
norlin
30.08.2017 10:46+1Не хочу начинать холивар, но, справедливости ради, есть третий путь – fuzzy-поиск по всему доступному, пример реализации – Sublime Text. Не нужно заучивать команды/шоткаты, не нужно искать кнопки/менюшки в GUI: один шоткат для вызова меню, далее пишется нужная команда или её часть, enter.
ИМХО, намного быстрее GUI в использовании, намного удобнее и быстрее vim/emacs в плане освоения. К сожалению, больше нигде не встречал настолько интуитивной и полной реализации данной фичи, часто встречаются лишь частичные реализации (например, fuzzy-поиск по файлам проекта, но нет поиска по командам IDE).
edelweard
30.08.2017 12:11+3Все IDE от JetBrains это умеют: там с незапамятных времён есть Find Action (Cmd/Ctrl+Shift+A), который ищет по командам. Действительно очень полезная штука.
norlin
30.08.2017 12:13Не пользовался их IDE, хотя постоянно слышу хвалебные отзывы… Что мне нравится в Саблайм, так то, что там этот подход используется для всего: поиск по командам редактора и плагинов, по файлам проекта, по методам внутри файла; из той же строки поиска доступен переход на конкретную строку файла… Возможно, что-то ещё упустил.
cpud36
31.08.2017 09:23В spacemacs'е есть подобный поиск. Если я не ошибаюсь, за это отвечает или Helm, или fzf.
Nondv Автор
31.08.2017 09:28Не хочу начинать холивар, но emacs умеет это:) можно автокомплитом искать точную команду, можно посмотреть байндинги для определенного сочетания клавиш, можно искать команду по описанию (не гугл-поиск, конечно, но все же). + плагины
Но лично я поиск по описанию использовал только пару раз.
А вообще, теоретически, эта функциональность может быть и в IDE при желании.
Не особо понимаю Atom и Sublime Text, но имакс и вим будут жить еще очень долго, т.к. их функциональность просто никогда не будте реализована в IDE ибо слишком сложно: у вима уникальный принцип работы с текстом, а имакс — это вообще по сути интерпретатор лиспа с встроенным текстовым редактором)norlin
31.08.2017 09:32-1Даже в Atom эта фича реализована не настолько удобно и полно, как в Саблайме. Да и самому Саблайму есть куда стремиться. Например, по-факту, сейчас в Саблайме как минимум 2 разных поиска – по файлам проекта и по коммандам редактора, то есть нужно запомнить, как минимум, два шотката для вызова этих поисков. А их вполне можно было бы объединить в один.
ZyXI
31.08.2017 21:53-1И получить кашу из разнотиповых результатов поиска, которые ещё неплохо бы отображать по?разному? Вы часто не знаете, ищете ли вы файл или команду? Поиск по тегам, именам файлов и их содержимому иногда имеет смысл объединить: получится что?то для варианта «коллега упомянул о существовании понятия X, где бы мне посмотреть что это такое?». Вроде то ли в sublime, то ли ещё где их реально объединили. Но искать файл и команду в одном поиске — зачем?
DmitriyH
30.08.2017 09:00+5К списку оболочек можно добавить SourceTree от Atlassian.
fareloz
30.08.2017 12:04Поддерживаю. Единственный известный мне клиент для Windows, который адекватно работает с Git-svn (уж приходится пользоваться такими извращениями). Недавно Tower for Win выпустили, но он не умеет(
DistortNeo
30.08.2017 15:29+1У Git под Windows есть одна проблема: отсутствие компактных нативных портов. Git работает исключительно под MinGW и тянет с собой все её кишки — в итоге получается больше 5000 файлов и 200 мегабайт. А Windows мелкие файлы очень не любит.
Если для SVN, HG все клиенты нативны, компактны и шустры, то все GUI для Git — это просто оболочки над консольным Git, и скорость работы гита в этом случае совсем не радует. Есть, кстати, компактный нативный клиент для MSVC, но фактически он умеет только локально коммитить, бранчить и мёрджить.HSerg
31.08.2017 09:23В Windows 10 для работы с Git очень удобен Bash on Windows. Причём терминал из состава Git for Windows показался более удобным, так что настроил Mintty и перенёс в него старые настройки.
ZyXI
31.08.2017 22:08Есть библиотека libgit2, она нативная, компактная и шустрая. Но это C’шная библиотека, а не замена консольному git.
DistortNeo
31.08.2017 22:27Собственно, эта библиотека (только libgit2sharp) и используется в Git-плагине в Visual Studio.
ZyXI
31.08.2017 23:10Привязок у библиотеки ну очень много, вроде все популярные языки с поддержкой вызова C’шных функций есть (не знаю, насколько полные и поддерживаемые). А замены консольному git почему?то нет, а UI основаны на нём. TortoiseGit вроде имеет настройку «UseLibgit2» (если не ошибаюсь, включена по?умолчанию), но я как?то недавно установил tortoisegit, забыв git и он всё равно потребовал git, а не просто заблокировал часть операций, которые libgit2 пока не умеет, вместо этого.
michalemiriti
30.08.2017 11:54Ну например мне не редко приходится логиниться по ssh на какие-то удаленные машины, а чтобы настроить какой-то GUI для git через ssh придется потратить немало сил. Но т.к. я вполне могу выполнить все необходимые операции только в терминале, то никакой проблемы нет.
Да и локально в 98% случаев я использую только git add, git commit и git push и только для задач которые вовлекают diff использую какой-нибудь гуй. И то не всегда.
asm0dey
30.08.2017 14:13У меня git commit — алиас на git commit -v. А gc — алиас на git commit. Так что две буквы и мне видно что я собираюсь закоммитить. Но мне удобно читать nuified diff'ы, да.
DaylightIsBurning
30.08.2017 15:48+1Разработка универсального консольного UI, пригодного для автоматизации значительно проще, чем разработка аналогичного GUI. Отсюда и популярность консоли — для многих вещей не существует качественного GUI.
saboteur_kiev
30.08.2017 16:07Я активно пользуюсь программами с GUI и активно пользуюсь консолью.
И я не понимаю, почему вам непонятно, по какой причине консоль популярна. Может по той причине, что вы никогда не пользовались ею активно, следовательно нашли способы делать нужные для ВАС вещи без нее. Ведь для того, чтобы чем-то эффективно пользоваться, сперва нужно потратить время и освоить инструмент на уровне выше среднего?
Из аргументов:
Консоль кастомизируется под себя гораздо больше, чем GUI
Консоль автоматизируется гораздо проще, чем GUI
Консоль позволяет объединять разные инструменты гораздо проще, чем GUIDaylightIsBurning
30.08.2017 16:20-1Консоль кастомизируется под себя гораздо больше, чем GUI
На практике — да, но теоретически никто не запрещает реализовать все три пункта на нужном уровне в GUI.
Консоль автоматизируется гораздо проще, чем GUI
Консоль позволяет объединять разные инструменты гораздо проще, чем GUIsaboteur_kiev
30.08.2017 18:24+2Только теоретически. И для этого вы должна быть разработчиком этого продукта. И даже если это опенсорс продукт — не факт, что вы достаточно квалифицированы.
В то время, как консолевские продукты очень легко обернуть любыми скриптами, алиасами, просто если вы знакомы с консолью на средненьком уровне. А если вы разработчик, то можно даже написать любую удобную вам гуишную оболочку, которая будет вызывать консольные команды.
ivanzoid
30.08.2017 16:44Я например параллельно использую GUI (в read-only режиме), а любого рода изменения через консоль, т.к. имхо через консоль быстрее (если есть конечно уже написанные всякие скрипты/алиасы/и т.д.) + точно знаешь что происходит.
tommyangelo27
31.08.2017 09:23А я специально на консоль переключаюсь, вообще на отдельное окно. Имхо, смена контекста даже помогает сделать более осознанный коммит, чем тыц-тыц в гуи. Пока команды наберу в кли, глядишь подсознание еще какую мыслишку подкинет :)
PsyHaSTe
01.09.2017 16:35Сижу праллельно как в консоли, так и интерфейсе. Дифы/ветки/историю смотрю в гуе. Коммичу/бранчуюсь из консоли. Почему? Ну во-первых через гуй нельзя сделать stash, что часто нужно. Более того, нет вообще возможностей сделать что-то окромя стандартного флоу pull/push/merge. Ну тот же cherry-pick. Про сложные вещи типа
git branch -a --contains 9263de3a03cb8b8b79d59fda1883efe9cf7f33e1молчу, очень мало гуёв предлагают такой функционал.
Как финал, у меня стоят гит хуки которые на переключение веток и пулл запускают вебпак. Когда я точно знаю, что ничего не менялось (git checkout -b например), то я в консоли могу сделать ctrl+c и продолжить заниматься своими делами, гуй же виснет, потому что он не знает, что гит хуки запускает и их можно приостановить.
Такой вот флоу у меня. Особого переключения контекста не больше, чем между разными окнами в IDE.
Ivanq
30.08.2017 08:19+4Вообще-то, у гита есть свои алиасы, но я понятия не имею, как их добавлять, т.к. мне лень изучать вопрос.
Добавлять алиасы в гит нужно командой:
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()Nondv Автор
30.08.2017 08:38Одна из причин, по которым я не хочу разбиратся с гитовыми алиасами — мне все равно придется писать
git <something>.
Т.к. автокомплит настраивается и для башевых алиасов, я предпочту
gdiff, а неgit d(не люблю нажимать пробел без причины)
Мне нравится граф в bitbucket. А так я заметил, что многие практикуют ребейз.
myxo
30.08.2017 10:20ну тут на вкус и цвет. Мне, например, наоборот не хочется увеличивать количество команд, которые начинаются с g.
ps. Этот способ можно добавить в статью, вместе с ручной правкой .gitconfig, комментарием ниже.
dmirogin
30.08.2017 10:15Или просто добавить в домашнюю папку пользователя папку .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"
zagayevskiy
30.08.2017 15:55Угу, как-то я подошёл к коллеге, у которого "гит не сохраняет мои изменения". Говорю — показывай, как делаешь. А он начинает мне такую вот абракадабру писать. Было печально.
PsyHaSTe
01.09.2017 16:40Увы, у меня магия не работает:
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 `('
Ivanq
01.09.2017 16:53+1git logвместоlog.- В моей команде нужно экранирование кавычек, так как используется алиас. Вам нужно заменить
\"на", тогда заработает.
Если понравится, просто скопируйте мой команду.
PsyHaSTe
01.09.2017 17:09Magic :) Работает, спасибо
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)"
Deosis
30.08.2017 08:20+2добавляю префикс[to_squash]
и переношу этот коммитВ справке git rebase --help написано, что гит умеет менять порядок автоматически, если использовать префикс squash! сообщение коммита
Nondv Автор
30.08.2017 08:35Да, припоминаю такое. Спасибо
Но я не пользуюсь автосквошем, т.к. часто объединяю не в один коммит, а несколько.
Интерактивный ребейз лично мне нужен будет в любом случае, т.к. использую его не только для сквоша:)
fishca
30.08.2017 09:30+3Комментарии напомнили времена использования Norton Commander.
«я пользуюсь командной строкой», а я пользуюсь Волков Коммандер и нечаянно нажал F8 и все удалил. :DNondv Автор
30.08.2017 09:32"я что-то нажала и все исчезло"
Я во время написания статьи, похоже, задел cmd+z, и у меня часть текста испарилась. Долго искал, что и где
ploop
30.08.2017 09:51+4Кстати, один из недостатков графических интерфейсов. Зацепил клавиатуру, что-то сделалось, а что не знаешь. В консоли хоть видно, что начудил.
yse
30.08.2017 10:06+3alias git-uncommit='git reset --soft $(git log --format=%H -2 | tail -1)'
а не проще как-нибудь вот так:alias git-uncommit='git reset --soft HEAD~1'Nondv Автор
30.08.2017 10:10+3Абсолютно!
Еще проще:
alias git-uncommit='git reset --soft HEAD~'
(единица опциональна)
Этому алиасу уже пара лет. Работает — не трогаю:)
mayorovp
30.08.2017 11:06Попробуйте с таким алиасом сделать uncommit два раза подряд :-)
С другой стороны, такой алиас, в отличие от варианта с git log, умеет отменять amend...
Nondv Автор
30.08.2017 11:58Не совсем понял, о чем Вы.
По-моему, оба варианта почти идентичны (вариант с логом, теоретически, может быть проблемным при наличии слияний, когда коммиты до кучи в логе указаны, и то я не уверен).
И выполнение команды дважды работает одинаково.
basilisk
30.08.2017 15:50+1Вы бы добавили это дополнение в статью, маленькое увеличение её полезности.
А то я чуть было не написал абсолютно такой же комментарий, как и выше :)
Yavanosta
30.08.2017 10:21Для текущей ветки лучше использовать __git_ps1
Для просмотра диффа в индексе git diff --staged там и новые файлы показываютсяNondv Автор
30.08.2017 12:07У меня такой функции нет:( Видимо, слишком старый комплишн-скрипт.
--stagedи--cachedтождественны, разве нет?lightsource
31.08.2017 17:27Да, они одинаковы. В документации написано, что
--staged— это синоним--cached. Вопрос предпочтения.
VioletGiraffe
30.08.2017 10:50Поделюсь опытом с теми, кто не хочет страдать в терминале и работать с репозиторием вслепую: Git Kraken — единственный удобный GUI для Git под Linux.
Aries_ua
30.08.2017 11:27А если хочется страдать? А если любовь к консоли очень сильна и безгранична? :)
AllexIn
30.08.2017 12:40SmartGIT чем не устраивает?
VioletGiraffe
30.08.2017 12:43Не находил его. Он платный, похоже? И на Java.
AllexIn
30.08.2017 12:45+1Это я к тому, что делать утверждения «единственно удобный» — очень смело.
SmartGIT бесплатный для личного использования. Да и с каких пор платность — критерий оценки качества?
P.S.
«И на Java.» — это приговор?ploop
30.08.2017 14:34+4«И на Java.» — это приговор?
Ага. Как рак. Может и обойдётся, но в среднем печально…
inoyakaigor
30.08.2017 17:16Плюсую это гражданина. Единственное на маке (и только на на нём), что ручной резолв конфликтов роняет приложение
TheShock
30.08.2017 23:05единственный удобный GUI для Git под Linux
А встроенный в WebStorm? Хотя я все-равно во всех ОС предпочитаю консоль для работы, только конфликты резолвлю в гуи.
Aries_ua
30.08.2017 11:26+1Как большинство здесь, люблю работать в консоли, где так же добавил удобные алиасы для себя. Но хочу обратить внимание на прикольную консольную программку «tig». Очень удобно и наглядно просматривать изменения и делать коммиты.
visortelle
30.08.2017 11:52Если пользуетесь Emacs, рекомендую посмотреть на magit. Крайне удобная штука.
parrker
30.08.2017 12:03Еще один вариант сменить ветку, не теряя текущих незакоммиченных правок:
git stash git stash branch new-branch-name
dimcha
30.08.2017 12:23+3> Как-то раз молодой неопытный программист хотел впервые закоммитить код, а гит открыл ему vim!
Есть пострашнее история:
Как-то раз опытный программист хотел впервые закоммитить код на свежеустановленной системе, а гит открыл ему nano!Nondv Автор
30.08.2017 12:28+4Чем нано не угодил? Там есть информация об основных действиях: закрыть, сохранить, вырезать и пр. Имхо, лучше бы по-умолчанию открывался всегда он.
Его можно не любить, но невозможно отрицать, что он лучше всего подходит на роль "общего" редактора.
Chiron
30.08.2017 14:52+1Мне иногда снится кошмар, что в системе есть только Nano, а на клавиатуре отсутствует Ctrl (с)
TheShock
30.08.2017 23:07а гит открыл ему nano!
nano — это ладно, а как-то мне гит vim открыл, пришлось новый комп покупать.
kstep
30.08.2017 12:53+2Вообще-то, у гита есть свои алиасы, но я понятия не имею, как их добавлять, т.к. мне лень изучать вопрос.
Уже за это хочется поставить минус. Лень прочитать документацию — зачем вообще тогда берёшься за инструмент? Эта инфа есть в
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. Если не лень изучать, кочнечно.Nondv Автор
30.08.2017 16:01уже писали об этом. Отвечаю повторно: про автосквош знаю и намеренно не использую по определенным причинам
Cheater
30.08.2017 13:34Помимо алиасов есть ещё одно клёвое средство сокращения команд — интерактивный git шелл. У него разные названия (git REPL, git shell,...) и несколько реализаций (например gitsh), но суть одна — окно команд, в который вводятся сразу команды git, без слова git перед ними (как в баше). Простейший git shell на баше:
#!/bin/bash
while true; do
echo -n "git shell# ";
read command;
git $command;
done
iShatokhin
30.08.2017 14:52git stash, сменить ветку, ..., вернуть ветку, git stash pop
Опасно! У нас так один разработчик случайно потерял все, что он сделал за день, теперь использует:
git stash apply
CaptainFlint
30.08.2017 19:53А как потеря-то произошла?
iShatokhin
30.08.2017 20:00Перемещался по веткам, что-то срочно правил, возвратился на свою, применил stash не там, откатился на правильную ветку… а в stash уже пусто.
firegurafiku
30.08.2017 23:55+1Содержимое squash ничем принципиально не отличается от обычного коммита (кроме того, что этот squash-коммит обычно недостижим из именованных веток). В этой ситуации нужно было просмотреть вывод
git reflog, найти там хеш нужного коммита и вернуть его содержимое в рабочую копию при помощиgit checkout.
gro
30.08.2017 15:35+4Статья про то, как использовать git со словами «в гите вообще-то есть алиасы, но я без понятия, как их использовать».
exvayn
30.08.2017 16:02+1alias glod='git log --oneline --decorate'
забирайте! бесплатно без регистрации
dregenor
30.08.2017 16:03oh-my-zsh — просто ставлю по дефолту везде (если приходится что-то под виндой делать тут babun неплох) потому что подсказка по истории операций на основе ввода это просто божественно.
я могу обновить последний коммит в 3 нажатия на клавиатуру "g" + up + enter,
а если операция не из последних то нажать up несколько раз, или уточнить запрос.
Про алиасы к гиту
https://github.com/GitAlias/gitalias
я чаще всего пользую g st, и g ca (commit --amend)
С момента как перешел с Win на lin 6 лет назад (а потом и на mac) — я обожаю консоль.
Особенно я ее люблю когда работаю с ноута лежа на диване, потому что клавиатура всегда клавиатура а тачпад совсем не мышка, целиться не так удобно.
Мне вообще кажется что владение консолью(также как и английским) является обязательным для программиста(хотяб на уровне базовых команд).
У меня на одной из работ тимлид был из gui-любов, а весь остальной отдел из маководов -консольводов… холивар не стихал — трудно ему приходилось, интересно он осознал или продолжает целиться мышкой в кнопочки.
inoyakaigor
30.08.2017 17:14+21) Сделать временный коммит
2) git stash, сменить ветку, ..., вернуть ветку, git stash pop
А потом забыть про всё это и воспользоваться git worktree
Cosmodark
30.08.2017 18:03+1git 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
Так же дает очень интересный эффект с подсветкой, наименованием коммита, временем и автором.
michael_vostrikov
30.08.2017 21:50-2создаю коммит, где в сообщении добавляю префикс[to_squash], заканчиваю работу над веткой, делаю полный ребейз
У меня сложилась такая система для ненужных коммитов.
'.'— дополнить предыдущий коммит, используется вместо amend если могут понадобиться изменения с прошлого шага — просто посмотреть или откатить только их.
'.. <message>'— сделать squash с одним из предыдущих.
'... <message>'или'. <message>'— временный коммит, который надо будет отредактировать — разделить на несколько, пропустить, или просто сообщение поправить.
maydjin
31.08.2017 02:01+1Может кто-то уже обратил внимание(не читал все комменты). Однако код ниже не выглядит очень хорошо:
function git-current-branch { git branch --no-color 2> /dev/null | grep \* | colrm 1 2 }
Можно сделать например так:
git rev-parse --abbrev-ref HEADNondv Автор
31.08.2017 09:22"Работает — не трогай".
Этот код в моем конфиге уже 3 года. Как часто Вы рефакторите свои конфиги?:)
По существу: спасибо, но если вы выполните эту команду на каком-то отдельно взятом коммите (не ветке или теге), то выводом будет просто
HEAD. Уверен, можно это дело усложнить и решить вопрос, но зачем?
horror_x
31.08.2017 02:05+1По моему, в IDE удобно только логи и диффы смотреть. Для всего остального набрать команду намного проще, чем искать какую-то кнопку и пытаться угадать как реально производимое действие легло на фантазии разработчика GUI.
Если вы постоянно работаете с конкретной IDE, запомнить пару хоткеев и использовать их гораздо эффективней набора команд.
kloppspb
31.08.2017 03:16Ага. Даже не представляю, насколько можно не знать и не любить свою IDE, чтобы «искать какую-то кнопку» и что-то там угадывать.
Rabajaba
31.08.2017 09:15+1Года 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
Gremglee
31.08.2017 09:15+1Не хватает упоминания git cherry-pick. Почему-то много разработчиков не знают про эту возможность перенесения любого коммита в любую ветку. Обычно этой командой пользуются для исправления факапов: кто-то случайно влил свой хотфикс в develop и удалил ветку. А в develop-e есть другие задачи и в master его вливать до тестирования нельзя. Выход: перенести покоммитно нужные изменения командой cherry-pick.
Nondv Автор
31.08.2017 09:16Да, совсем забыл про нее. Но на ежедневной основе я ее не использую.
Anyway, добавлю в пост, спасибо
michael_vostrikov
31.08.2017 10:01Оффтоп. У нас на одной работе было слово «черрипикнуться». Употребляется в любом переносном смысле, например «там такой код, что черрипикнуться можно».
Enione
31.08.2017 09:16-12Я так понимаю что афтар тупо написал консольный зашквар по-поводу какой он имхо задрот, ибо ебошит Git в командной строке. Не читал +100500 коментов в коим ему тыкали носом что енто уже перебор, но я так понимаю что это было написано ради только букв и очередного поста… Подайте WinAPI сюды! А так, коли есть проблемы — ставь tortoisegit.org. Направь людей на путь истенный и фришный. Не понимаю зачем вообще всё это. В век когда всё написано и переписано и с всякими кнопочками долбаться с CMD? Может кто просвестит? И на перёд — да конфузы бываю в Git-е разные, никто не мешает эти конфузы решать. Но на статью это не тянет. RTFM!
Alex_Kostikov
31.08.2017 15:21-1Прежде чем писать статью про 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.
Зато, хоть, вроде не перевод! ;)Nondv Автор
31.08.2017 15:22Вы, конечно, большой молодец, что скопировали кусок мануала, но ничего нового мне не сообщили (Вы удивитесь, но я читал мануал по гиту, а не методом тыка узнавал какие-то фичи) :)
Ответа на мой вопрос "зачем" этот кусок так и не дает.
ashumkin
31.08.2017 18:20я думаю, потому что команды не должны быть деструктивными, если заданы без параметров
раньше, (до 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 — автор патча
KeyJoo
01.09.2017 17:29+1Кто где находит инфу по Гиту. Всегда есть >> Первоисточник + Альтернативы…
Но команды, методологии, способы, тулзы, где мы про них не узнали — всегда буду полезны.
Автору спасибо за статью.
masterspline
Я бы предложил начать знакомство с git с книги про git. Для начала (и уверенной работы с git) оттуда достаточно прочитать первые 3 главы.
Amareis
Собственно, моя первая работа началась с изучения этой книги. Потом пару месяцев активно применял полученные знания, периодически в неё подглядывая и все фичи из поста отложились в подкорке.
Но должен заметить что та же Idea сокращает явную работу с гитом до минимума. Коммиты, пуши, ребазы, чекауты, новые ветки, стэши… Да и CVS>Log очень удобен, когда явно видишь все коммиты, их взаимосвязи и изменения в каждом из них. Единственное, чего не хватает — add -p, ну или я ещё не нашёл как оно делается.
pmcode
По моему, в IDE удобно только логи и диффы смотреть. Для всего остального набрать команду намного проще, чем искать какую-то кнопку и пытаться угадать как реально производимое действие легло на фантазии разработчика GUI.
Amareis
Ну вообще отчасти это верно, просто я эти команды набираю в менюшке, выскакивающей по Ctrl+Shift+A, где доступны вообще все действия IDE. Ну и пока вроде всё действует по методу наименьшего удивления, так что угадывать ничего не приходится.
Ну и сохранение пароля жизнь упрощает, хотя оно конечно и в консоли настраивается. В общем-то, главный плюс IDE в том, что не происходит никакого переключения контекста, даже терминал открытым держать не надо.
psFitz
В idea есть вкладка "терминал") в ней удобнее всего с гитом работать.
Amareis
Ну да, ей я всегда и пользуюсь. Только всё равно это переключение в другую парадигму, тут не так важно, в отдельном окне терминал или в том же.
kloppspb
Какой пароль? Ключи же :)
monah_tuk
Соглашусь, но отчасти: в QtC, к примеру, мне удобно:
Ну и диффы и история, куда без этого.
varnav
В Tortoise Git для отправки изменений нужно сделать 3 клика мышью.
В командной строке нужно для того-же самого 32 нажатия клавиши.
Не знаю кому 32 нажатия проще чем 3.
KvanTTT
Ну вообще говоря еще сообщение коммита нужно на клавиатуре набирать.
varnav
Не забыл, но это одинаковое кол-во нажатий как в консоли, так и без консоли.
Кстати можно выбрать из шаблонов и даже надиктовать, не всё так однозначно.
Cheater
Помимо одинакового кол-ва нажатий, в GUI есть ещё затраты на переключение с клавиатуру на мышь и обратно. Про шаблоны и надиктовать — используйте нормальный $GIT_EDITOR (vim, emacs) вместо дефолтного vi и у вас будут и шаблоны и что угодно, ограниченное только вашей фантазией в скриптовании редактора. В GUI в любом случае у вас будет банальная textarea.
varnav
Это всё теория. На практике я в любом случае 3 клика сделаю быстрее чем вы введёте несколько команд, независимо от алиасов, табов и прочего.
Проверял неоднократно.
Valery4
Даже и не знаю.
У меня это выглядит таким образом:
Переколючаемся в консоль (Если я в этот момент в IDE от Intellij, то клац по кнопке терминала, если в Vim — то Ctrl-Z). — Одна секунда максимум.
Потом gca и ввод.
Пишем сообщение и выходим. (помимо сообщения тоже секунда максимум)
Так что по времени это будет не дольше чем три клика. Вопрос привычек и удобства.
P.S. Я пытаюсь показать альтернативный сценарий, а не переубедить. Вы же мышкой всё равно продолжите, а я в консоли.
saboteur_kiev
Это у вас теория. Если вы пользуетесь например энтерпрайз битбакетом, то пока откроется страничка, пока вы сделаете пулл реквест, пока выпадающий список считает новые бренчи… А в консоли точное название бренча написал, команду куда мержить написал, нажал enter и пошел делать другую задачу.
varnav
У вас видимо либо узкий интернет-канал, либо тормозные рабочие станции.
saboteur_kiev
Либо энтерпрайз, где оно вот так.
varnav
Кроме того, при чём тут страничка?
saboteur_kiev
У вас есть десктопный GUI к битбакету, дженкинсу, тимсити?
Из консоли можно запускать необходимые действия с минимальными навыками продвинутого юзера. Как это все автоматизировать/ускорить в GUI?
Free_ze
Не особо обоснованный аргумент. Очевидно, что алиас будет быстрее нескольких кликов с диалогами и ожиданием завершения команд. CUI по своей природе кастомизируется лучше, чем GUI.
saboteur_kiev
«На практике я в любом случае 3 клика сделаю быстрее чем вы введёте несколько команд, независимо от алиасов, табов и прочего.»
У меня вопрос. У вас вообще скорость набора хотя бы 200-300 символов в минуту есть? Три клика в разных местах экрана это не тройной клик.
А вызов алиаса может быть например 1-2 буквы, таб (автодополнение) и enter, что даже на слух воспринимается как короткая трель.
varnav
А я то тут при чём? Я ж не сам с собой соревновался.
Free_ze
Чтобы добавить хоть чуточку объективности в ваш эксперимент (=
a1ien_n3t
Алиасы и авто дополнение в консоли никто не отменял. А вы забыли про то что мышку еще нужно до этих пунктов довести. Так что не все так однозначно.
varnav
Я соревновался как-то специально, и всегда выигрывал, с отрывом причём.
jsirex
Для стандартных действий — да, кнопку нажать быстрее. Для более менее нестандартных ситуаций — нет. И тут начинается: из gui это сделать вообще можно? Есть там такая фишка? А где? Сколько минут будете лазить пока найдёте?
Use case:
1. Вы что-то там себе в ветке fix-foo делали
2. Потом переключились на dev и продолжили работу.
3. А теперь вас попросили пушнуть ветку fix-foo только под нормальным именем, типа bug/proj-1567-fix-foo
Из консоли это можно сделать одной командой и не будет путаницы в «понимании поведения интерфейса».
В итоге бывает проще выучить 1 инструмент (git cli), чем несколько. Конечно, это не отменяет того, что GUI — удобная штука.
Кстати, пункт 4: пушнуть ветку fix-foo без последнего коммита (потому, что там ерунда) — это всё ещё одна команда.
varnav
И в чём проблема?
Два клика, никакой путаницы.
Valery4
А зачем все?
demobin
Интересно откуда цифра 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 вызивает боль). И в этом нет ничего плохого, но обобщать подобный опыт не стоит.
michael_vostrikov
Это не просто 22, их надо проверять, чтобы все правильно было. Это дополнительное внимание и время на исправление если ошибся, особенно в середине. В GUI значения уже подставлены, если команда стандартная, то просто тыкаешь в район кнопки. Если не попал, то ничего не произойдет.
1 и 2 есть в TortoiseGit. Там вообще удобный интерактивный ребейз. Есть команда «Rebase onto this» для коммита, не надо отдельную ветку создавать.
3 можно и потерпеть, никто не спорит, что основные команды надо знать. Но локальной работы все-таки больше, так что лучше пользоваться тем, что удобнее для нее.
ZyXI
А режим редактирования истории без перенесения есть? Когда возникла такая задача для консоли был написан alias
git ri:Он длинный, но позволяет работать как
hg histedit.Проблемы, решаемые таким вариантом:
git riвы не получите внезапно неработающие изменения, потому что вmasterнемного поменяли API чего?то, использующегося в новом коде, а слияния от такого конфликты обычно не ловит.Если забыть про 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, если он всё же понадобится, немного сложнее.michael_vostrikov
Так не надо ребейзить на master. Надо ребейзить на начало своей ветки. Тогда эти проблемы в принципе не появляются.
Ребейз в TortoiseGit работает через cherry-pick. Поэтому все полностью контролируется TortoiseGit. Любой коммит можно отредактировать как нужно через графические инструменты, и сообщение и файлы.
Не вижу большого смысла в возможности добавлять свои команды в GUI. Для сложных вещей есть консоль. А GUI нужен для облегчения повседневной работы.
ZyXI
В консоли по?умолчанию
rebaseидёт на master (точнее, на что?то настраиваемое, но это «что?то» — ветка, см. второй абзац раздела «DESCRIPTION»git help rebase). А alias делает именно это: rebase на начало ветки (пока нет слияний, rebase на последнее слияние, если есть). В tortoisegit есть простой способ найти эту точку?А про «сложные вещи»: если консоль непривычна, то сложные вещи будет сделать очень сложно. А как она будет привычна, если используется в основном GUI?
michael_vostrikov
В TortoiseGit выпадающие списки со значением по умолчанию. Там не надо ничего искать, всё в интерфейсе показывается.
Кстати, в статье есть команда
git rebase -i HEAD~3. Я так понимаю, она берет последние 3 коммита. Зачем что-то искать, если можно указать?Сложные вещи делаются редко, можно и потерпеть.
ZyXI
git riне требует знания количества коммитов в той части истории, которую нужно изменить, аgit rebase -i HEAD~3требует. Когда их число достигает хотя бы пяти (а я легко могу сделать такую серию только изfixup!изменений) считать становится уже неудобно; если PR большой, то опечатки приходится исправлять и за десяток полноценных коммитов.А каким именно образом указывается основание для rebase в tortoisegit я не знаю, пока что он мне был нужен исключительно чтобы сделать
git clone, в случаях, когда мне неохота ставить babun (сборка на основе cygwin), в котором git также есть (для новых проектов, за редким исключением, всегда использую mercurial). В консоли приходится искать, или отряжать скрипт, чтобы он искал. Если в tortoisegit такой скрипт написали за вас, то это отлично.michael_vostrikov
Там нет скрипта, по крайней мере специально для этого. Есть лог коммитов, в контекстном меню коммита пункт "Rebase onto this". Ничего искать не надо, что хотим то и указываем.
А
git rebase -i abcdefне требует.ZyXI
Т.е. всё же надо искать, где начиналась ваша ветка, или хотя бы предка первого изменяемого изменения. Журнал не в тему: искать удобнее и несколько быстрее, но с
git riничего искать не нужно.git rebase -i abcdef, внезапно, сделает rebase, если изменения не основаны на abcdef. А нужно изменение истории без rebase.michael_vostrikov
Что значит "изменение истории без rebase"? У вас команда заканчивается на
git rebase --interactive "$o" "$@".Зачем указывать abcdef, если вам не нужно делать на него rebase? По ошибке? Вот поэтому я предпочитаю GUI, там не надо это за каждым символом следить. Ну и да, разговор был что "нужно знать количество коммитов". А это не так.
Почему не в тему, если вопрос в том, что искать сложно? В консоли сложно, в GUI лог и так постоянно используется. Тыкнуть мышкой в коммит это недолго. У вас была проблема, вы ее решили. А когда лог под рукой, такой проблемы не возникает.
ZyXI
И что, что заканчивается? У git полно универсальных команд: тот же checkout берёт на себя и создание ветки, и переключение на ветку с обновлением рабочего каталога, и обновление каталога без переключения, и частичное применение изменений из другой ветки. У mercurial это всё разные команды (правда, последнего в таком виде как у git нет, или требуется plugin). Изменение истории — это у меня было
Я хочу объединить
D'иD'':. Но по?умолчанию
git rebase -i masterсделаетВзамен вы получили постоянно висящее окно (или лог будет настолько же «под рукой» как у меня в терминале), специализированное практически под одну задачу. А вопрос был не в том, как бы искать попроще, а в том как бы не искать вообще.
michael_vostrikov
Зачем писать
В терминале выводится только текст, который можно только посмотреть. В графическом интерфейсе из этого окна можно выполнить кучу разных команд. Поэтому не «специализированное практически под одну задачу», а совсем наоборот.git rebase -i master, если можно написатьgit rebase -i s?Насчет поиска в GUI. Что в этом сложного?
ZyXI
В терминале можно пускать компиляцию, тесты, посмотреть результаты с travis, … А в tortoisegit только git. Впрочем, это только альтернативный workflow: терминал с tmux и Vim плюс браузер в принципе заменяются на браузер+IDE+tortoisegit, особенно учитывая, что в IDE терминал часто есть.
А сложное: сравните
git ri<CR>, дальше что?то ещё.mayorovp
В одном терминале нельзя увидеть все это одновременно.
Та же компиляция крупных проектов своим логом "затирает" всю информацию на терминале.
Nondv Автор
Ознакомьтесь с такой штукой как tmux.
Можно делить терминал на "панели", переключаться между "вкладками" (там они называются окна), можно листать вывод, копировать, вставить и, внимание (!!), все это без использования мыши и с помощью сочетаний клавиш emacs/vim (полагаю, что вимовские намного удобнее в контексте тмукса, но я emacs-юзер, поэтому пользуюсь ими).
Даже если Вам не нужны эти фичи, то все равно ознакомьтесь. Это серверное приложение и можно восстанавливать сессии. Очень удобно, если вы работаете по ssh и получаете обрыв связи
michael_vostrikov
Так пускайте, кто мешает) Я говорю конкретно про использование git.
Я к тому, что это настолько сложно, что нужно стремиться вместо этого писать кастомные скрипты в консоли? Мне вот неохота прогонять 10 коммитов с начала ветки, если надо поменять только 2 последних. Не говоря уже о том, что у вас гораздо больше времени уйдет на редактирование файла для ребейза. Это экономия на спичках.
Ну и да. "Переключиться на терминал, нажать G, нажать I, нажать T, нажать Space, нажать R, нажать I, проверить, что нет опечаток, нажать Enter". Обнаружить опечатку "get", переместить туда курсор, убрать символ, добавить символ, или нажать Ctrl+C и набрать все заново. А потом в "git log" проверить, все ли правильно получилось, не забыл ли чего.
ZyXI
Нет, именно это — не настолько. Я к консоли «стремлюсь», потому что их там можно писать, и потому что часть вещей там универсальна: к примеру, когда вы не знаете точного вида регулярного выражения проще и быстрее искать что?то в
git log --patch | lessилиhg log -v --patch | less(Про автоматически используемый git’ом pager не говорите, я их всегда отключаю.), чем, во?первых, вспоминать что поиск по патчам в одном местеgit log -G, в другомhg grep, во?вторых, учитывать, что регулярные выражения в одном месте вроде POSIX ERE, а в другом, кажется, Python re, в?третьих, тратить время на перезапуск — поиск в less быстрее, чем повторный запуск с необходимостью повторно сформировать diff’ы.Зависит от редактора: переместить курсор в конец списка изменений в Vim требует нажатия всего одной клавиши.
На редактирование файла для rebase у меня зачастую уходит столько же времени, сколько потребуется, чтобы пройти по списку действий из 1, исключая последнее («дальше что?то ещё»).
Слишком долго печатаете для программиста: за следующей клавишей можно и нужно тянуться одновременно с набором предыдущей (даже без слепого набора, но с двумя руками), поэтому делить на отдельные нажатия смысла не имеет. Опечатки тоже проверяются по мере набора (если смотреть не на клавиатуру). А мышка так не параллелится: «найти нужное изменение» и «навести мышку» вы, скорее всего, будете делать одновременно, а с остальным из моего списка так не получится. И ускорить сложнее: про методы ускорения набора я слышал, про методы ускорения взаимодействия с GUI я слышал только «выучите клавиатурные сочетания и используйте методы ускорения набора» (возможно, что?то иное знают «профессиональные» игроки в некоторые RTS).
(Кстати, такой вопрос: а в tortoisegit часом не получится всё делать с клавиатуры?)
michael_vostrikov
Эх, снова вы приводите какие-то проблемы, которых в GUI нет) Я например не знаю, как в git отключается pager, как-то не было необходимости интересоваться.
GUI получается вообще универсальнее некуда — везде есть кнопки, списки, текстовые поля.
Про методы ускорения вы не слышали, потому что и так скорость взаимодействия максимальная. Можно сказать, взаимодействие со скоростью света. Поэтому улучшение переносится на этап проектирования UI/UX. Быстрее только сразу запустить нужное действие хоткеем, без взаимодействия с графикой.
ZyXI
Никто как?то ещё не может похвастаться идеальной, да ещё и универсальной программой, поэтому скорость взаимодействия максимальной быть не может. На этапе проектирования интерфейса ускорены могут быть и консольные, и GUI программы, но GUI намного сложнее подпилить самому под свою задачу, тренировками того же слепого набора можно ускориться ровно настолько, насколько автор покрыл всё клавиатурными сочетаниями. Т.е. если вас не устраивает скорость взаимодействия с GUI приложением или его интерфейс, то вы не сможете сделать ничего, не будучи самому разработчиком GUI приложений.
Универсальности никакой никогда не было, есть некоторые общие соглашения насчёт ограниченного набора действий, но и они часто нарушаются. В тех же полях ввода
<S-Left>почти наверняка что?то выделит, а уже<C-S-Home>может и переход сделать.<Tab>может увести вас куда?то не туда, вставить что?то в поле ввода или просто ничего не сделать. До сих пор не могу привыкнуть к тому, что делает<S-перетаскивание>и<C-перетаскивание>в Altium: почти везде второе копирует объект, в Altium — перетаскивает с сохранением соединений, а копирует первое. Если автор GUI заранее не предположил, что данные с некоего элемента интерфейса понадобится куда?то скопировать, то единственным доступным обычному пользователю способом это всё же сделать будет скриншот (и последующее распознавание текста, скорее всего, ручное, — если нужен именно текст) — в GUI я такое вижу постоянно, особенно в сообщениях об ошибках (их очень не любят тестировать). В консоли я такого не видел никогда, технология не позволяет запретить мне скопировать текст.Конечно, я не жду, что что?то вроде Altium вдруг окажется консольным приложением — даже если такое существует, под терминал такие приложения не подходят никак. Но универсальности в GUI меньше, чем в консоли: нарушаемые соглашения есть и там, и там, но в консоли часть ожиданий пользователя нарушить нельзя в принципе из?за ограничений технологии.
varnav
А git add?
Да даже если 22 — это гораздо больше 3 кликов.
TyVik
Ctrl+Shift+K в любимой IDE.
zmeykas
Еще и проверит не забыл ли TODO, проведет анализ кода и при необходимости сделает деплой.
afendiko
А если линукс или ssh? Да здравствует Oh My Zsh!
mayorovp
На винде лично мне нравятся Git Extensions. Аналог add -p в интерфейсе подготовки коммита делается одной кнопкой (S, от Stage). Там же можно сделать отдельным строкам Unstage или Reset.
domix32
git-colaпод linux с примерно таким же функционаломKoToSveen
Тоже пользуюсь Git Extensions на винде. Интерфейс информативен в достаточной мере.
Lamaster
Это как сказать. Не всегда она работает ожидаемо, например при создании ветки она автоматически переключает HEAD на неё. Это очень неожиданно, когда создаёшь ветку, ресетишь текущую, переключаешься на созданную. Возможно я просто привык к TortoiseGit, но тем не менее.
Плюс к этому Idea не всегда показывает всю историю изменений файла, и это не зависит ни от отображения бранчей, ни от текущего HEAD. А git log и TortoiseGit отображает всё верно.
Amareis
Галочку соответствующую уберите :)
Nondv Автор
Курсором? Мышку двигать??
Слишком сложно, до свидания.
(хотя, возможно, все не так плохо и можно использовать tab, space и enter)
Amareis
Видите подчеркнутую "C"? Это означает что Alt+C переключит этот чекбокс. С Idea, я подозреваю, мышку вообще можно не использовать.
ZyXI
Интересно, а переназначить такое можно? У меня лично все
<A-зарезервированы под оконный менеджер. Конкретно<A-c>был заменой<A-F4>(закрытие текущего окна) пока я был на fluxbox, когда переписывал сокращения под i3, то решил, что я слишком часто нажимаю<A-c>случайно и надо бы добавить shift.alek0585
Как вы там в конце статьи написали? Know your tools?