Как уменьшить количество изменений в ветке?
Начали работу над задачей, создали ветку, начали менять код, запостили изменения. И вот находим совершенно новую, неожидаемую проблему, которая мешает выполнению данной задачи, но никак не связана с ней. Что теперь делать с изменениями для этой новой проблемы?
Например: задача добавить новую колонку в для отображения в таблице. Добавили. Но для теста нужно еще обновить данные в таблице /по умолчанию нет ничего/, а вот обновить данные не получается, хотя раньше можно было.
Не понял, что мешает добавить?
Ничего не мешает, вопрос совершенно в другом.
Добавили мы колонку и еще, что надо, но теперь нужны данные, а кнопа не работает, нужно править. Так вот что делать с этими изменениями?
И кстати, это просто пример, на самом деле все сложнее, но принцип тот же.
Не понял. Нужно править, но через короткое время в табле появится нужная колонка, и всё исправленное нужно обратно возвращать? И вы типа не хотите создавать новую тестовую ветку, которую через пару дней всё равно мерджить придётся? А в чём проблема делать короткоживующие ветки? В разных обущающих уроках по контролю версий часто показывают варианты, где ветка из пары коммитов состоит всего, а потом либо убивается, либо мёрджится. Да там даже не всю ветку мёрджить надо - лишь те файлы, которые вы меняли для тестов со своей таблицей.
Тебе интересно что стоит сделать в git-е,
как одно из направлений. Но вообще то, проблема гораздо шире.
Есть PBI, есть Task, есть бранч к таску, есть время выполнения таски, есть PR. Есть код, есть изменения непосредственно относящиеся к задаче, а есть нет.
Все это нужно синхронизировать и для этого нужно иметь чётко описанный алгоритм, что делать в каком случае.
Вот например, комментарий с ошибкой написан, код неправильно отформатирован, имя функции неправильное и т.п.
Ну или что бы идти дальше, нужно сделать небольшие изменения, не относящиеся непосредственно к задаче.
Новая ветка для проблемы - откуда создаем ветку и когда? Может достаточно изменить одну троку, а может и по некоторому количеству строк в разных файлах.
Если из мастера, то там могут быть уже новые изменения от другого чела. Да и дальнейшая работа может не иметь смысла без предыдущей правки. Если из текущей, то как делать PR только для этих изменений, в файле то могут быть изменения и для текущей задачи.
Обычно куски проекта изолируют, чтобы более-менее не зависеть от веток других разработчиков, а внутри команды планируют, кто когда и какую ветку будет делать и когда будут их мёрджить или убивать, чтобы веток не сильно много было и они не сильно затягивались по времени. В ветке же вы обычно только свою часть правите, а не по всему проекту тестовые изменения раскидываете? Так что при слиянии число конфликтов будет минимальным. Ну а перед слиянием своей ветки подтягиваете последнюю версию из мастера, чтобы протестить с уже последними изменениями. Это вроде даже автоматом делается - сначала чекаут или получение последний версии, а потом чекин.
Я тоже не понял в чем проблема.
1) Все что надо для решения задачи делаешь в одной ветке, потом в мастера пихаешь (ну или в stage у кого как принято)
2) Делаешь ветку для подзадачи из данной ветки и в конце пихаешь в ветку задачи (а потом как всегда в мастера). Это если не очень уверен в нужности или это просто эксперимент
3) Если подзадача полезна другим уже сейчас и они не хотят ждать, делаешь новую ветку из мастера и туда же ее мержишь, а потом подсавываешь в свою рабочую ветку (вместе со всеми другими). Фактически отдельная задача, типа хот-фикс.
Смотря какая проблема. Если в проде, создаётся новая задача - хотфикс, создается новая ветка от главной ветки (мастер или мэйн), дальше все по плану - PR в мастер. После этого мастер сливается с веткой для задачи, и работа идёт дальше.
Если проблема только для реализации задачи, фиксите ее прямо в ветке для задачи.
Все что надо для решения задачи делаешь в одной ветке, потом в мастера пихаешь
Как можно пихать в мастер то что не работает?
Делаешь ветку для подзадачи из данной ветки
иногда бывает так что проблема накатывается комом или просто видишь рефакторинг. Значит всё туды и открывать новую таску? только на что? Если хочется много не связанных исправлений, которые-то сразу и не видно.
постоянно открывать новые и на них PR в новую задачу, так PR задачи будет с мастером сравнивать и там будут изменения не имеющие отношения к задаче.
Если подзадача полезна другим уже сейчас
Кто должен определять степень полезности?
Да и смысла в подзадаче может и не быть, пока не будут активированы новые изменения.
Пока приходится делать двойную работу, делать локально как надо, а после смотреть что относится к задача, а что нет и разбивать на новые ветки.
Хотя вот попалась хитрая штука. В блазоре "хтмл код" можно записывать в одном файле с "cs", а можно и в разных.
Согласно текущему соглашению всё должно быть в разных. Но это можно сделать только когда вообще никто не будет работать над этим проектом.
Главная ветка теперь называется 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
Так-то это простенький параметр git
Это никого не интересует, так как PR смотрят в azure, а не локально. Фактически, это что то наподобие вывода windiff в веб морде.
Хотя мне больше нравится смотреть изменения локально в beyoud compare. Но комменты всё равно только в azure можно писать.
Ну а меня (слава богу) не интересует azure от слова совсем. Ибо по сравнению не только с амазоном, но и с gcp это лютое отсталое гм... мелкомягкое уродство :) Начиная от вики и кончая их CI.
Могу только посоветовать перейти на более приличный клиент, если твой не даёт возможности пользоваться базовыми функциями, гит он повсюду гит.
А пока что кушайте, не обляпайтесь. Быстрый поиск говорит что мелкомягкие не поумнели: https://developercommunity.visualstudio.com/t/pull-request...
P.S. Ну и в bc тоже можно изменения с пробелами и переносами игнорировать, емнип.
не интересует azure от слова совсем
К сожалению сравнивать было не с чем, да и незачем. Нужно работать в том, что дали.
Ибо по сравнению не только с амазоном, но и с gcp
попробую поискать, но интересно и конкретное мнение, что действительно лучше, от чего в восторге?
Лучше confluence для теам документации пока не встречал, но и вики у мс вполне нормальная, можно загрузить всё локально и пользовать любимый md редактор.
перейти на более приличный клиент, если твой не даёт возможности
проблема то не у меня, а у других. Хотя один фиг всё писать нужно в azure
Ну а меня (слава богу) не интересует azure от слова совсем. Ибо по сравнению не только с амазоном, но и с gcp это лютое отсталое гм... мелкомягкое уродство :) Начиная от вики и кончая их CI.
Только МС предлагает полный спектр продуктов под ключ - облака, операционки, базы данных, средства разработки, языки и фреймворки разработки, платформы - от железных до софтовых. И всё это интегрируется куда лучше, чем у всяких Амазонов, Эпплов, Гуглов, где поставщики всего этого разные, плюс тоже свои заморочки есть.
попробую поискать, но интересно и конкретное мнение, что действительно лучше, от чего в восторге?
Надо пробовать, руками щупать. С azure я был только в одном проекте, в 2020, чуть больше полугода. Так что на глубинный взгляд не претендую. Что запомнилось: как только что-то чуть сложнее чем 2+2 становится, начинаются пляски с бубном. Или вообще никак.
То что в Jira/Jenkins/Gitlab(Bitbucket) и gcp/aws делается за минуту частно сделать нельзя. Очень долго мучались с пайплайном. Типа автоматом собирай и деплой новую версию после того, как пулл реквест закоммичен. Что конкретно не получалось... Не помню. Что-то с авторизацией. Помню постоянные сидения с нашим azur-овсим спецом, когда я ему показывал, мол, вот так я деплою новую версию на gcp из Jenkins-а, сделай так же в этих пайплайнах.
Правила кто куда может коммитить, что мёржить и те пе в азуровском гите... После гитлаба это тихий ужас. Задолбались все :)
Не помню. Что-то с авторизацией
жалко, с авторизацией никаких проблем не припомню, но у нас все на мс.
Jira когда то был в каком то проекте, но кроме названия тоже ничего не помню.
Во всех проектах azure и дома тоже. Так что сравнивать практически просто не с чем
типа автоматом собирай и деплой новую версию после того, как пулл реквест закоммичен
именно так примерно и работает.
Вот пришлось, даже следующую хотелку делать:
- после комитта любой ветки, автоматом стартуют build и тесты.
- Мастер дополнительно деплоится автоматом на "девелопер сервер".
- Из любой ветки можно сделать "релиз".
- Любой "релиз" можно задеплоить на девелопер/тест/продуктивный сервер, На два последних с дополнительным подтверждением.