Как уменьшить количество изменений в ветке?
Главная ветка теперь называется main ;)
Чуть не поседел. Побежал проверять. Нифига. В версии 2.40.1 от 2023-04-25 всё ещё master. Так что это только богомерзкие гитхабы с гитлабами такой политкорректной хренью занимаются.
И ваще, у меня в предках достаточно крепостных, чтобы я перестал использовать терминологию master-slave :)
P.S. А в Африке живут негры. Нас так в школе учили (c)
С удовольствием так бы и делал. Но хотят обратное. Как найти золотую середину?
Кто хочет? Вот кто хочет, тот пусть и объясняет.
Адекватные договариваются внутри команды. В основном для того, чтобы не править одно и то же два раза. Если ты работаешь один, то тебе глубоко пофиг где ты что правишь.
Обычно договаривались так: косметические изменения (нашёл опечатку, переменная криво названа, комментарий добавить) молча делаются в ветке, с которой ты сейчас работаешь. С найденными ошибками сложнее. Насколько критична ошибка? Как долго я буду работать над текущей веткой? Сколько по времени займёт исправление ошибки?
Если ошибка серьёзная, то для неё заводится и отдельный тикет и отдельная ветка. Чтобы как можно лучше задокументировать когда она была поправлена. Если не критична, то как долго я буду работать над текущей веткой? Если долго, то создаём новую ветку. Чтобы другие не ждали исправлений или не правили параллельно. Если не долго, то как много времени надо поправить на исправление? Если не больше 1-2 часов (тут сами договаривайтесь), то делам в текущей. Если больше - выносим в отдельную ветку. Как-то так.
косметические изменения
ну тут тоже не все так просто. Вот хотя бы есть длинная строка, код форматер сделает ее правильной без проблем, но народ будет видеть изменения в нескольких строках и искать а может там еще что то и изменено?
Но фактически да - отсутствует набор правил для правки кода. Вот только как их написать покороче.
PR и таски создаются для решения реальной проблемы, соответственно, если сомневаешься, то просто занимайся своей проблемой и все. Главный критерий: твой код должен работать и твоя проблема должна быть решена. Либо ты решил проблему, либо нет, все остальное не имеет значения.
Нужно ли делать что-то еще? Это все неформально. Форматирование делается автоматически (если люди не могут сами договориться). Все что не влияет на функциональность можно вполне улучшать (комментарии, доки).
Ну есть еще кое-какие критерии:
- Если не чувствуешь уверенность, например, это чужой проект, то и не надо лишнего ничего делать.
- Если чувствуешь собственность и тебе с этим жить дальше, то вполне можно и даже нужно где-то что-то подправлять, что не относится к задача. Типа просто мимо проходил и решил подправить. Но тут надо знать меру.
- Если это никто не заметит и не оценит и мне это не надо, то я бы вряд ли что-то делал
- Есть куча проектов со своей культурой и правилами, а потому желательно адаптироваться и не пытаться изменить эти правила.
- Частенько ты можешь попросить коллегу сделать нужные тебе изменения в его PR, или наоборот тебя могут попросить внести пару строк. Это если изменения лучше относятся к другому PR, который уже вот-вот запушат в мастера. Ну типа "вставь пару строк логов, я хочу видеть, что там он пишет".
все остальное не имеет значения.
Ну вот к этому всё и сводится, похоже. 
Все что не влияет на функциональность можно вполне улучшать
В этом то и проблема. Функциональность не страдает, но делать низзя.
Было
func1(longNamelongNamelongNamelongNamelongName1, longNamelongNamelongNamelongNamelongName2, longNamelongNamelongNamelongNamelongName3);
Стало
func1(
longNamelongNamelongNamelongNamelongName1,
longNamelongNamelongNamelongNamelongName2,
longNamelongNamelongNamelongNamelongName3
);
Если это никто не заметит и не оценит
Еще не встречал чтобы было как то по другому. Ну разве в каких то редких случаях.
В этом то и проблема. Функциональность не страдает, но делать низзя.
Кто это сказал? Он это требование как-то обосновал? Или так, трепанул не подумав? В проекте есть какие-то требования к коду? Максимальную длину строки для читаемости ограничивали?
Он это требование как-то обосновал?
Когда видишь изменения невозможно быстро оценить, что это просто разнос строк. Возможно там были сделаны и еще какие то изменения.
Это же в примере только так просто.
В проекте есть какие-то требования к коду?
Конечно, stylecop даже проверяет совсем дурные правила (типа в строке не должно быть "конечных" пробелов)
Максимальную длину строки для читаемости ограничивали?
Да, но в данном конкретном случае длина меньше допустимой
В системах контроля версий нужно сохранять лишь семантические конструкции, а не весь синтаксис вплоть до отдельного пробела. Тогда при загрузке на любую машину с любыми правилами форматирования у каждого будет так, как ему нравится, при этом код будет по сути оставаться тем же самым. Автоматически же решится большинство проблем с обновлением синтаксиса до последних версий языка - просто выбрал версию, и если семантика однозначно отображается на новый синтаксис, то получаешь его.
Когда видишь изменения невозможно быстро оценить, что это просто разнос строк. Возможно там были сделаны и еще какие то изменения.
Познакомь его с параметром "не показывать изменения whitespaces"
Да, но в данном конкретном случае длина меньше допустимой
Жаль. Понятие "так лучше читается" у всех разное, тяжелее спорить.
Познакомь его с параметром "не показывать изменения whitespaces"
Мы уже говорили об этом - этого недостаточно. Правил форматирования слишком много - на все параметров не напасёшься.
Ещё раньше я предлагал, чтобы код сохранялся-загружался автоматически в автоформате, заданном у каждого пользователя и в самой репе. Т.е. загрузил я файл для сравнения с моей версией - всё отформатировалось как у меня на машине. Загрузил кто-то другой - как у него.
А где azure PR? :)
В github-е кнопочка есть (ну или была, давно не смотрел): https://github.blog/2018-05-01-ignore-white-space-in-code-...
Так-то это простенький параметр git diff-а: -w