Pull to refresh
16
0
Sergii Sergieiev @gurugray

Engineering Manager & Staff Developer

Send message

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

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

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


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

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

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


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

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

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

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

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

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

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


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

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

Надо бы ещё совет «Пользуйтесь ключом -p».

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


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

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

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


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

Про isteadOf я писал когда-то заметку, настройка удобна, особенно когда работаешь с разными ремоутами
Крутой конфиг, спасибо!
Я правда не сторонник заводить на всё алиасы, потому как прыгал часто на чужие терминалы, но как пример — очень классно :)
Fast forward при распространённых workflow почти никогда не случается — 90% случаев заканчиваются лишним merge'ем, совет как раз в том что стоит контролировать два разных действия, если человек умеет пользоваться pull'ом, то этот совет ему уже не нужен :)
Сложные вещи гораздо реже используются и зачастую требуют много мотивационного сопровождения. Не всегда это удобно в формате статьи потреблять. Например про один git reset можно написать статью больше чем предложенная.
Если прямо послушать, то можно прямо мои лекции и послушать :))

Information

Rating
Does not participate
Date of birth
Registered
Activity

Specialization

Specialist
Lead
From 5,000,000 ₽