#фишка дня
Продолбался весь день с подготовкой релиза. С cherry-pick-ами нужных коммитов. Шутки про черрипики точёны оставьте себе.
В чём же проблема?
А в том, что наша команда работает по trunk-модели. Всё сливается в мастер, мастер автоматически релизится как Latest-версия продукта и отправляется в тестирование.
Продакшен-релиз, полученный из стабильного мастера (trunk), обзывается как минорный в рамках модели семантического версионирования.
Когда нужен релиз, а транк не считается стабильным — выбираем нужные коммиты и релизим патч-релиз из своей ветки.
Очень важный момент здесь: время, когда транк считается нестабильным, должно быть сведено к минимуму. В любой момент команда должна иметь возможность релизить текущее состояние проекта.
Для этого реализуются различные feature-флаги и прочие условные условности для разделения потоков пользователей продукта по фичам.
Естественно, такое состояние удерживать не всегда просто, потому череда патч-релизов может быть очень длинной. Это не то чтобы плохо само по себе...
Плохо когда вы забыли о гигиене и смешали коммиты от двух фичей — свободной к релизу и нестабильной. Или когда не засквошили PR-коммит (мой случай).
Тогда выборка черри-пиков может быть не самым приятным занятием. А грязные черри-пики штука очень неприятная.
Так вот, про что же фишка дня? А вот про то, что в процессе я выяснил: совсем не обязательно делать checkout коммита по его хэшу, можно по сообщению! Буквально:
Причём, сообщение не надо вспоминать полностью!
В итоге, git выберет ближайший к вам такой коммит. Уютно!
В общем, соблюдайте гигиену репы, котаны. Не долбитесь весь день в черрипики.
#git #til #commit
Продолбался весь день с подготовкой релиза. С cherry-pick-ами нужных коммитов. Шутки про черрипики точёны оставьте себе.
В чём же проблема?
А в том, что наша команда работает по trunk-модели. Всё сливается в мастер, мастер автоматически релизится как Latest-версия продукта и отправляется в тестирование.
Продакшен-релиз, полученный из стабильного мастера (trunk), обзывается как минорный в рамках модели семантического версионирования.
Когда нужен релиз, а транк не считается стабильным — выбираем нужные коммиты и релизим патч-релиз из своей ветки.
Очень важный момент здесь: время, когда транк считается нестабильным, должно быть сведено к минимуму. В любой момент команда должна иметь возможность релизить текущее состояние проекта.
Для этого реализуются различные feature-флаги и прочие условные условности для разделения потоков пользователей продукта по фичам.
Естественно, такое состояние удерживать не всегда просто, потому череда патч-релизов может быть очень длинной. Это не то чтобы плохо само по себе...
Плохо когда вы забыли о гигиене и смешали коммиты от двух фичей — свободной к релизу и нестабильной. Или когда не засквошили PR-коммит (мой случай).
Тогда выборка черри-пиков может быть не самым приятным занятием. А грязные черри-пики штука очень неприятная.
Так вот, про что же фишка дня? А вот про то, что в процессе я выяснил: совсем не обязательно делать checkout коммита по его хэшу, можно по сообщению! Буквально:
git checkout ':/add multiselect to ui kit'Причём, сообщение не надо вспоминать полностью!
В итоге, git выберет ближайший к вам такой коммит. Уютно!
В общем, соблюдайте гигиену репы, котаны. Не долбитесь весь день в черрипики.
#git #til #commit
🤩11👍6
#фишка дня
Продолбался весь день с подготовкой релиза. С cherry-pick-ами нужных коммитов. Шутки про черрипики точёны оставьте себе.
В чём же проблема?
А в том, что наша команда работает по trunk-модели. Всё сливается в мастер, мастер автоматически релизится как Latest-версия продукта и отправляется в тестирование.
Продакшен-релиз, полученный из стабильного мастера (trunk), обзывается как минорный в рамках модели семантического версионирования.
Когда нужен релиз, а транк не считается стабильным — выбираем нужные коммиты и релизим патч-релиз из своей ветки.
Очень важный момент здесь: время, когда транк считается нестабильным, должно быть сведено к минимуму. В любой момент команда должна иметь возможность релизить текущее состояние проекта.
Для этого реализуются различные feature-флаги и прочие условные условности для разделения потоков пользователей продукта по фичам.
Естественно, такое состояние удерживать не всегда просто, потому череда патч-релизов может быть очень длинной. Это не то чтобы плохо само по себе...
Плохо когда вы забыли о гигиене и смешали коммиты от двух фичей — свободной к релизу и нестабильной. Или когда не засквошили PR-коммит (мой случай).
Тогда выборка черри-пиков может быть не самым приятным занятием. А грязные черри-пики штука очень неприятная.
Так вот, про что же фишка дня? А вот про то, что в процессе я выяснил: совсем не обязательно делать checkout коммита по его хэшу, можно по сообщению! Буквально:
Причём, сообщение не надо вспоминать полностью!
В итоге, git выберет ближайший к вам такой коммит. Уютно!
В общем, соблюдайте гигиену репы, котаны. Не долбитесь весь день в черрипики.
#git #til #commit #бородач
Продолбался весь день с подготовкой релиза. С cherry-pick-ами нужных коммитов. Шутки про черрипики точёны оставьте себе.
В чём же проблема?
А в том, что наша команда работает по trunk-модели. Всё сливается в мастер, мастер автоматически релизится как Latest-версия продукта и отправляется в тестирование.
Продакшен-релиз, полученный из стабильного мастера (trunk), обзывается как минорный в рамках модели семантического версионирования.
Когда нужен релиз, а транк не считается стабильным — выбираем нужные коммиты и релизим патч-релиз из своей ветки.
Очень важный момент здесь: время, когда транк считается нестабильным, должно быть сведено к минимуму. В любой момент команда должна иметь возможность релизить текущее состояние проекта.
Для этого реализуются различные feature-флаги и прочие условные условности для разделения потоков пользователей продукта по фичам.
Естественно, такое состояние удерживать не всегда просто, потому череда патч-релизов может быть очень длинной. Это не то чтобы плохо само по себе...
Плохо когда вы забыли о гигиене и смешали коммиты от двух фичей — свободной к релизу и нестабильной. Или когда не засквошили PR-коммит (мой случай).
Тогда выборка черри-пиков может быть не самым приятным занятием. А грязные черри-пики штука очень неприятная.
Так вот, про что же фишка дня? А вот про то, что в процессе я выяснил: совсем не обязательно делать checkout коммита по его хэшу, можно по сообщению! Буквально:
git checkout ':/add multiselect to ui kit'Причём, сообщение не надо вспоминать полностью!
В итоге, git выберет ближайший к вам такой коммит. Уютно!
В общем, соблюдайте гигиену репы, котаны. Не долбитесь весь день в черрипики.
#git #til #commit #бородач
❤16👍4