Roman
в этом коммите будет 1 фича. Все рефакторинги и форматирование будет касательно нового кода, написанного в этой ветке. Существующий код рефакторится и форматируется в отедльных ветках, которые так же сквошатся
Vasily
Я тут поддержку @atsapura
x
в этом коммите будет 1 фича. Все рефакторинги и форматирование будет касательно нового кода, написанного в этой ветке. Существующий код рефакторится и форматируется в отедльных ветках, которые так же сквошатся
Не оч. понятно. По ветке на форматирование? И в отделеой ветке сама фича?
Vasily
Не,Роман имеет ввиду схлопывание коммитов в один
Vasily
Который пойдет на пр
Bonart
в этом коммите будет 1 фича. Все рефакторинги и форматирование будет касательно нового кода, написанного в этой ветке. Существующий код рефакторится и форматируется в отедльных ветках, которые так же сквошатся
Ага, сейчас. Любая фича состоит из а) подготовительных рефакторингов б) новых типов и тестов для них в) собственно изменений поведения приложения г) удаления ставшего ненужным кода
Vasily
Bonart
Дополнительно есть смысл выделять в отдельные коммиты форматирование и автоматические рефакторинги
Bonart
Гит добавляет отдельные коммиты на перемещения и переименования файлов
Roman
Ага, сейчас. Любая фича состоит из а) подготовительных рефакторингов б) новых типов и тестов для них в) собственно изменений поведения приложения г) удаления ставшего ненужным кода
ну, у нас такой подход хорошо работает. И продукт сложный, и фичи серьезные, а подход работает
Bonart
Ну да, раньше и подход фигачь в транк работал. А еще раньше контроль версий - это был не инструмент а роль
Roman
ясно, спасибо
Bonart
И тоже все работало
Bonart
Собственно зачем все это нужно. Рано или поздно наступает момент, когда надо разобраться, на кой фиг появился конкретный кусок кода и какие перемены вызвало именно его появление
Bonart
И вот находим мы, что код появился как результат здоровенного сквош-коммита, добавляющего киллер-фичу
Bonart
И остаемся один на один с коммитом врукопашную
Hog
И даже заблеймить некого!
Vasily
Ну, собственно, на каждую фичу должна быть документация
Vasily
И список задач
Vasily
Каждая из которых идёт отдельным пулл реквестом
Bonart
Ну, собственно, на каждую фичу должна быть документация
Которая при расхождении с кодом бесполезна. Да и описывает совсем не код. И компилятор ее не понимает
Vasily
Которая при расхождении с кодом бесполезна. Да и описывает совсем не код. И компилятор ее не понимает
Ну если делать пр по 5к строк, мало что получится
Vasily
Даже с историей коммитов
Vasily
Разговор сейчас скорее о скейлинге больших команд разработки, имхо
Bonart
Ну если делать пр по 5к строк, мало что получится
Можно и не по 5к. Достаточно перемешать разные логические изменения
Фил Ранжин
Они и правда оставляют желать лучшего
Vasily
Можно и не по 5к. Достаточно перемешать разные логические изменения
Ну тут проблема скорее решается декомпозицией задач на более мелкие
Hog
Разговор сейчас скорее о скейлинге больших команд разработки, имхо
У меня было и 5 человек с «мастером» на самба-шаре, и ЦВС на 10, и СВН на 1500 и гит на одного. Человек ко всему привыкает :)
Bonart
Если на одно логическое изменение - один коммит, то разобраться и что-то зряче исправить легко. А если в коммите смешаны рефакторинги с модификациями функциональности - у меня для вас плохие новости
Hog
Vasily
Vasily
И там для того, что ты описал, и придуманы пр
Bonart
Я больше про тулинг вокруг и поддержку идешками
Студия мерк поддерживает, черепашка у мерка лучше любого гуя для гита, с гитхабами и прочим - можно пушить из мерка в гит
Bonart
И там для того, что ты описал, и придуманы пр
Пр - это работа с ветками. Как они разбиты на коммиты - неважно с точки зрения пр
Hog
Vasily
Пр - это работа с ветками. Как они разбиты на коммиты - неважно с точки зрения пр
Не, тут не соглашусь
Vasily
Пр он по факту и является логической единицей коммита в тот же фичебранч
Hog
Путь гита - командная строка :)
Vasily
Что там наговнякал с коммитами кодер в локальном репо - его дело
Vasily
Дальше он оформляет пр на задачу
Vasily
Типа рефакторинг и прочее
Bonart
Не, тут не соглашусь
Возможно. Итак у нас два пр - один для ветки из одного коммита, второй для ветки из пачки коммитов. Где ревьюеру проще найти левое изменение?
Vasily
Vasily
Я знаю, что коммитил в данном пр один человек
Vasily
Мне важен дифф итоговый
Vasily
Для определения косяков
Bonart
Тогда пофиг
Правда? В одном случае ревьер имеет информацию о цели конкретного коммита. В другом - только о задаче в трекере. Особенно забавно если решение входит 5 рефакторингов на 500 строк в сумме, 2 переименования файлов, 3 перемещения, 1 модификация поведения на 5 строк
Hog
И она у гита абсолютно неконсистентная
Наверное разные команды пилили разные команды. И не договорились :)
Bonart
Для определения косяков
Косяк намного проще определить, зная цель каждого изменения в коде. Иначе придется по каждому чиху звать автора.
Bonart
Наверное разные команды пилили разные команды. И не договорились :)
Я к тому что путь гита - это гитхаб. Он классный. А консоль у него - не будем о грустном.
Dr. Friedrich
Bonart
В свою собственную репу можешь пушить как хочешь.
Так ей надо потренироваться на кошках в гитфлоу
Анна
я решила, что фича-бранчей с мержем потом в мастер мне хватит для начала, чтобы поддержать минимальный порядок
Vasily
Косяк намного проще определить, зная цель каждого изменения в коде. Иначе придется по каждому чиху звать автора.
Я понял проблему.Кейс валидный,когда ревьюит кто-то типа архитектора.Но такой сценарий сам по себе не оч
Vasily
Потому как он сразу подразумевает элитарность и разделение на простых исполнителей и тех, кто их код с смотрит
Vasily
Этого лучше избегать, там ботлнеки гигантские
Bonart
Я понял проблему.Кейс валидный,когда ревьюит кто-то типа архитектора.Но такой сценарий сам по себе не оч
Первый кейс - первичное ревью. Второй - разбор полетов, особенно если автор давно забыл про тот код или вообще недоступен. Это собственно внутреннее качество продукта второго порядка. Первый порядок - качество кода, второй - качество истории его изменений
Hog
Потому как он сразу подразумевает элитарность и разделение на простых исполнителей и тех, кто их код с смотрит
Нет. Просто код смотрит, не автор, а пара соратников. Наверное ты не работал с формальным ревью процессом никогда...
Vasily
Dr. Friedrich
Так ей надо потренироваться на кошках в гитфлоу
Это вы уже сами додумали про гитфлоу :)
Фил Ранжин
Bonart
Потому как он сразу подразумевает элитарность и разделение на простых исполнителей и тех, кто их код с смотрит
Наоборот. История должна помочь понять код всем кто его читает. Суперархитектор нужен как раз со спагетти-сквошингом
Фил Ранжин
Студия мерк поддерживает, черепашка у мерка лучше любого гуя для гита, с гитхабами и прочим - можно пушить из мерка в гит
А тортоис отвратительно выглядит
Hog
А те, кто использует, обречены на вечные страдания.
Зато попадут в рай - уже настрадались при жизни
Bonart
А тортоис отвратительно выглядит
Работавшим с гитовыми гуями сложно упрекать другие инструменты в плохом внешнем виде
Hog
Работавшим с гитовыми гуями сложно упрекать другие инструменты в плохом внешнем виде
Один на электроне (не помню названия) оч вылизанный уй
Bonart
Один на электроне (не помню названия) оч вылизанный уй
На электроне только .уй и может быть. А мне инструмент нужен.
Фил Ранжин
Работавшим с гитовыми гуями сложно упрекать другие инструменты в плохом внешнем виде
Мне поддержки в vscode хватает