Слияние TFS для пользователей, которые привыкли к VSS

Question

Я только что перенес команду из 7 разработчиков из VSS в TFS. Я перенес весь их код в папку DEV, которую я затем разветвлял в папку QA (которую я разветвлял в папку PROD). Разработчики обычно не работают с одними и теми же файлами, но есть несколько общих классов утилит. Весь код предназначен для большого веб-сайта ASP.NET. Когда разработчики готовы объединиться из DEV в QA, они хотят объединить только свои изменения. Например, предположим, что Developer1 работал над проектом в течение последних 3 месяцев, и он готов объединить весь свой код в QA. Однако Developer2 работал над другим проектом в течение последних 2 месяцев, который еще не готов к объединению. Изменения Developer1 и Developer2 никоим образом не зависят друг от друга, но они не разделены на разные структуры папок, и каждый из них регулярно делает последние обновления. Похоже, у разработчика1 нет способа объединить свои изменения, не объединив при этом все изменения разработчика2. В настоящее время developer1 просматривает окно Pending Changes и «Undoing Pending Changes» для всех изменений Developer2, но это отнимает много времени. Они могут объединять каждый файл по отдельности, но это также занимает много времени. Есть ли более простой способ? У меня будет коронарная болезнь, если я услышу, как еще один человек объяснит, насколько легче было работать в VSS.

Answer 1

Есть ли причина, по которой они, кажется, разветвляют все изменения, а не только свои собственные наборы изменений?

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

Answer 2

Похоже, лучшая стратегия (на будущее) - это работать над проектом. Если Dev1 и Dev2 работают над принципиально разными вещами, у каждого из них должна быть своя ветвь кода.

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

В вашей текущей ситуации вы делаете то, что называется "вишневым" слиянием. Это не забавная вещь (как вы выяснили), и она подвержена ошибкам PEBKAC . По этой причине слияния вишневого дерева настоятельно не рекомендуется. Тем не менее, если вам необходимо выполнить слияние по принципу «вишня», вы можете использовать некоторый контроль, объединяя изменения (вместо последних).

Чтобы сделать это, определите наборы изменений, которые Dev1 зарегистрировал в вашей ветви Dev, затем объедините эти наборы изменений с вашей основной веткой. Вам нужно будет сделать это по порядку от самого старого до самого нового, чтобы быть уверенным, что вы получите все файлы. Лучше всего, если вы собираетесь это сделать, - либо написать утилиту для этого, либо перейти к командной строке TF.EXE, чтобы вы могли объединить ваши слияния.

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

Ключевой урок, который вы изучаете здесь, заключается в том, что ваша стратегия / методология ветвления является одной из самых важных вещей в SCM (в целом). Мы перешли с StarTeam на TFS чуть более полутора лет назад, и когда мы это сделали, мы потратили около 4 месяцев на пересмотр нашего подхода к ветвлению, пока не пришли к тому, что соответствовало бы нашей среде и нашим процессам разработки.