Как я использую git

    Intro


    Основам git мне пришлось научиться на своем первом месте работы (около трех лет назад).
    С тех пор я считал, что для полноценной работы нужно запомнить всего-лишь несколько команд:


    • git add <path>
    • git commit
    • git checkout <path/branch>
    • git checkout -b <new branch>

    И дополнительно:


    • git push/pull
    • git 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!.


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

    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 194
    • +18
      Я бы предложил начать знакомство с git с книги про git. Для начала (и уверенной работы с git) оттуда достаточно прочитать первые 3 главы.
      • +4

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


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

        • +10
          Idea сокращает явную работу с гитом до минимума

          По моему, в IDE удобно только логи и диффы смотреть. Для всего остального набрать команду намного проще, чем искать какую-то кнопку и пытаться угадать как реально производимое действие легло на фантазии разработчика GUI.
          • +2

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

            • +7

              В idea есть вкладка "терминал") в ней удобнее всего с гитом работать.

              • +1

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

              • +5
                Ну и сохранение пароля жизнь упрощает

                Какой пароль? Ключи же :)
                • 0

                  Ключи тоже бывают под паролями :)

              • +1

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


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

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

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

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

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

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

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

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

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


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

                                    image

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

                                1 и 2 есть в TortoiseGit. Там вообще удобный интерактивный ребейз. Есть команда «Rebase onto this» для коммита, не надо отдельную ветку создавать.

                                3 можно и потерпеть, никто не спорит, что основные команды надо знать. Но локальной работы все-таки больше, так что лучше пользоваться тем, что удобнее для нее.
                                • +1

                                  А режим редактирования истории без перенесения есть? Когда возникла такая задача для консоли был написан 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, если он всё же понадобится, немного сложнее.

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

                                    Ребейз в TortoiseGit работает через cherry-pick. Поэтому все полностью контролируется TortoiseGit. Любой коммит можно отредактировать как нужно через графические инструменты, и сообщение и файлы.

                                    Не вижу большого смысла в возможности добавлять свои команды в GUI. Для сложных вещей есть консоль. А GUI нужен для облегчения повседневной работы.
                                    • 0

                                      В консоли по‐умолчанию rebase идёт на master (точнее, на что‐то настраиваемое, но это «что‐то» — ветка, см. второй абзац раздела «DESCRIPTION» git help rebase). А alias делает именно это: rebase на начало ветки (пока нет слияний, rebase на последнее слияние, если есть). В tortoisegit есть простой способ найти эту точку?


                                      А про «сложные вещи»: если консоль непривычна, то сложные вещи будет сделать очень сложно. А как она будет привычна, если используется в основном GUI?

                                      • 0

                                        В TortoiseGit выпадающие списки со значением по умолчанию. Там не надо ничего искать, всё в интерфейсе показывается.


                                        Кстати, в статье есть команда git rebase -i HEAD~3. Я так понимаю, она берет последние 3 коммита. Зачем что-то искать, если можно указать?


                                        Сложные вещи делаются редко, можно и потерпеть.

                                        • +1

                                          git ri не требует знания количества коммитов в той части истории, которую нужно изменить, а git rebase -i HEAD~3 требует. Когда их число достигает хотя бы пяти (а я легко могу сделать такую серию только из fixup! изменений) считать становится уже неудобно; если PR большой, то опечатки приходится исправлять и за десяток полноценных коммитов.


                                          А каким именно образом указывается основание для rebase в tortoisegit я не знаю, пока что он мне был нужен исключительно чтобы сделать git clone, в случаях, когда мне неохота ставить babun (сборка на основе cygwin), в котором git также есть (для новых проектов, за редким исключением, всегда использую mercurial). В консоли приходится искать, или отряжать скрипт, чтобы он искал. Если в tortoisegit такой скрипт написали за вас, то это отлично.

                                          • 0

                                            Там нет скрипта, по крайней мере специально для этого. Есть лог коммитов, в контекстном меню коммита пункт "Rebase onto this". Ничего искать не надо, что хотим то и указываем.


                                            а git rebase -i HEAD~3 требует

                                            А git rebase -i abcdef не требует.

                                            • –1

                                              Т.е. всё же надо искать, где начиналась ваша ветка, или хотя бы предка первого изменяемого изменения. Журнал не в тему: искать удобнее и несколько быстрее, но с git ri ничего искать не нужно.


                                              git rebase -i abcdef, внезапно, сделает rebase, если изменения не основаны на abcdef. А нужно изменение истории без rebase.

                                              • +1

                                                Что значит "изменение истории без rebase"? У вас команда заканчивается на git rebase --interactive "$o" "$@".


                                                Зачем указывать abcdef, если вам не нужно делать на него rebase? По ошибке? Вот поэтому я предпочитаю GUI, там не надо это за каждым символом следить. Ну и да, разговор был что "нужно знать количество коммитов". А это не так.


                                                Журнал не в тему: искать удобнее и несколько быстрее, но с git ri ничего искать не нужно.

                                                Почему не в тему, если вопрос в том, что искать сложно? В консоли сложно, в GUI лог и так постоянно используется. Тыкнуть мышкой в коммит это недолго. У вас была проблема, вы ее решили. А когда лог под рукой, такой проблемы не возникает.

                                                • –1

                                                  И что, что заканчивается? У 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)



                                                  Взамен вы получили постоянно висящее окно (или лог будет настолько же «под рукой» как у меня в терминале), специализированное практически под одну задачу. А вопрос был не в том, как бы искать попроще, а в том как бы не искать вообще.

                                                  • +1
                                                    Зачем писать git rebase -i master, если можно написать git rebase -i s?

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

                                                    Насчет поиска в GUI. Что в этом сложного?

                                                    • 0

                                                      В терминале можно пускать компиляцию, тесты, посмотреть результаты с travis, … А в tortoisegit только git. Впрочем, это только альтернативный workflow: терминал с tmux и Vim плюс браузер в принципе заменяются на браузер+IDE+tortoisegit, особенно учитывая, что в IDE терминал часто есть.


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


                                                      1. Переключиться на черепашку, посмотреть на лог, найти там нужное изменение, навести мышку, нажать ПКМ, навести мышку и нажать ЛКМ, дальше что‐то ещё.
                                                      2. Переключиться на терминал, напечатать git ri<CR>, дальше что‐то ещё.
                                                      • 0
                                                        В терминале можно пускать компиляцию, тесты, посмотреть результаты с travis, …

                                                        В одном терминале нельзя увидеть все это одновременно.


                                                        Та же компиляция крупных проектов своим логом "затирает" всю информацию на терминале.

                                                        • +1

                                                          Ознакомьтесь с такой штукой как tmux.
                                                          Можно делить терминал на "панели", переключаться между "вкладками" (там они называются окна), можно листать вывод, копировать, вставить и, внимание (!!), все это без использования мыши и с помощью сочетаний клавиш emacs/vim (полагаю, что вимовские намного удобнее в контексте тмукса, но я emacs-юзер, поэтому пользуюсь ими).


                                                          Даже если Вам не нужны эти фичи, то все равно ознакомьтесь. Это серверное приложение и можно восстанавливать сессии. Очень удобно, если вы работаете по ssh и получаете обрыв связи

                                                        • 0

                                                          Так пускайте, кто мешает) Я говорю конкретно про использование git.


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

                                                          Я к тому, что это настолько сложно, что нужно стремиться вместо этого писать кастомные скрипты в консоли? Мне вот неохота прогонять 10 коммитов с начала ветки, если надо поменять только 2 последних. Не говоря уже о том, что у вас гораздо больше времени уйдет на редактирование файла для ребейза. Это экономия на спичках.


                                                          Ну и да. "Переключиться на терминал, нажать G, нажать I, нажать T, нажать Space, нажать R, нажать I, проверить, что нет опечаток, нажать Enter". Обнаружить опечатку "get", переместить туда курсор, убрать символ, добавить символ, или нажать Ctrl+C и набрать все заново. А потом в "git log" проверить, все ли правильно получилось, не забыл ли чего.

                                                          • –1
                                                            Я к тому, что это настолько сложно, что нужно стремиться вместо этого писать кастомные скрипты в консоли?

                                                            Нет, именно это — не настолько. Я к консоли «стремлюсь», потому что их там можно писать, и потому что часть вещей там универсальна: к примеру, когда вы не знаете точного вида регулярного выражения проще и быстрее искать что‐то в 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 часом не получится всё делать с клавиатуры?)

                                                            • 0
                                                              Эх, снова вы приводите какие-то проблемы, которых в GUI нет) Я например не знаю, как в git отключается pager, как-то не было необходимости интересоваться.

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

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

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


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


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

                                  • 0
                                    А git add?

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

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

                                    • 0

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

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

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

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

                                            • –14

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


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

                                              • +26

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

                                                • 0

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

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

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


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

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

                                              ЗЫ Я в аналогичных случаях обычно жал Ctrl+Z и убивал процесс руками :)
                                              • +1
                                                Если нажать Ctrl-C в VIM то будет подсказка типа «Type :quit to exit Vim»
                                              • +3

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

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

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

                                                    • 0

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

                                                • +3

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

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

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

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


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


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

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

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

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

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


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


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

                                                            • 0
                                                              Есть github.com/andreafrancia/trash-cli для пользования корзиной через консоль.
                                                            • +3

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


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

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

                                                                Ну и, собственно, никто не отменял GUI клиенты с командной строкой. Надо сделать что-то нестандартное — взял и сделал в консоли.
                                                                • 0

                                                                  Не раз приходилось чистить за сотрудниками, которые используют эклипс, и временные файли и простыни файлов с путями в гитигнор, вместо *<название файла>, так что тут вопрос внимательности, а не консоль/GUI. В консоли можно добавить все файлы, с расширением например *.cpp и они добавятся со всех вложенных директорий, не надо будет мышкой кликать и выбирать. Так что тут спорное утверждение

                                                                  • 0
                                                                    Это вопрос кривизны реализации Эклипса (безотносительно VCS, эта IDE весьма кривая сама по себе). В Tortoise* добавление в ignore list более-менее грамотное: никаких абсолютных путей, предалагается несколько вариантов (например фрагмент относительного пути, например "/Debug/", или расширение "*.obj" или имя файла с расширением). Еще одно преимущество графических утилит — добавляя маску в ignore list, я сразу вижу как исчезает группа файлов в списке кандидатов на добавление; список уменьшается и я обращаю внимание на следующие файлы, которые нужно добавить в игнорируемые или наоборот добавить под контроль версий. То есть прежде чем коммитить я получу готовый список без единого лишнего файла, который я буду видеть заранее.
                                                                    • 0

                                                                      После Intellij IDEA тоже чистил. Для линукса нету Tortoise, поэтому ваш вариант не может быть использован в моей ситуации вообще

                                                                      • 0
                                                                        Для линукса вообще беда: куча DE и файловых менеджеров, под многие из которых просто не реализован доступ к конкретным VCS-GUI-утилитам из контекстного меню. А если и реализован то с какими-то глюками.
                                                                        • –1

                                                                          В линуксе как раз все в порядке с гитом, он там нативный)
                                                                          Это просто другой вид работы, где можно обойтись без мышки. Я, например, уже пользуюсь GUI в исключительных случаях, только по требованию работодателя. Меня он просто бесит из-за медлительности

                                                              • 0
                                                                Почему народ так цепляется за консоль мне непонятно…

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

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

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

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


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


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

                                                                  • +1

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


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

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

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

                                                                        • +4

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

                                                                        • 0

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

                                                                          • 0

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


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

                                                                            • –1

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

                                                                              • –1

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

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

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

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

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

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

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

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

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

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

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

                                                                                          • 0
                                                                                            Сижу праллельно как в консоли, так и интерфейсе. Дифы/ветки/историю смотрю в гуе. Коммичу/бранчуюсь из консоли. Почему? Ну во-первых через гуй нельзя сделать stash, что часто нужно. Более того, нет вообще возможностей сделать что-то окромя стандартного флоу pull/push/merge. Ну тот же cherry-pick. Про сложные вещи типа git branch -a --contains 9263de3a03cb8b8b79d59fda1883efe9cf7f33e1 молчу, очень мало гуёв предлагают такой функционал.

                                                                                            Как финал, у меня стоят гит хуки которые на переключение веток и пулл запускают вебпак. Когда я точно знаю, что ничего не менялось (git checkout -b например), то я в консоли могу сделать ctrl+c и продолжить заниматься своими делами, гуй же виснет, потому что он не знает, что гит хуки запускает и их можно приостановить.

                                                                                            Такой вот флоу у меня. Особого переключения контекста не больше, чем между разными окнами в IDE.
                                                                                          • +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()
                                                                                            • 0

                                                                                              Одна из причин, по которым я не хочу разбиратся с гитовыми алиасами — мне все равно придется писать git <something>.


                                                                                              Т.к. автокомплит настраивается и для башевых алиасов, я предпочту gdiff, а не git d (не люблю нажимать пробел без причины)


                                                                                              Мне нравится граф в bitbucket. А так я заметил, что многие практикуют ребейз.

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

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

                                                                                                • 0
                                                                                                  Или просто добавить в домашнюю папку пользователя папку .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"

                                                                                                  • 0

                                                                                                    Угу, как-то я подошёл к коллеге, у которого "гит не сохраняет мои изменения". Говорю — показывай, как делаешь. А он начинает мне такую вот абракадабру писать. Было печально.

                                                                                                  • 0
                                                                                                    Увы, у меня магия не работает:
                                                                                                    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
                                                                                                      1. git log вместо log.
                                                                                                      2. В моей команде нужно экранирование кавычек, так как используется алиас. Вам нужно заменить \" на ", тогда заработает.

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

                                                                                                      • 0
                                                                                                        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)"
                                                                                                  • +2
                                                                                                    добавляю префикс[to_squash]
                                                                                                    и переношу этот коммит

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

                                                                                                    • 0

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


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

                                                                                                    • +1

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

                                                                                                      • +3
                                                                                                        Комментарии напомнили времена использования Norton Commander.
                                                                                                        «я пользуюсь командной строкой», а я пользуюсь Волков Коммандер и нечаянно нажал F8 и все удалил. :D
                                                                                                        • 0

                                                                                                          "я что-то нажала и все исчезло"


                                                                                                          Я во время написания статьи, похоже, задел cmd+z, и у меня часть текста испарилась. Долго искал, что и где

                                                                                                          • +4
                                                                                                            Кстати, один из недостатков графических интерфейсов. Зацепил клавиатуру, что-то сделалось, а что не знаешь. В консоли хоть видно, что начудил.
                                                                                                          • 0

                                                                                                            Far Manager решает эту проблему (F8 удаляет в корзину). Поэтому чтобы нечаянно удалить приходится нажимать Shift+Del :-)

                                                                                                            • +1
                                                                                                              Я у себя всегда эту опцию отключаю. Не люблю возиться в мусорной корзине :)
                                                                                                          • +3
                                                                                                            alias git-uncommit='git reset --soft $(git log --format=%H -2 | tail -1)'

                                                                                                            а не проще как-нибудь вот так:
                                                                                                            alias git-uncommit='git reset --soft HEAD~1'

                                                                                                            • +3

                                                                                                              Абсолютно!


                                                                                                              Еще проще:


                                                                                                              alias git-uncommit='git reset --soft HEAD~'

                                                                                                              (единица опциональна)


                                                                                                              Этому алиасу уже пара лет. Работает — не трогаю:)

                                                                                                              • 0

                                                                                                                Попробуйте с таким алиасом сделать uncommit два раза подряд :-)


                                                                                                                С другой стороны, такой алиас, в отличие от варианта с git log, умеет отменять amend...

                                                                                                                • 0

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


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

                                                                                                                  • 0

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

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

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

                                                                                                                • 0

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


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

                                                                                                              • 0
                                                                                                                Поделюсь опытом с теми, кто не хочет страдать в терминале и работать с репозиторием вслепую: Git Kraken — единственный удобный GUI для Git под Linux.
                                                                                                                • 0
                                                                                                                  А если хочется страдать? А если любовь к консоли очень сильна и безгранична? :)
                                                                                                                  • 0
                                                                                                                    Тогда поможет только хороший психоаналитик :)
                                                                                                                  • 0
                                                                                                                    SmartGIT чем не устраивает?