Вы продолжаете разработку в ответвлении или в соединительной линии? [закрытый]

Question

Вы продолжаете разработку в ответвлении или в соединительной линии? [закрытый]

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

public class Test { 
    public static void main(String[] args) {
        int list[] = {1, 2, 3, 4, 5, 6};

        for (int i = 1; i < list.length; i++) {
          System.out.println("\n\n\nloop number " + i);
          System.out.println("\ni = " + i);
          System.out.println("\nThe value at list[i] = " + list[i]);
          System.out.println("\ni - 1 = " + (i - 1));
          System.out.println("\nSo I'm accessing element " + (i - 1) +
            " in the list for this iteration.");
          System.out.println("\nThe value at list[i - 1] = " + list[i - 1]);
          System.out.println("\nEnd of loop " + i);
          list[i] = list[i - 1];
        }

        for (int i = 0; i < list.length; i++)
          System.out.print(list[i] + " ");
    }
}

Обычно я не использовал бы это для простого цикла, но Я хотел показать вам различные способы доступа к значениям при запуске цикла.

. Вы получите что-то вроде этого для каждой итерации цикла в консоли, он проведет вас через то, что значения:

loop number 1

i = 1

Значение в списке [i] = 2

i - 1 = 0

Итак, я обращаюсь к элементу 0 в списке для этой итерации.

Значение в списке [i-1] = 1

Конец цикла 1

171

version-control

задан tshepang 10 April 2014 в 03:24

23 ответа

Метод, который мы используем, По необходимости подход, который обсужден подробно в замечательной книге Laura Wingerd:

http://oreilly.com/catalog/9780596101855/index.html

, В то время как книга по необходимости центральна (Wingerd По необходимости менеджер по продукции), понятия могут быть применены к любому VCS.

по необходимости подход (и платформа) обслуживал нас очень хорошо. Это используется в большом количестве фирм (Google, Intuit, и, я услышал, сама Microsoft Windows).

книга определенно стоит чтения.

0

ответ дан 23 November 2019 в 20:43

Для меня это зависит от программного обеспечения, которое я использую.

Под CVS, я просто работал бы в "соединительной линии" и никогда не отмечал бы/переходил бы, потому что это было действительно болезненно, чтобы сделать иначе.

В SVN, я сделал бы свой "новейший" материал в соединительной линии, но когда пришло время сделать, нажатие сервера отмечено соответственно.

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

1

ответ дан cpm 23 November 2019 в 20:43

Соединительная линия должна обычно быть Вашим основным источником разработки. Иначе Вы проведете много времени, объединяясь в новых возможностях. Я видел сделанный другой путь, и это обычно приводит к большому количеству последних головных болей интеграции.

Мы маркируем наши выпуски, таким образом, мы можем быстро ответить на производственные чрезвычайные ситуации без distribing активной разработки.

1

ответ дан Jim 23 November 2019 в 20:43

Соединительная линия обычно является основной строкой разработки.

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

1

ответ дан 17 of 26 23 November 2019 в 20:43

Мы следуем за trunk=current потоком разработки, branch=release (s) подход. На выпуске клиенту мы переходим соединительная линия и просто сохраняем соединительную линию продвигающейся вперед. Необходимо будет принять решение на том, сколько выпусков Вы готовы поддерживать. Чем больше Вы поддерживаете, тем больше слияния Вы будете делать на исправлениях ошибок. Мы пытаемся сохранить наших клиентов на не больше, чем 2 выпусках позади соединительной линии. (Например, Dev = 1.3, поддерживаемые версии 1.2 и 1.1).

2

ответ дан Lou 23 November 2019 в 20:43

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

Предыдущие производственные сборки перемещены в то время в old_production_, и текущий выпуск напоминания является всегда просто производством. Весь наш сервер сборки знает о производстве, то, как развернуть производственное ответвление, и мы сбрасываем ту сборку с ноги с триггером силы.

2

ответ дан DevelopingChris 23 November 2019 в 20:43

Мы используем соединительную линию для основной разработки и ответвления для работ по техническому обслуживанию выпусков. Это работает хорошее. Но тогда ответвления должны только использоваться для исправлений ошибок, никаких существенных изменений, особенно на стороне базы данных, у нас есть правило, что только изменение схемы может произойти на основной соединительной линии и никогда в ответвлении.

4

ответ дан adriaanp 23 November 2019 в 20:43

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

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

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

необходимо будет экспериментировать, если Вы имеете большую группу разработчиков и получаете ощущение какой работы в Вашей ситуации. Вот страница от Microsoft, которая может быть несколько полезной: http://msdn.microsoft.com/en-us/library/aa730834 (По сравнению с 80) .aspx

4

ответ дан Harpreet 23 November 2019 в 20:43

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

ответвление необслуживания А должно быть создано только, когда существует вероятность (или уверенность) коллизий среди кода, который был бы трудным управлять любым другим путем. Если ответвление не решит логистическую проблему, оно создаст тот.

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

4

ответ дан Chuck 23 November 2019 в 20:43

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

существует стоимость интеграции для слияния и ловли до новых возможностей, прокрученных в соединительную линию, но Вы собираетесь страдать от этой боли так или иначе. Наличие всех разрабатывает на соединительной линии, вместе может привести к ситуации с Диким Западом, в то время как ветвление позволяет Вам масштабировать и выбирать точки, в которых требуется принять горькие таблетки интеграции. Мы в настоящее время масштабируемся более чем ста разработчикам на дюжине проектов, каждом с несколькими выпусками с помощью тех же базовых компонентов, и это работает вполне прилично.

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

5

ответ дан Josh Segall 23 November 2019 в 20:43

Мы разрабатываем на соединительной линии, если изменения не являются слишком главными, дестабилизация, или мы приближаемся к главной версии одного из наших продуктов, в этом случае мы создаем временное ответвление. Мы также создаем постоянное ответвление для каждого выпуска отдельного продукта. Я нашел документ Microsoft о Переходящее Руководство довольно полезный. Eric Sink учебное руководство при ветвлении также интересно, и указывает на это, какие работы для Microsoft могут быть слишком тяжелыми для части остальной части нас. Это было в нашем случае, мы на самом деле используем подход, Eric говорит, что его команда делает.

8

ответ дан Brian Stewart 23 November 2019 в 20:43

Я думаю, что Ваш второй подход (например, отмечая выпуски и делая экспериментальный материал в ответвлениях, считая соединительную линию стабильной) является лучшим подходом.

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

Ответвления, как предполагается, являются реальными полями песка, хотя соединительная линия должна будет играть эту роль также: теги укажут, является ли код "золотым" в то время, подходит для выпуска.

10

ответ дан Jon Limjap 23 November 2019 в 20:43

Хорошей ссылкой на процессе разработки, который сохраняет стабильность соединительной линии и действительно все работает в ответвлениях, является Divmod Окончательная Качественная Система Разработки . Быстрая сводка:

Всей сделанной работе нужно было связать билет с ним
А, новое ответвление создается для каждого билета, где работа для того билета сделана
, Изменения от того ответвления не объединяются назад в соединительную линию магистрали, не будучи рассмотренным другим участником проекта

, Они используют SVN для этого, но это могло легко быть сделано с любой из распределенных систем управления версиями.

11

ответ дан Travis 23 November 2019 в 20:43

Оба.

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

Выпуски сохраняются в их собственном каталоге, только с исправлениями ошибок, сделанными на них (и затем объединяются в соединительную линию).

Любая новая возможность, которая собирается оставить соединительную линию в нестабильном или нерабочем состоянии, сделана в своем собственном отдельном ответвлении и затем объединена в соединительную линию на завершении.

19

ответ дан Wolf 23 November 2019 в 20:43

Я склонен проявлять "подход" ответвления выпуска. Соединительная линия энергозависима. Однажды выпускают подходы времени, я заставил бы выпуск перейти, который я буду рассматривать более осторожно. Когда это наконец сделано, я маркировал бы/отметил бы состояние репозитория, таким образом, я буду знать, что "чиновник" выпустил версию.

я понимаю, что существуют другие способы сделать это - это - просто способ, которым я сделал его в прошлом.

36

ответ дан Matt Dillard 23 November 2019 в 20:43

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

Те люди выше, кто возражает высказыванию, что Вы будете иметь:

проблемы сборки Constant для ежедневных сборок

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

, вероятно, не использовала непрерывные методы интеграции.

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

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

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

Имеют чтение статьи Martin Fowler на Непрерывная Интеграция . Мы прокрутили наше собственное такая система для главного проекта (3,000kSLOC) приблизительно в 2 000 строк Posix sh.

66

ответ дан Tim Cooper 23 November 2019 в 20:43

@Brian R. Bondy: Обратите внимание на то, что это не решение, как только Ваша команда достигает определенного количества людей/задач, обработанных параллельно на проекте.

, Как только отдел QA вовлечен в обеспечение качества, усилия должны были обеспечить, одна установка на происходящее ответвление просто слишком высоки. Думайте SOA/клиенты/серверы/веб-сервисы/базы данных , все из которых должны быть обеспечены на ответвление .

Это решение испытывает недостаток также в этапе интеграции.

-1

ответ дан pointernil 23 November 2019 в 20:43

Read this: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

0

ответ дан zvolkov 23 November 2019 в 20:43

ИМХО, нет универсального ответа на вопрос о соглашении о подрывной деятельности.

Это действительно зависит от динамики проекта и компании, использующей его. В очень быстро меняющейся среде, когда выпуск может происходить так часто, как раз в несколько дней, если вы попытаетесь неукоснительно помечать теги и ветвиться, вы получите неуправляемый репозиторий. В такой среде подход «ветвление по мере необходимости» мог бы создать гораздо более удобную в обслуживании среду.

Кроме того, по моему опыту, с чисто административной точки зрения очень легко переключаться между методологиями svn, когда вы захотите.

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

0

ответ дан 23 November 2019 в 20:43

Это действительно зависит от того, насколько хорошо ваша организация/команда управляет версиями и какой SCM вы используете.

Если то, что будет следующим (в следующем релизе), можно легко спланировать, вам лучше разрабатывать в стволе. Управление ветками требует больше времени и ресурсов. Но если следующее нельзя легко спланировать (что постоянно происходит в больших организациях), вы, вероятно, в конечном итоге будете выбирать коммиты (сотни/тысячи), а не ветки (несколько или десятки).
С Git или Mercurial управлять ветками намного проще, чем с cvs и subversion. Я бы выбрал методику стабильного ствола / тематических ветвей. Это то, что использует команда git.git. read:http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
В Subversion я сначала применил методику develop-in-the-trunk. Было довольно много работы, когда дело доходило до даты релиза, потому что каждый раз мне приходилось выбирать коммиты (моя компания не умеет планировать). Теперь я вроде как эксперт в Subversion и хорошо знаю, как управлять ветками в Subversion, поэтому я перехожу к методологии стабильного ствола / тематических веток. Это работает гораздо лучше, чем раньше. Сейчас я пробую, как работает команда git.git, хотя мы, вероятно, будем придерживаться Subversion.

1

ответ дан 23 November 2019 в 20:43

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

Мне она нравится, потому что:

Это просто: вы можете получить ее по картинке.
Он работает (и масштабируется) хорошо, без особых проблем слияния и конфликтов.
Вы можете выпустить «рабочее программное обеспечение» в любое время (в духе Agile).

И на всякий случай, если это было недостаточно явно: разработка ведется в «рабочих ветвях», магистраль используется для DONE (готового к выпуску) кода. См. Все подробности в Контроль версий для нескольких Agile-команд .

14

ответ дан 23 November 2019 в 20:43

Вот дизайн SVN, который я предпочитаю:

root
- разработка
  - ветви
    - feature1
    - feature2
    - ...
  - trunk
- beta {{1} }
  - теги
  - ствол
- выпуск
  - теги
  - ствол

Вся работа выполняется из разработки / ствола, за исключением основных функций, требующих его собственный филиал. После проверки работы с разработкой / основной веткой мы объединяем протестированные проблемы в бета-версию / магистраль. При необходимости код тестируется на бета-сервере. Когда мы готовы развернуть некоторые изменения, мы просто объединяем соответствующие ревизии в выпуск / магистраль и развертываем.

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

Эта конструкция обеспечивает большую гибкость. Это также позволяет нам легко оставлять ревизии в бета-версии / стволе при объединении других в выпуск / ствол, если некоторые ревизии не прошли тестирование в бета-версии.

1

ответ дан 23 November 2019 в 20:43

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

version-control

Вы продолжаете разработку в ответвлении или в соединительной линии? [закрытый]

23 ответа

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