Скажем, я пишу код для билета и проверяю его на проверку кода (набор изменений A). Обзор возвращается, иллюстрируя некоторые изменения, которые необходимо внести. Я вношу необходимые изменения и проверяю его (создание набора изменений B). Предположим, что набор изменений B отображает набор изменений. При устаревании, когда приходит время для слияния (возможно, от соединительной линии к ветке развертывания), должны ли быть объединены оба набора изменений, чтобы сохранить историю или только окончательный, правильный набор изменений?За тот же билет, слияние только последних правильных изменений по сравнению с полной историей?
У меня создалось впечатление, что правильное слияние будет содержать все изменения, внесенные в файл, чтобы история могла быть сохранена, и в trunk нет никаких висячих наборов изменений. Тем не менее, я получаю некоторое сопротивление этому в моей команде. Мысли?
В чем их аргумент против сохранения истории изменений? это зависит от вашей философии в отношении того, что такое контроль источника. если он предназначен для представления (a) какой-то идеальной версии вашего кода, где никто никогда не совершал ошибку или (б) просто самого современного понимания. –
По большей части кажется, что им просто не нравятся стычки слияния более чем одного набора изменений с последующими ветвями. Это не так аккуратно. Но я с трудом жертвую точностью за что-то вроде аккуратности. – WickerPopstar
Если это проблема, я бы подумал о переключении на tfs git. Слияние нескольких коммитов не является проблемой. –