2015-09-30 3 views
0

наши сборки занимают много времени. с модульными испытаниями около 4 часов. Я пытаюсь построить и запустить модульные тесты на master. В то же время, мне нужно объединить мастер филиал А.git: нужно построить на одной ветке и слить эту ветку на другую ветку

есть способ НЕ изменить то, что файлы выглядят как в файловой системе и слить в другую ветвь

---------\-----master 
      \----A 

что-то вроде " git merge from_branch to_branch "или" git merge to_Branch from_Branch "Я наблюдал за некоторыми сообщениями с alais, но они выглядят так, как будто они выполняют« git checkout A; git merge master », который я не хочу делать. Не могу сделать проверку, потому что у меня есть процессы, требующие доступ к файлам в мастер

благодаря

+0

Ну, после слияния файлов с мастером в A, нет? Что вы хотите быть в своем рабочем пространстве? Просто будьте логикой, вы не можете иметь (просто) содержимое мастера и (просто) содержимое другой ветки одновременно в любой директории. Если вам нужен чистый мастер и объединенный контент одновременно, вы можете захотеть клонировать содержимое репозитория в другое место, где вы объединяетесь и получаете доступ к первой рабочей области из других процессов. –

+0

Филиал А имеет изменения за пределами мастера. Что мне нужно, чтобы сохранить сборку в каталоге и в то же время появиться, что я сделал «git checkout A; git merge master»; проблема в том, что если я в 1 окне сделаю «git checkout master, mvn clean install», а в другом - «git checkout A; git merge master». если я нахожусь в середине сборки и проверки другого филиала, то сборка, как я понимаю, будет захватывать файлы из новой ветки, а не веткой, которую она запускала с –

ответ

1

Наших сборкам занимают много времени. с модульными испытаниями около 4 часов. Я пытаюсь создать и запустить модульные тесты для мастера. В то же время мне нужно объединить магистратуру в филиал A.

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

- B - C - D [master] 
      \ 
      E - F - G [feature] 

Использование git merge master держать функции филиала в курсе изменений в master (альтернативно git rebase master, чтобы избежать многих ненужных точек слияния). Функциональные ветви можно безопасно выталкивать, не подвергая опасности другие ветви.

Второй должен использовать continuous integration server. То есть, у вас есть выделенный компьютер, который ничего не делает, кроме создания и запуска полного набора тестов на все, что помещается в центральный репозиторий. Преимущество этого заключается в том, чтобы обеспечить окружающую среду как можно ближе к реальной производственной среде (что не происходит на вашей машине разработки). Travis CI - пример службы CI, Jenkins - сервер CI с открытым исходным кодом.

Обратите внимание, что вы можете запускать собственный CI-сервер на виртуальной машине на своем рабочем столе.

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


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

git clone /path/to/my/devel /path/to/my/tests 

Выполнить тесты в /path/to/my/tests и делать свою работу в области развития /path/to/my/devel.

+0

Мне нравится идея второго клона. не думал об этом. У нас есть постоянный сервер интеграции. проблема в том, что наша разработка env достаточно отличается от CI и других серверов. другие тесты модуля develoer проходят по моей системе, но не работают на CI. –

+0

@petercooke Я не могу вас сильно убедить, чтобы использовать ветви функций и сервер CI. Это избавит вас от многих будущих проблем. – Schwern

+0

мы используем ветви для каждого билета jira, затем объединяем ветки обратно в мастер –

2

Согласитесь с @Schwern, что самым простым решением для этой проблемы является наличие клона репозитория.

Иногда вместо полного клона вы можете найти copied workdir более удобным. В частности, вам не нужно тянуть/нажимать между этими двумя локальными репозиториями git.

Лучшим решением будет CI-сервер. Промежуточное решение на этом пути может делать такие сборки в докере, если вы можете использовать его и можете запускать тесты на linux.

Смежные вопросы