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

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

Ничё не понял, но если одно мешает другому, значит они связаны.

вот пример. В желтой рамке, то что было до того, внизу что хотят. Забыл только стереть содержимое ячеек, поначалу все пустые.

но если одно мешает другому, значит они связаны.

задача - добавить колонку, кнопка ну никак не связана с этой задачей.

Не понял, что мешает добавить? В таблице нет колонки ещё и она не мапится на гуй, или что? Ну сделайте промежуточный класс, который принимает данные из таблицы с одной колонкой и ещё имеет временную вторую колонку с любыми данными.

Не понял, что мешает добавить?

Ничего не мешает, вопрос совершенно в другом.

Добавили мы колонку и еще, что надо, но теперь нужны данные, а кнопа не работает, нужно править. Так вот что делать с этими изменениями?

И кстати, это просто пример, на самом деле все сложнее, но принцип тот же.

Не понял. Нужно править, но через короткое время в табле появится нужная колонка, и всё исправленное нужно обратно возвращать? И вы типа не хотите создавать новую тестовую ветку, которую через пару дней всё равно мерджить придётся? А в чём проблема делать короткоживующие ветки? В разных обущающих уроках по контролю версий часто показывают варианты, где ветка из пары коммитов состоит всего, а потом либо убивается, либо мёрджится. Да там даже не всю ветку мёрджить надо - лишь те файлы, которые вы меняли для тестов со своей таблицей.

Начали работу над задачей, создали ветку, начали менять код, запостили изменения. ...

Тебе интересно что стоит сделать в git-е, так?

Новая ветка для проблемы; когда будет решена - слияние с веткой для задачи.

и с мастером!

Это уже детали.

Мастер, кстати, не политкорретно ;)

Пережитки сабвершна или, прости господи, clearcase.

Не понял

Сорри, не знаю что еще нужно пояснить

Тебе интересно что стоит сделать в git-е,

как одно из направлений. Но вообще то, проблема гораздо шире.

Есть PBI, есть Task, есть бранч к таску, есть время выполнения таски, есть PR. Есть код, есть изменения непосредственно относящиеся к задаче, а есть нет.

Все это нужно синхронизировать и для этого нужно иметь чётко описанный алгоритм, что делать в каком случае.

Вот например, комментарий с ошибкой написан, код неправильно отформатирован, имя функции неправильное и т.п.

Ну или что бы идти дальше, нужно сделать небольшие изменения, не относящиеся непосредственно к задаче.

Новая ветка для проблемы - откуда создаем ветку и когда? Может достаточно изменить одну троку, а может и по некоторому количеству строк в разных файлах.

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

Мастер, кстати, не политкорретно ;)

Слияние с веткой белой мужской шовинистической свиньи подойдёт? ))

Обычно куски проекта изолируют, чтобы более-менее не зависеть от веток других разработчиков, а внутри команды планируют, кто когда и какую ветку будет делать и когда будут их мёрджить или убивать, чтобы веток не сильно много было и они не сильно затягивались по времени. В ветке же вы обычно только свою часть правите, а не по всему проекту тестовые изменения раскидываете? Так что при слиянии число конфликтов будет минимальным. Ну а перед слиянием своей ветки подтягиваете последнюю версию из мастера, чтобы протестить с уже последними изменениями. Это вроде даже автоматом делается - сначала чекаут или получение последний версии, а потом чекин.

Я тоже не понял в чем проблема.

1) Все что надо для решения задачи делаешь в одной ветке, потом в мастера пихаешь (ну или в stage у кого как принято)

2) Делаешь ветку для подзадачи из данной ветки и в конце пихаешь в ветку задачи (а потом как всегда в мастера). Это если не очень уверен в нужности или это просто эксперимент

3) Если подзадача полезна другим уже сейчас и они не хотят ждать, делаешь новую ветку из мастера и туда же ее мержишь, а потом подсавываешь в свою рабочую ветку (вместе со всеми другими). Фактически отдельная задача, типа хот-фикс.

Главная ветка теперь называется main ;)

Смотря какая проблема. Если в проде, создаётся новая задача - хотфикс, создается новая ветка от главной ветки (мастер или мэйн), дальше все по плану - PR в мастер. После этого мастер сливается с веткой для задачи, и работа идёт дальше.

Если проблема только для реализации задачи, фиксите ее прямо в ветке для задачи.

Все что надо для решения задачи делаешь в одной ветке, потом в мастера пихаешь

Как можно пихать в мастер то что не работает?

Делаешь ветку для подзадачи из данной ветки

иногда бывает так что проблема накатывается комом или просто видишь рефакторинг. Значит всё туды и открывать новую таску? только на что? Если хочется много не связанных исправлений, которые-то сразу и не видно.

постоянно открывать новые и на них PR в новую задачу, так PR задачи будет с мастером сравнивать и там будут изменения не имеющие отношения к задаче.

Если подзадача полезна другим уже сейчас

Кто должен определять степень полезности?

Да и смысла в подзадаче может и не быть, пока не будут активированы новые изменения.

Пока приходится делать двойную работу, делать локально как надо, а после смотреть что относится к задача, а что нет и разбивать на новые ветки.

Хотя вот попалась хитрая штука. В блазоре "хтмл код" можно записывать в одном файле с "cs", а можно и в разных.

Согласно текущему соглашению всё должно быть в разных. Но это можно сделать только когда вообще никто не будет работать над этим проектом.