Подсказки для ручного слияния разнообразного кода

Question

Подсказки для ручного слияния разнообразного кода

module.exports
 Синтаксис взят из  Модули  (которые в основном используются в NodeJ - его аналогом является require, а не импорт). Если вы хотите использовать import, вам нужно использовать предложение export, которое из  модулей es6  
export default PageLoader
 вы также можете сделать именованным экспортом 
export { PageLoader };
, а затем 
import { PageLoader } from './pageLoader'; 
  Дополнительная литература

5

branching-and-merging branch merge svn

задан Vadim Kotov 11 August 2017 в 07:47

2 ответа

Другие вопросы по тегам:

branching-and-merging branch merge svn

Похожие вопросы:

score 4 · Answer 1

То, о чем Вы говорите, по существу пытается повторно основывать одно из ответвлений. Существует поддержка этого в некотором DVCSs, но я не знаю ни о какой поддержке такого рода вещи в SVN.

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

Как Вы избегаете этого в будущем? Частая интеграция.

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

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

score 0 · Answer 2

Возьмите единственный файл, скажите src1.c. Можно создать ромбовидную схему, описывающую слияние этот путь:

   Original src1.c
        /       \
       /         \
      /           \
   b1 src1.c     b2 src1.c
      \            /
       \          /
        \        /
         \      /
        merged src1.c

Где b1 означает первую версию ответвления, и b2 означает вторую версию ответвления. Можно выдержать сравнение, параллель diffs (скажите что та между объединенным источником и b2 версией, и b1 и оригиналом). Это может помочь.