Я новичок в мире управления исходным кодом / версиями и читал столько, сколько физически возможно, чтобы разобраться в различных методах, которые люди используют для своего собственного управления исходным кодом / версиями.
Одна вещь, которую я заметил, - это довольно отчетливое разделение методов разработчиков на две (возможно, больше?) Группы: одна группа предпочитает поддерживать свой ствол в всегда стабильном состоянии и выполняет все обслуживание и будущую разработку в ветвях, в то время как другие предпочитают делать всю свою разработку в стволе и держать его в не очень стабильном состоянии.
Мне любопытно, что предпочитает сообщество здесь, в StackOverflow, и есть ли у вас свои собственные методы.
Примечание: если это поможет адаптировать ответы, я должен отметить, что я - единственный разработчик (максимум два или три других в одном проекте), который работает в основном в ASP.NET и SQL Server 2005.
Мне нужен всегда стабильный багажник. У вас должна быть возможность в любой момент восстановить последнюю стабильную версию ...
В вашем случае я настоятельно рекомендую избегать большого количества ветвлений. Это действительно довольно сложный процесс, который не нужен для небольших проектов и небольших команд.
Всегда стабильно. Даже если я одинокий разработчик - особенно если я одинокий разработчик.
Для меня сломанное дерево означает меньше возможностей узнать, чем я занимаюсь, должен.
Большие изменения происходят в ветках, так же как и в стабильных выпусках, и вносят наименьшие единицы изменений, возможные в любой момент, чтобы продолжать двигаться вперед в хорошем темпе.
Все свои разработки я делаю в багажнике. Я разработчик-одиночка и не хочу иметь дело с ветвлением. Когда мой код стабилен, я просто помечаю текущую версию. Например, я бы пометил версию 1.0, 2.0 beta, 2.0-кандидат на выпуск 1, версию 2.0 и т. д. Ветвление, вероятно, было бы лучшей альтернативой, если вы поддерживаете старые версии для исправления ошибок и поддержки, но поскольку я этого не делаю, я не делаю этого. не волнуйся об этом.
Различия могут быть связаны с тем, насколько болезненным является слияние в данной системе управления версиями.
С git ветвление и слияние практически не требует усилий, поэтому для меня обычным делом является поддержание чистоты своего мастера и выполнение всей моей работы в ветвях. Ветвление и слияние в svn, особенно в предыдущих версиях, не так дешево и просто, поэтому, когда я использовал svn, я, как правило, работал непосредственно с стволом.
Я всегда использовал основной ствол в качестве заголовка кода. Обычно туда входит новый код разработки.
Мы делаем ответвления для выпусков, и мы можем переходить на «большой» дестабилизирующий эксперимент.
Когда мы исправляем ошибки, они сначала входят в основную версию, а затем при необходимости объединяются (переносятся обратно) в соответствующую ветку версии.
Если большой эксперимент удастся, его снова объединят с основным.
Мы используем теги для номеров сборки в ветках версий и main. Таким образом, мы можем вернуться к конкретной версии и выполнить сборку, если потребуется.
Старайтесь начинать с простого, я всегда стараюсь иметь известную рабочую сборку, которую можно воспроизвести для тестирования и развертывания и т. д. В зависимости от вашего репозитория вы можете использовать номер версии (SVN) или просто пометить известные рабочие версии, как они есть обязательный.
Если вы обнаружите, что несколько человек касаются одних и тех же файлов, вам нужно будет рассмотреть стратегию ветвления, кроме этой для такой небольшой команды разработчиков, это будет просто ненужными накладными расходами ... (IMO)
Это методология, которой мы следуем: Любой стабильный выпуск следует брать из транка. Любая дальнейшая работа или модификации должны выполняться внутри рабочей ветки и должны быть объединены с основной веткой по мере готовности к выпуску.
Если есть несколько независимых разработок, каждая группа должна иметь свою ветку, которую они должны периодически синхронизировать с trunc и объединять ее обратно в магистраль, когда она будет готова.
Как я уверен, вы заметили, поискав в Интернете ответы на эту тему, это одна из тех вещей, где лучший ответ - «Это зависит от обстоятельств», и, как указывалось в большинстве ответов, это компромисс. между тем, насколько легко вы хотите иметь возможность фиксировать / объединять новый код или управлять обширной историей версий, которую вы можете легко откатить для поддержки или отладки.
Я работаю в небольшой компании, а это означает, что в любой момент времени у нас может быть 3 или 4 разных версии кода на машинах разработчика, которые еще не добавлены в репозиторий. Мы используем TortoiseSVN для нашей системы управления версиями, которая дает нам возможность без особых трудностей выполнять ветвление / слияние, а также возможность просматривать журнал обновлений или довольно легко возвращать наши локальные копии к более ранней версии.
Основываясь на вашем вопросе, я полагаю, что мы попали бы в группу разработчиков, которые постоянно стараются поддерживать стабильную магистраль, и мы создаем новый код и тестируем его перед тем, как объединить его обратно в магистраль. Мы также стараемся сохранять «снимки» каждого выпуска версии, чтобы при необходимости мы могли легко проверить более раннюю версию и пересобрать ее, не добавляя никаких новых функций, предназначенных для будущего выпуска (это тоже отличный механизм для отслеживания ошибок, так как вы можете использовать более ранние версии кода, чтобы помочь определить, когда конкретная ошибка была впервые внесена в ваш код. Однако следует быть осторожным, если ваше приложение ссылается на общий код, который поддерживается отдельно от вашей версии -ed код, вам тоже нужно будет отслеживать его!).
В репозитории это выглядит примерно так:
Сундук
Выпуск v1.0.2.x
Выпуск v1.1.1.x
v1.2.1.x Разработка <- (Это будет объединено с Trunk и заменено папкой Release)
Когда я только начинал в компании, наша структура версий не была такой сложной, и по моему опыту я бы сказал, что если у вас есть какая-либо необходимость отслеживать более ранние версии, стоит приложить что-то вроде этого. вместе (как я сказал ранее, он не обязательно должен выглядеть именно так, если он соответствует вашим индивидуальным потребностям), хорошо документируйте его, чтобы все участники могли его поддерживать (альтернатива состоит в том, что создатель в конечном итоге «присматривает за детьми» "репо, которое быстро становится невероятной тратой времени), и поощряйте всех ваших разработчиков следовать ему. Вначале может показаться, что это требует больших усилий, но вы оцените это, когда впервые захотите воспользоваться этим.
Удачи!
Один из аспектов - как долго изменения будут находиться в нестабильном состоянии.
Когда внесенное мной изменение может повлиять на других людей или на ночную сборку, я делаю свою работу над веткой и сливаю, когда она стабильна.
Если внесенные мной изменения не повлияют на других людей (потому что это мой частный код дома, а не код на работе), тогда я в порядке с проверкой неработающих промежуточных состояний, если это то, что я хочу. Иногда я делаю несколько проверок подряд, которые нестабильны; для меня это нормально, когда это касается только меня, и рабочий процесс будет непрерывным. Если я вернусь через несколько лет (а не через несколько дней), и что-то не работает, это станет проблематичным (один недостаток того, что я работаю так долго, как я) - у меня есть некоторые проекты, которые все еще в разработке и обслуживании, которые достаточно стары, чтобы голосовать).
Я использую вариант тегов для достижения повторяемых сборок - поэтому, если мне нужно вернуться к стабильной версии для исправления ошибки, я могу использовать информацию тега для этого. Очень важно иметь возможность получить стабильную версию по запросу.