Если в очень упрощённом варианте: сделали 1 и 2, отдали в тестирование, начинаем делать 3, зависящую от 1 и 2. В 1 и 2 тестировщик нашёл баги, правим, 3 нужно обновить. И так несколько раз.
Как будут мержится известно, но 1 и 2 раньше. Предполагается, что к моменту передачи в тестирование 3 фичи 1 и 2 уже будут выпущены (или по крайней мере протестированы).
Всё в одной не удобно — сложнее тестировать, сложнее планировать и следить за процессом разработки.
Как быть в таком случае:
Есть ветки master, feature-1 (основа — master), feature-2 (основа — master). В каждую из веток регулярно коммитят.
Возникает задача параллельно делать feature-3, которая будет включать себя изменения из feature-1 и feature-2 (и соответственно изменения из master).
При этом по ходу разработки в feature-3 нужно регулярно подтягивать изменения feature-1 и feature-2 (которые меняются и регулярно ребейзятся на master).
Если в feature-3 для получения изменения из 1 и 2 я буду использовать rebase, то коммиты постоянно будут дублироваться (что логично, ведь git не будет знать о том, что коммиты в feature-1 и feature-2 «те же самые»).
Если использовать merge, то история загрязнится мердж-коммитами и почти невозможно будет получить «чистую» история по feature-3.
Как вариант, для получения изменений делать squash всех коммитов в feature-3 и уже потом rebase на ветки, но теряется история, что не удобно.
Может быть я упускаю какое-то простое очевидное решение?
Ваш случай — исключение. Ну кто в здравом уме работает с «живой» базой на 300 тысяч пользователей на рабочем сервере? А даже если и работает (чтобы отловить чего-нибудь очень специфичное), то проверяет все запросы и действия перед выполнением. Из-за дебильных ситуациях обычно и появляются дебильные интерфейсы с миллионом подтверждений.
Конкретно описанная проблема никак не решается, т.к. виноват не интерфейс, а невнимательный пользователь.
В общем случае можно делать задержку на выполнение критичных команд, например после выполнения TRUNCATE появляется надпись «таблица <big>users</big> будет очищена через 10 секунд. |отменить очищение таблицы <big>users</big>| |очистить таблицу <big>users</big> без ожидания прямо сейчас|»
Я очень удивился когда Старкрафт 2 на 6600 GT и 1920*1200 летал на чуть выше средних настройках, как будто игра была выпущена за год до выпуска карточки. (Стоит добавить, что любая другая игра требует понижения настроек для приемлемой игры.)
Хотелось бы кроме кнопочки «посмотрел эпизод» кнопочку «скачал эпизод» и чтобы на странице profile/ отмеченные как уже скачанные как-то отличались от не отмеченных.
Как будут мержится известно, но 1 и 2 раньше. Предполагается, что к моменту передачи в тестирование 3 фичи 1 и 2 уже будут выпущены (или по крайней мере протестированы).
Всё в одной не удобно — сложнее тестировать, сложнее планировать и следить за процессом разработки.
Есть ветки master, feature-1 (основа — master), feature-2 (основа — master). В каждую из веток регулярно коммитят.
Возникает задача параллельно делать feature-3, которая будет включать себя изменения из feature-1 и feature-2 (и соответственно изменения из master).
При этом по ходу разработки в feature-3 нужно регулярно подтягивать изменения feature-1 и feature-2 (которые меняются и регулярно ребейзятся на master).
Если в feature-3 для получения изменения из 1 и 2 я буду использовать rebase, то коммиты постоянно будут дублироваться (что логично, ведь git не будет знать о том, что коммиты в feature-1 и feature-2 «те же самые»).
Если использовать merge, то история загрязнится мердж-коммитами и почти невозможно будет получить «чистую» история по feature-3.
Как вариант, для получения изменений делать squash всех коммитов в feature-3 и уже потом rebase на ветки, но теряется история, что не удобно.
Может быть я упускаю какое-то простое очевидное решение?
Конкретно описанная проблема никак не решается, т.к. виноват не интерфейс, а невнимательный пользователь.
В общем случае можно делать задержку на выполнение критичных команд, например после выполнения TRUNCATE появляется надпись «таблица <big>users</big> будет очищена через 10 секунд. |отменить очищение таблицы <big>users</big>| |очистить таблицу <big>users</big> без ожидания прямо сейчас|»