2013-05-04 2 views
1

Я разрабатываю приложение для Windows Phone, используя SDK версии 7.1 (для WP7) и размещая его в git repo. Чтобы сделать его доступным на устройствах с Windows Phone 8 с более высоким разрешением, я создал ветвь WP8, где я преобразовал проект Visual Studio и внес некоторые необходимые корректировки кода.«Многоканальная» разработка с использованием git

Теперь, когда я продолжаю развиваться на master, я хотел бы обновить функциональные изменения в ветке WP8. Моя первая мысль заключается в merge те ветви, но я боюсь, две возможные проблемы:

  1. При использовании merge, одна ветвь будет исчезать. (Не верно)
  2. Изменения, связанные с прошивкой (WP7 → WP8), могут быть переопределены.

Существует ли надлежащий способ разработки git для нескольких различных (но похожих) целевых SDK, которые зависят от большого количества идентичного кода?

+0

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

+0

О, я, должно быть, испортил это в моей голове ... –

ответ

1

При использовании слияния одна ветка исчезнет.

Нет, ни одна ветвь не исчезнет

изменения прошивки, связанные с (WP7WP8) может быть переопределен

Во-первых, попробуйте скорее rebaseWP8 на вершине master.
То есть, попробуйте применить WP8наверх из master (см. merge vs. rebase).
Как Gary Fixlercomments below, это имеет смысл для ветвей с короткой историей (в противном случае повторное применение очень старых коммитов на вершине недавней работы может быть проблематичным, и история не имеет смысла).


Я только воспитывать перебазироваться, потому что считается плохой практикой, чтобы объединить master в любой другой отрасли (это называется «back merge», и делает Adam Dymitruk сердит;)).

Вы должны использовать Feature branches, которые затем можно объединить в master, и в WP8 отрасли.
Это имеет преимущество легкости ветвления предлагаемого мерзавцем, и оставить master только стабильным состояние кода: дальнейшее развитие в master должно быть сделано в полнометражной ветви (и затем объединить кmaster), вместо того, делается в master (что приводит к «обратному слиянию» от master к другому ответвлению, что является плохой практикой)

Подробнее о статье Адама «Branch Per Feature».


Что касается файлов конфигурации, вы можете также сохранять значения в разделяет файлы и использовать файл шаблона для создания нужного файла конфигурации с нужными значениями, в зависимости от отрасли вы.
См. "What's the easiest way to deal with project configuration files?".

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

+0

Не переустанавливал бы переписывать вещи точно так же, как слияние? Я думал, что разница заключается в том, что rebase копирует отдельную ветку, чтобы совершать мастер, а merge создает одно коммит, содержащее все изменения из ветки. – Andomar

+0

@Andomar Лучше использовать повторную работу над созданием мастера вместо слияния (http://stackoverflow.com/questions/804115/git-rebase-vs-git-merge/804178#804178). Вот почему я предлагаю драйвер фильтра содержимого для файлов конфигурации (см. Мой отредактированный ответ). – VonC

+0

@Andomar - Нет, rebase ничего не перезаписывает. Он повторяет фиксацию изменений в новом месте, по существу отключая ветвь и снова подключая ее в другом месте. Проблема следить за этим заключается в том, что вы в конечном итоге разрушаете контекст в своей истории. Вы сообщаете об общем создании A, переформатируете WP7 сверху, рефакторинг, общий для создания B, переформатируйте WP7 сверху - теперь коммит, который был общим, не имеет смысла поверх рефакторинга B. У меня есть 500+ коммитов в репо с этой проблемой. Я усвоил это с трудом. –

0

Изменения, связанные с прошивкой (WP7 → WP8), могут быть переопределены.

Филиалы предназначены для версий одного и того же устройства на разных этапах разработки. Если вы объедините ветку, git попытается переместить все изменения с одного на другой. Нет простого способа перемещения только независимых от архитектуры изменений из одной ветки в другую.

Лучшая ситуация, когда вы можете получить одну ветку для сборки для обоих. Поделитесь файлами, которые можно использовать совместно, и сохраните конкретные вещи проекта в отдельных каталогах, например arch/wp7 и arch/wp8.

+0

Ну, проблема здесь в том, что не так просто отличить разделяемые от не разделяемых частей, так как они могут быть даже в одних и тех же файлах. Например, я мог бы изменить страницу XAML (дизайн пользовательского интерфейса) для более высоких разрешений в 'WP8', но в' master' я добавил новые функции. –

1

Вы можете уйти от этого с помощью ветвей или папок, но это главный кандидат ИМО для подмодулей. Я использую их для таких вещей. Вот примерный набор из 3 РЕПО:

common/ (bare repo of common files) 
    .git/ 

wp7/ (regular repo of wp7 specifics) 
    .git/ 
    common/ (submodule) 

wp8/ (same as wp7, but for wp8) 
    .git/ 
    common/ (submodule) 

Чтобы сделать общую, который вы бы просто взять регулярный репо и git clone --bare repo optional_bare_repo_name. Если вы не укажете его имя, оно будет клонировать common в папку с именем common.git, которая является пустой версией. Теперь вы можете либо в wp repo сделать git subdmodule add path/to/common optional_folder_name (он использует имя папки репо, если вы не укажете его). Это эффективно клонирует общее репо в папку внутри каждого репозитория wp. Они также могут быть ветвями одного репо; вы просто добавите подмодуль в каждую ветвь.

Подмодули немного больше обслуживания, чем ветви, но они что-то не делают. Они дают вам параллельную линию развития внутри вашего репо. Когда вы делаете изменения в общем репо внутри либо репликации wp, вы совершаете его там, и вы можете вернуть его обратно к внешней, пустой версии обычного, и вытащить его в другом репо второго репо. Это просто регулярное репо, но его клоны живут внутри репозиториев wp. В ваших репозиториях wp вы скажете, какую версию вы хотите прямо сейчас, сначала проверив правильную фиксацию внутри общего репо, затем снаружи в репозитории wp, выполнив git add common и git commit -m'Update common for feature X'. Это создает фиксацию в репозитории wp, которая просто сохраняет хэш коммита в общем подмодуле.

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

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

+0

Выглядит более чистым, чем перезарядка, но может быть излишним для моего проекта ~ 50 классов. Изменения для WP8 довольно малы, но разбросаны по всему моему проекту ... Кроме того, я немного боюсь изменить всю настройку проекта. –

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