Pull to refresh
18
0
Михаил Калашник @Splurov

Пользователь

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

ini_set('display_errors', 'on');
error_reporting(E_ALL);

$a = array('id' => 7);

echo $a[id];

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity