Подрывная деятельность - кто-либо должен разрабатывать от соединительной линии?

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

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

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

Конечно, иногда большая функция должна быть поставлена ​​отдельно, но в них случаях может быть сделано специально утвержденное исключение.

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

Однако наша система всегда строится и часто также использует CI. Каждый разработчик должен знать о цикле обновления / перестройки / повторного тестирования / фиксации (не то, чтобы он надежный, но он работает достаточно хорошо).

Хм, это больно, когда я думаю о том, сколько из наших программных практик работают «достаточно хорошо» .

Я думаю, это действительно зависит от масштаба вашей операции. Может быть, до 5-10 разработчиков, каждый из которых выполняет транк, действительно должен быть в порядке. Но, конечно, каждый должен иметь в виду, что магистраль всегда должна быть компилируемой. Если они работают над серьезными изменениями, которые некоторое время не будут компилироваться, им следует перейти в ветку.

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

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

Работа в ветвях и сохранение основной магистрали (мониторинг с помощью системы непрерывной интеграции) тоже нормально, но может привести к конфликтам с разработчиками в нескольких ветвях, вносящих изменения.

Взгляните также на следующий сайт:

http: //www.cmcrossroads. com / bradapp / acme / branching /

Здесь обсуждается ряд шаблонов ветвления для параллельной разработки, включая:

• S1. Основная линия
• S2. Параллельное сопровождение / разработка
• S3. Перекрывающиеся выпуски
• S4. Линия стыковки
• S5. Линии поэтапной интеграции
• S6. Изменить очереди распространения
• S7. Кодовая строка сторонних производителей
• S8. Внутренние / внешние линии

Зависит от масштабов изменений. Хорошей практикой является то, что ствол всегда должен быть компилируемым, но это не обязательно означает, что разработчики не могут работать над стволом для небольших изменений / исправлений - в конце концов, это одна из причин наличия рабочей копии; вы можете убедиться, что что-то компилируется , прежде чем зафиксирует это.

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

При использовании Subversion, как правило, каждый работает из основной ветки. Если конкретный разработчик работает над большой или «экспериментальной» функцией, может быть целесообразно создать отдельную ветвь для этой работы, которую можно будет позже объединить обратно в основную часть.

Хотя метод, который вы описываете, с каждый разработчик, имеющий свою ветку, ближе к Git , чем к Subversion. Если вы предпочитаете работать таким образом, я настоятельно рекомендую вместо этого использовать Git.

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

Да.
нет никакого смысла делать вашу последнюю ветку самым последним выпуском. Затем ваш ствол устареет по сравнению с вашими филиалами.

Через две недели после безумная погоня за гусем, мне не удалось найти какую-либо комбинацию изменений кода, которая позволила бы этот метод потоковой передачи документов PDF, Excel или Word, когда включена опция « Не сохранять зашифрованные страницы на диск »

Microsoft заявила, что такое поведение является преднамеренным, в ряде статей базы знаний и частных электронных письмах. Похоже, что когда включена опция « Не сохранять зашифрованные страницы на диск », IE ведет себя правильно и выполняет то, что ему велят делать. Этот пост - лучший ресурс, который я нашел до сих пор, в котором объясняется, почему этот параметр будет включен, а также плюсы и минусы его включения:

« Не сохранять зашифрованные страницы на диск. 'вступает в силу при работе с соединениями SSL (HTTPS). Подобно тому, как веб-сервер может отправлять готовую информацию о том, как кэшировать файл, можно настроить Internet Explorer так, чтобы он не сохранял файлы в кеш во время соединения SSL (HTTPS), независимо от того, сообщает ли вам веб-сервер.

Что такое Плюс для включения этой функции, безопасность - это причина номер один, почему эта функция включена. Страницы не хранятся в кэше временных файлов Интернета.

В чем заключается обратная сторона? Низкая производительность, поскольку в кеш ничего не сохраняется, даже если 1-байтовое изображение в формате gif, которое десятки раз использовалось на странице, необходимо каждый раз загружать с веб-сервера. Что еще хуже, некоторые действия пользователя могут потерпеть неудачу, например, загруженные файлы будут удалены, а при открытии документов PDF не будет названо несколько сценариев »

. клиенты и пользователи, у которых существуют альтернативы использованию этого параметра:

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

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

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

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

Как Нил Баттерворт сказал , это зависит; существует несколько подходящих способов.

Однако лично я бы порекомендовал иметь стабильную магистраль и делать все основные разработки на временных ветках. (То есть, только небольшие независимые изменения, которые будут полностью сделаны с помощью одного коммита, должны идти непосредственно в ствол.) Чтобы долгоживущие ветки не уходили слишком далеко от основной ветки, (автоматически) объединяйте все, что идет в транк во все ветви разработки, по крайней мере, ежедневно. Да, и все должно контролироваться CI - не только магистраль, но и все ветки разработки. Особенно с Хадсоном это несложно и вызывает очень мало накладных расходов.

Если вам интересно, как мы это применили, в этом ответе есть более подробные сведения. (Я бы не хотел слишком много повторяться. ..:)

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

У меня есть разработчики, которые создают ветки проекта или изменяют ветки запросов / ошибок за пределами ствола, а затем объединяются обратно, так что в некотором смысле да, у меня есть разработчики, работающие вне ствола, но что входит в «объединение» ветвей контролируется с помощью некоторого инструмента или процесса управления сборкой.

Я думаю, что это довольно хорошо освещено в этом вопросе

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

После того, как бета-версия была в порядке, мы выпускаем версию в продукт.

Сегодня я работаю над версией 3.0 нашего продукта и фиксирую изменения моего кода в стволе. Релиз еще впереди.

Сотрудник экспериментирует с некоторыми функциями, которые могли бы войти в 4.0, но определенно не в 3.0. Она откладывает свои вещи в отдельную ветку. Было бы неправильно записывать такие вещи в ствол.

Другой сотрудник исправляет ошибки в версии 2.5, которую мы уже отправили клиенту. Он проверяет их в ветке 2.5 по очевидным причинам.

Итак, чтобы ответить на вопрос заголовка (Если все будут развиваться вне магистрали, мой ответ - нет. HTH

PS насчет слияния. Мы могли бы выборочно объединить некоторые вещи от ветви 2,5 к стволу позже, но не от ствола обратно к ответвлению.