Intereting Posts
Как мы можем использовать контроль версий в общей рабочей среде? Как указать страницы github на пользовательскую домашнюю страницу html SVNKit как оболочка для C или C ++ svn: E155010: Ошибка пропущенного файла Commit Eclipse: возможно ли SVN выполнить основной проект, выполняя подпроект? Как изменить номер автоматической версии в bitkeeper? Автоматизация доступа к репозиторию Odyssey во время развертывания / выпуска программного обеспечения Как мне переместить Git Repo с Beanstalk в Github? Узел npm install, зависимость от зависимостей от установки конкретной версии Subversion (SVN) – обновление локального каталога с большими файлами Слияние двух ветвей Проблема структуры каталога проекта в Eclipse SVN Включить и игнорировать другой репозиторий Изменение имени автора предыдущих коммитов: ускоренная переадресация отклоняется каковы разные версии формата репозитория (для параметра core.repositoryFormatVersion) в git?

Лучшие рекомендации при создании нескольких тестовых ветвей

Недавно я начал использовать функциональность ветвления в git для поддержки моего проекта github, и я понимаю, как создавать ветки, переключаться между ними и объединять их. Тем не менее, большинство примеров, которые я видел, связаны с созданием одной ветви без хозяина, затем слияние новой ветви с мастером, если изменения должны быть сохранены. Я не нашел примеров для параллельной работы нескольких тестовых ветвей.

Например, я пытаюсь улучшить свой один из моих сценариев, и у меня есть три разные взаимоисключающие идеи для улучшения, поэтому я делаю три новых филиала. Я тестирую работу разных ветвей и решаю сохранить ее.

Должен ли я просто удалить две ветви, которые мне не нужны, а затем объединить финальную ветвь с мастером? Будут ли сохраняться данные из этих филиалов, чтобы я мог пересмотреть их, если это необходимо, или удалит ветви, чтобы удалить эти коммиты?

Я единственный вкладчик, поэтому нет проблем с конфликтами с другими участниками.

Solutions Collecting From Web of "Лучшие рекомендации при создании нескольких тестовых ветвей"

Если вы удаляете другие ветви, это не сразу удаляет коммиты; но если вы оставите коммиты без ссылок, они могут быть удалены. Существует процесс сбора мусора ( gc ), который выполняется в определенное время (или когда вы просите его запускать), и одна из его задач состоит в том, чтобы очистить «недоступные» объекты (такие как коммиты, которые не указываются как ref и не указана родительскими указателями других достижимых коммитов).

Поэтому, если вы хотите сохранить коммиты для использования в будущем, вы можете не захотеть удалить ветви. Или, если вы хотите удалить ветви – чтобы они не отображались в списках «unmerge branch» или что-то в этом роде, вы можете пометить главу каждой ветви, а затем удалить ветку.

Другой вариант – объединить каждую «неправильную» ветвь, а затем вернуть слияние

 A -------------- M1 - W1 - M2 - W2 - M3 <--(master) \ / / / x1 -- x2 -- x3 / / \ / / y1 -- y2 -- y3 -- y4 / \ / z1 - x2 - x3 - x4 - x5 - x6 

В этом примере, если у вас есть branch_x и branch_y с решениями, которые вы решили не хранить, а branch_z с решением, которое вы решили сохранить, вы могли бы сказать

 git checkout master git merge x git revert HEAD git branch -dx git merge y git revert HEAD git branch -dy git merge z git branch -dz 

Это сообщит git, что вы учли изменения во всех трех ветвях, но только хотите сохранить изменения с z . Это гарантирует, что коммиты остаются доступными, поэтому они не могут быть собраны в мусор и позволяют удалять ветки.

С другой стороны, на самом деле поиск старых коммитов, если вы не помечаете их, может быть затруднительным – и если вы собираетесь их пометить, чтобы впоследствии их можно было найти, тогда может не иметь смысла объединить их в ваш master где они могут загромождать историю.