company_banner

15 базовых советов по Git для эффективной работы каждый день

  • Tutorial

Привет, меня зовут Сергеев Сергей aka gurugray. Сейчас я «Mentor FrontEnd Community» в компании ManyChat. Вы могли видеть мои лекции по релизному циклу и регламенту работ с системами контроля версий в Школе Разработки Интерфейсов Яндекса (ШРИ).


Меня часто спрашивают какие life-hacks или best-practices я использую при работе с Git'ом и репозиториями проекта.


Эта заметка — попытка объяснить те базовые настройки и приёмы, которыми я пользуюсь каждый день. Рецепты не претендуют быть ноу-хау, но могут помочь с освоением ежедневной гигиены работы с репозиторием.



1. Используй свежее


Я предпочитаю работать в консоли и большая часть команд и советов в этой заметке будет про консольный клиент. Это своего рода первая рекомендация — используйте консольный клиент для ежедневной работы с репозиторием и регулярно его обновляйте. В консольном клиенте в первую очередь появляются новые возможности и исправления ошибок.


> git --version
git version 2.27.0

2. Настрой инструмент


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


> git config --global user.email "gurugray@yandex.ru"

> cd company_project
> git config user.email "gurugray@manychat.com"

Если вы не пользуетесь консолью и vim'ом для редактирования, то вам стоит настроить и ваш редактор:


> git config --global core.editor "code --wait"

3. Настрой autocomplete


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


Git из коробки предоставляет набор скриптов для автокомплита, но если ваш shell, как у меня, более экзотичен — найдите и поставьте автокомплит именно для него.


4. Ускоряй часто используемое


Настройте себе псевдонимы (aliases) для быстрой работы. Для каждого человека удобство ощущается по-разному и я не рекомендую увлекаться однобуквенными псевдонимами, особенно если вы часто работаете на других рабочих станциях или используете ssh для удалённой работы на серверах — вам либо придётся тратить время на борьбу с различиями, либо растаскивать свой файл настроек по всем машинам (что не всегда плохо, конечно). Также не старайтесь заменить псевдонимами любое сочетание команд — половину вы забудете, а к половине привыкните более, чем оно того заслуживает.


Я перешёл на Git с SVN, потому для меня базовые псевдонимы перекочевали оттуда, а "b" — единственный однобуквенный псевдоним.


> git config --global alias.st "status -sb"
> git config --global alias.co "checkout"
> git config --global alias.ci "commit -a"
> git config --global alias.b "branch"

5. Обзорность помогает решать проблемы


Я часто работаю с историей проекта — нужно понять, что и когда влилось, и какие состояния проекта этому предшествовали. Часто важно знать последовательность комитов и топологию дерева истории. Git из коробки помогает показать дерево истории проекта:


> git log --oneline --graph --branches

Но для полноты картины хочется видеть и авторов, и даты и в удобной расцветке, потому мой псевдоним выглядит не так дружелюбно с параметром --pretty=format::


> git log --graph --date=short --branches --pretty=format:'%C(yellow)%h%C(reset) %ad | %C(75)%s%C(reset) %C(yellow)%d%C(reset) [%an]'

6. Следуй протоколу


Всегда клонируйте репозиторий, в который вносите правки по git+ssh протоколу, это работает быстрее чем по http и сэкономит время в процессе работы:


> git clone git@github.com:gurugray/gurugray

7. Разделяй источники


Если вы работаете с репозиториями по «форковой» модели (когда к основному репозиторию есть доступ только на чтение, а все pull-request'ы подаются из форка) называйте основной репозиторий upstream это поможет не путаться в командах отведения веток и push'а в свой origin. Не забывайте про протокол, если репозиторий открыт только для чтения, то его можно клонировать без ssh-слоя, что тоже даст экономию времени в процессе работы:


> git clone git://github.com/gurugray/gurugray -o upstream

8. Контролируй процесс


Не используйте команду pull, это составная команда и делает несколько действий сразу. Часто при работе с репозиторием новички допускают ошибку не понимая, как эта команда обновляет текущую ветку, и замусоривают свою историю или неправильно работают с дефолтной веткой. Я рекомендую явно обновлять репозиторий локально, затем явно обновлять свою ветку:


> git fetch --all
> git rebase my_feature upstream/master

9. Не вводи себя в заблуждение


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


> git fetch --all
> git checkout -b my_feature upstream/master

> git branch -D master

10. Не бойся исправлять


Если вы следите за чистотой истории и хотите исправить состояние проекта зафиксированное несколько комитов назад, то достаточно закомититься с параметром --fixup= и передать нужный хэш комита для последующего причёсывания истории


> git commit -m "Feature A is done"
> ...
> git commit -m "Feature B is done"
> git commit --fixup=fe2f857

> git log --oneline
a5050e7 fixup! Feature A is done
633e33f Feature B is done
...
fe2f857 Feature A is done
cb5db88 Previous commit

11. Не бойся быстро исправлять


Один из полезных псевдонимов — замена последнего комита текущим состоянием, позволяет «подклеить» текущее состояние к последнему зафиксированному, при этом не включая режим редактирования сообщения:


> git config --global alias.fixlast "commit --all --amend --no-edit"

12. Перебазируй


Научитесь и пользуйтесь командой rebase в интерактивном режиме и с параметром --autosquash с которым использование --fixup будет ещё более удобным, а сам ребейз помогает причёсывать историю и аккуратно оформить комиты, например по принятым у вас guidline'ам, до подачи pull-request'а для успешного его принятия.


> git rebase -i --autosquash cb5db88
pick fe2f857 Feature A is done
fixup a5050e7 fixup! Feature A is done
pick 733e2ff Feature B is done

> git log --oneline
633e33f Feature B is done
...
5778cbb Feature A is done
cb5db88 Previous commit

13. Сбрасывай ненужное


Научитесь и пользуйтесь командой reset она позволит легко манипулировать локальной историей и состоянием, например после череды правок и комитов на код-ревью «схлопнуть» последние ненужные состояния проще с её помощью:


> git reset @~4
> git commit --all

14. Контролируй деструктивный push


Если вы хотите запушить изменённую историю, советую использовать полный синаксис команды и не использовать ключ --force -f, это позволит не привыкать к настройкам по умолчанию и не приведёт к случайным перетираниям истории на сервере:


> git push origin +feature

15. Помни про летописца


Не забывайте про reflog эта команда поможет разобраться с проблемами в локальном репозитории если что-то пошло не так — спасательный круг для новичков, к которому они редко подходят:


> git reflog
> ...
> git reset --hard FOUND_HASH

Все советы выше помогут быстрее работать с репозиторием и быстрее получать ответы об истории разработки поиска ошибок и выявления узких мест в регламенте работы, но эта тема для отдельной статьи.


Есть ещё много возможностей для тонкой настройки Git'а под себя и для решения более специфичных кейсов, но описанные выше возможности инструмента позволяют вам каждый день удобно работать не теряя в скорости.

ManyChat
Будущее мессенджер-маркетинга

Comments 63

    +2
    Я предпочитаю работать в консоли и большая часть команд и советов в этой заметке будет про консольный клиент. Это своего рода первая рекомендация — используйте консольный клиент для ежедневной работы с репозиторием и регулярно его обновляйте. В консольном клиенте в первую очередь появляются новые возможности и исправления ошибок.


    Какая-то странная у вас аргументация.
    Ни разу не сталкивался с ошибками git клиента
    А вот то что в VS 2019 появился squash, мне во многом облегчило жизнь
      +2
      Ну строго говоря Вы подтвердили тезис — squash в консольном клиенте был давно :)
      Но я не навязываю кому-то инструмент, вполне возможно у Вас другие сценарии использования.
        0
        Ни разу не сталкивался с ошибками git клиента

        Ooo, вот только что нарвался. В Windows 10 на одной машине вдруг стала сбоить команда git subtree add. Три дня на ушах стоял. Потом обнаружил, что глюки имеют место только при запуске из-под Far'а. Не только напрямую, но даже если из него Pycharm запустить. В конце концов выяснилось, что по непонятной причине Far запускается в режиме совместимости с Windows 8.1.

        0
        Не используйте команду pull

        Категорически поддерживаю. Эта команда делает две совершенно разные вещи: fetch + merge, причем с непредсказуемым результатом, not the unix way. Очень жаль, что она есть, без нее было бы меньше магии и меньше путаницы.


        Советую вместо git pull делать примерно так:


        git fetch
        git status -sb

        И после этого уже merge или rebase.

          +7

          Есть потрясающая опция git config --global pull.ff only — пулл делает только fast-forward и фейлится, если он этого не может сделать. Это избавляет от необходимости контролировать каждый fetch+merge и при этом защищает от пулла не в ту ветку.

            +1
            Как многие жалуются опций у git'а действительно много, но смысл совета как раз в том чтобы не делать два разных действия одновременно. fetch — для синхронизации базы merge/rebase для апдейта ветки и рабочей копии проекта.

            Ну и `ff-only` будет фейлиться если над проектом работают много разработчиков и основная ветвь двигается часто.
              +2
              ff-only будет фейлиться

              В этом-то и задумка. А ещё если локальные изменения не пересекаются с входящими (затронуты разные файлы, и в вашей ветке сверху нет незапушенных коммитов), то по идее такой pull должен прокатывать как fast-forward.


              Этот подход успешно работает вместе с правилом: что бы ни делал (ну, за исключением коммитов на одну строчку) — создавай новую ветку. Пришла пора вмержить основную к себе или свою в основную — да пожалуйста. Надо срочно переключиться на основную не вливаясь — делаешь в текущей сверху коммит wip в который включаешь все текущие изменения, спокойно переключаешься на основную. А когда возвращаешься, этот wip откатываешь и продолжаешь как ни в чём не бывало.


              А про fetch, кстати, многие забывают или не знают про такую классную опцию как --prune — вместе с выкачиванием новых веток/коммитов, она удаляет те, которые были удалены на сервере (имеются в виду remote-ветки. Ваши локальные чекауты останутся нетронутыми).

                0
                Всё так! Спасибо за комментарий!
                  +1

                  Опция pull.ff only очень хороша, но не все про нее знают, и мало у кого она установлена. В моем конфиге она есть, но я в принципе не делаю git pull. Для таких случаев у меня есть алиас git fff, что значит fetch fast-forward, вот кусочек моего конфига:


                  [alias]
                  s   = !git status -sb
                  f   = !git fetch origin --tags --prune && git s
                  ff  = !git merge @{u} --ff-only && git l1 && git s
                  fff = !git f && git ff
                    0
                    Крутой конфиг, спасибо!
                    Я правда не сторонник заводить на всё алиасы, потому как прыгал часто на чужие терминалы, но как пример — очень классно :)
                      +1

                      Можно разу делать pull --rebase

                        0
                        Можно, если знаешь что делает команда, то можно делать сразу два действия с выбором режима. Но я намного реже хочу делать ребейз сразу с фетчем :)
                    +4
                    svn мне нравился тем, что многое он не умел, но при этом был на порядок проще. Все эти ff, wip, squash (и update-index --assume-unchanged который ниже — тут наверняка почти никто не знает) — мне неизвестны, хотя с гитом лет 5 работаю. Ну как неизвестны. wip — впервые вижу, только stash знаю, а остальные — слышал, но ни разу не применял.
                    Так что я бы добавил «изучи инструмент полностью». Проблема в том, что многие возможности это «о, прикольно» — но применяться не будет почти никогда. Но… представим что я программист. Что от меня требуется? Написать код, протестировать, и закоммитить. А потом вылить на удаленный сервер для тестов сервером, другими людьми. При этом голова чем занята? Почему этот баг не воспроизводится в отладчике, как сделать новую фишку максимально быстро и красиво и проверить все граничные случаи… А не о том, что я должен делать fetch (который бывает разный, смотря какие опции), потом merge… и подобное.
                    Это так, мысли вслух.
                      +2
                      git проще чем может показаться. И в то же время это очень мощный инструмент, заслуживающий чтобы ему уделили время на изучение. В документации есть не только про то как работают команды, но и про то как работает сам git. И поняв внутреннею механику, которая повторюсь довольно проста(как и многие гениальные вещи), вам будет намного понятнее как применять команды. Рекомендую довольно подробную статью здесь на habr ну и глава в git-scm
                        0

                        "wip" — аббревиатура от "work in progress", используется как плейсхолдер и на гит никак не завязано. Да, это я как-то погорячился, упомянув его без расшифровки.

                          0
                          «переключиться на основную не вливаясь» — для этого есть stash, а как закончили то stash pop. Иначе получается незаконченная каша. Лучше тогда «работа в ветке, сделал мелкий блок для конкретной задачи — закоммитил», тогда и stash не нужен. А иначе это «мусорный» коммит с нерабочим кодом. Впрочем, если потом идёт слияние как 1 итоговый коммит с потерей промежуточных, не помню опцию, то тоже имеет место быть.
                          В общем, гит может много. Это его и сила и слабость, большинство останавливаются на clone-pull-commit-push.
                          ЗЫ Про stash уже увидел чуть ниже, отвечал по мере чтения, простите.
                          Оставить там коммент — не смогу, ответ раз в час.
                            +1

                            Только влитое временно в [временную, ежели нужно] ветку там в ветке и останется до потребности/сноса.
                            Да и в кашу stash превращается ещё легче.

                          0
                          Да у svn были свои плюсы, но не все настройки и параметры git'а нужно помнить или знать. Я как раз старался описать ровно то чем пользуюсь буквально каждый день, а не эпизодически.

                          … я программист. Что от меня требуется? Написать код…


                          А вот это утверждение очень спорное, но повод для следующей заметки.
                          +1
                          Надо срочно переключиться на основную не вливаясь — делаешь в текущей сверху коммит wip в который включаешь все текущие изменения, спокойно переключаешься на основную. А когда возвращаешься, этот wip откатываешь и продолжаешь как ни в чём не бывало.

                          git stash делает фейспалм
                            0

                            А вот не всё так однозначно.


                            Есть несколько моментов. Если пытаться работать одновременно с несколькими ветками и делать stash в нескольких, то после переключения на исходную ветку сильно задумываешься, что нужно применить вместо git stash pop. Если стешить совсем небольшие изменения, то можно вообще не вспомнить, что делал стеш, и потом сидишь и удивляешься, почему результат не тот. А окончательно я решил для себя вопрос, когда как-то раз stash сохранил изменения только в модифицированных файлах, а те которые были untracked — безвовратно протерялись (про то, что их надо было отдельно включать через --include-untracked я тогда не знал). Так что текущие изменения в ветке, которые в любом случае в неё попадут, проще сразу коммитить, пусть даже во временный коммит.


                            А вот stash удобно пользоваться для хранения хаков, которые можно применить к любой ветке и потом не жалко откатить перед "настоящим" коммитом.

                              +2

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

                                0

                                Вот-вот, поддерживаю.

                                  0

                                  Я помечаю такие временные бекап-коммиты крестиком, примерно так:


                                  [x] Temp

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


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

                                    +1

                                    можно придумать по аналогии с !fixup сообщением, и настроить хук
                                    так и избежать «плохих» комитов и автоматизировать свой flow

                                0
                                Тоже не понял, зачем так делать. У меня есть только одно объяснение… Я сам так делал, когда не знал про git stash )
                                UPD: Увидел новые сообщения. Причина использования временного коммита понятна, но всё же на вкус и цвет.
                          0
                          А чем не устраивает
                          git pull --rebase 
                          ?

                            0

                            Отвечу более развернуто.


                            Фундаментальное преимущество git — его распределенность: вся история есть локально, и можно полноценно работать даже когда нет сети, поэтому он такой быстрый. Сеть нужна всего в двух случаях: скачать новые коммиты с удаленного сервера (git fetch) [причем для всех веток сразу], отправить свои коммиты на удаленный сервер (git push).


                            С этой точки зрения команда git pull (с какими угодно опциями) — это "супер-команда", которая скачивает новые коммиты [также для всех веток сразу] и сразу же пытается автоматически интегрировать их с локальными коммитами на текущей ветке.


                            Для меня это две совершенно разные задачи. Отказ от этой "супер-команды" дает следующие преимущества:


                            1. Логическое разделение двух несвязанных операций.
                            2. Возможность увидеть и сравнить все изменения до их интеграции.
                            3. Возможность самому решать как делать интеграцию (--no-ff, --ff-only, standard rebase, rebase-via-merge, --squash).
                            4. Не запускать лишний раз скачивание коммитов с сервера. Именно поэтому git pull — всегда такая медленная операция, тогда как сами по себе merge и rebase быстрые, потому что им не нужна сеть.
                            5. Есть ясное понимание того, что происходит, без каких-либо сюрпризов. Не надо полагаться на какие-то опции этой "супер-команды".
                          +4

                          Странно, что совсем не упомянуты хуки. Инструмент, которым я пользуюсь каждый день — привычка называть ветки единообразно, типа "my_feature_PRJ-001", где PRJ-001 — номер задачи в жире/редмайне, плюс миниатюрный скрипт commit-msg, который номер задачи подставляет в начало сообщения коммита. Если есть интеграция с ишью трекером, очень удобно смотреть что делают другие и вспоминать, а что делал сам.


                          О, о, а ещё есть такая суперская вещь как git update-index --assume-unchanged <path to file> — изменённый файл перестаёт отображаться как изменённый и соответственно нигде в гите не всплывает до тех пор, пока не приходят коммиты с этим же файлом или вы не решаете отредактировать его ещё раз. Очень помогает, если в вашем репозитории есть отслеживаемые конфиги, а вы у себя хотите держать их альтерированную версию и не хотите, чтобы они мозолили вам глаза.


                          Я обожаю гит и его возможности для упрощения себе жизни, простите. >_<

                            0
                            Спасибо. Есть правда много приёмов, но я старался не сильно пространно рассказать то чем пользуюсь буквально каждый день :)
                              0

                              А вот интересно было бы послушать, на самом деле. Про "базовые" лайфхаки много пишут, а про продвинутые меньше. У гита есть ещё порох много заначек; про тот же git commit --fixup я например только из этой статьи узнал.


                              Вам спасибо за поднятие интересной и полезной темы.)

                                0
                                Сложные вещи гораздо реже используются и зачастую требуют много мотивационного сопровождения. Не всегда это удобно в формате статьи потреблять. Например про один git reset можно написать статью больше чем предложенная.
                                Если прямо послушать, то можно прямо мои лекции и послушать :))
                                  0
                                  del
                              +6
                              Не используйте команду pull, это составная команда и делает несколько действий сразу

                              Какой-то крайне сомнительный совет :) Во-первых, не дофига ли чести для рутинного действия, которое почти всегда fast forward, как уже выше отметили для тех, когда это не так, есть опция в конфиге. Во-вторых,


                              git pull -r

                              Сделает то ж самое, что приведено в примере, только автоматически


                              Правильный совет — разберитесь уже как работает git pull и как решать проблемы, которые он создаёт)

                                0
                                Fast forward при распространённых workflow почти никогда не случается — 90% случаев заканчиваются лишним merge'ем, совет как раз в том что стоит контролировать два разных действия, если человек умеет пользоваться pull'ом, то этот совет ему уже не нужен :)
                                  0
                                  [pull]
                                  rebase = true
                                  [rebase]
                                  autoStash = true
                                  0
                                  > git pull -r

                                  У меня даже так: pura = pull --rebase --autostash

                                  Но тут всё-таки надо понимать, когда нужен pull с мержем — иногда бывает.
                                  +1

                                  Имеет смысл упомянуть tig, определённые вещи там делаются невероятно удобно.


                                  git clone git@github.com:gurugray/gurugray

                                  К пункту 6 можно добавить настройку в .gitconfig:


                                  [url "git@github.com:"]
                                    insteadOf = https://github.com/
                                    0
                                    tig прикольный, у меня он всегда по умолчанию установлен, но как-то не зашёл на каждый день

                                    Про isteadOf я писал когда-то заметку, настройка удобна, особенно когда работаешь с разными ремоутами
                                    +1
                                    Надо бы ещё совет «Пользуйтесь ключом -p».

                                    И горячо поддерживаю, то что нужно работать из консоли, т.к. есть люди, кто познакомился с git используя ide'шки, для них мысль об обычном merge панику вызывает. Т.е. консоль это то, что надо уметь, GUI лучше осваивать, когда освоил CLI.
                                      0
                                      Надо бы ещё совет «Пользуйтесь ключом -p».

                                      Это который у git add ?


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

                                        0
                                        У `git add`, `git checkout` у `git reset` и может ещё где, сходу не соображу. Мы ввели правило, все изменения в гит добавлять с таким ключом, сразу пропали вопросы, вида «а это тут зачем?». Т.к. бывало человек коммитил в одну ветку, то что должно быть в другой, либо нажал что-то в редакторе, современный редактор рассчитанный на использование систем контроля версий это дело сохранил, а дальше получаем на ревью PR в котором есть нерелевантный код или вообще мусор.
                                          0

                                          Такой подход требует большей дисциплины, чем я могу расчитывать :)
                                          Но в нём определённо есть плюсы!

                                            0
                                            Я не верю в то, что обычно понимается под дисциплиной. Если этой рекомендацией не пользоваться, глупые косяки возникают, что приводит к сложностям на ревью. Как следствие пользоваться проще чем не пользоваться. Понятно, если пишете в одну каску, то этот фактор, поощряющий использование ключа пропадает, но тут уже привычка. Ну и… косяки с случайным коммитом того, чего коммитить не надо у меня бывали, мне проще использовать.
                                              0

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


                                              Дисциплину я понимаю так — думать о том что и почему ты комитишь, хотя бы так :)

                                                0
                                                Ваш подход, IMHO, может работать как индивидуальная практика. В команде такой применять вряд ли получится. Т.к. уж больно замороченно, потом для создания агрегированных состояний есть Pull request'ы с ревью, мы у себя в команде их сквошим при мерже. Т.к. по факту, на мне важно один там коммит в истории или сотня.
                                                  0

                                                  Ух, вот в командной практике я стараюсь отговаривать сковшить PR, мне кажется минусы от этой практики превышают её плюсы


                                                  И тогда не очень понятно зачем заморачиваться с add -p и подобным если потом всё в одну кучу схлопываете?

                                                    0

                                                    -p позволяет коммитить только то, что нужно закоммитить. А PR под фичу. В истории потом понятно, кто когда и зачем реализовывал. Неудобно только, что связь с dev ветками теряется, но по факту она редко нужна.

                                                      0

                                                      не очень понятен флоу, было бы интересно подискутировать по этому поводу :)

                                                        0
                                                        Флоу типичен в таких ситуациях: есть N+M изменений, из которых N идут в планируемый коммит, а M — это то, что не должно коммититься, потому что из них 90% это log(«TMP: точка 25») или что-то подобное, часть — изменения опций для такого дебага, и т.д. — и они перекрываются по файлам.

                                                        Более того, я обычно использую даже не add -i или -p, а add -e — с редактированием диффа. У него есть некоторые маргинальные ограничения (например, добавление нового файла не проходит по частям), но в >99.9% случаев помогает разделить две категории изменений, даже если они перекрылись в одной строке.
                                                          0

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


                                                          потому мой флоу скорее — атомарно комитить дебаг, чаще ребейзиться и в конце выбрасывать дебаг из истории комитов

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

                                                              есть ещё worktree, но мне на каждый день не особо прижилось
                                                              но на маленьких проектах может даже быть очень эффективным

                                        +3
                                        для них мысль об обычном merge панику вызывает

                                        Это скорее от неумения работать, чем от GUI

                                        И потом, до сих пор не понимаю, как можно говорить про «Обзорность» и консоль в одном предложении. Пытаться построить псевдо-дерево в консоли, чтобы сымитировать возможности GUI.
                                        ¯ \ _ (ツ) _ / ¯
                                          0

                                          пример с деревом в консоли — мне правде удобнее ¯ \ (ツ) / ¯
                                          и возможность сразу грепать по ней и делать первичный поиск для меня тоже важна

                                            0
                                            Ну, люди умеющие консоль и боящиеся мержа может и встречаются, но мне не попадались. Да ребейз не каждый трогал, но, на мой вкус, в норме, он и не нужен.
                                          0
                                          Еще пара слов в копилку про pull:
                                          Его так часто используют с опциией --rebase, что в самом git можно переопределить поведение команды pull:
                                          git config --global branch.autosetuprebase always
                                          После выполнения этой команды все команды git pull будут интегрироваться с помощью команды git rebase, а не git merge.
                                          Признаюсь, сам только что об этом узнал, когда полез смотреть что за ключ -r у команды pull
                                            0

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

                                            0
                                            GitHub будет показывать вашу активность, даже если вы смените место работы.

                                            Это разве что если вы ведете свои проекты на github. Многие же кампании поднимают свой enterprise gitlab и магической публикации активности в гитхаб не происходит.

                                              0

                                              это так, да :)

                                              +2
                                              Как то странно git pull попал в немилость, а git commit --all в рекомендации)

                                              А уж ничего разрушительнее commit --all --amend --no-edit в алиасах я представить не могу
                                                0

                                                Тут я согласен, что commit --all может быть зачастую вреден, но я не рекомендовал его специально, возможно стоило и тут несколько предохраниться :)

                                                0
                                                git config --global core.editor "code --wait" а для чего это нужно?
                                                  0

                                                  это нужно для того чтобы редактировать сообщения комита в редакторе VSCode в частности
                                                  core.editor может быть любым удобным редактором

                                                Only users with full accounts can post comments. Log in, please.