Когда нужно создать новый репозиторий?

Question

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

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

Answer 1

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

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

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

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

Answer 2

Это интересная проблема. На мой взгляд, вы можете с комфортом хранить все свои алгоритмы сортировки в одном репо. Просто создайте отдельные подпапки для каждого алгоритма.

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

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

Answer 3

К Оставьте заявку: Это зависит от того, насколько велик ваш проект.

Гигантские проекты, такие как У Android есть свои хранилища для почти всего. Они также используют git submodule s, которые являются в основном репозиториями внутри хранилищ.

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

Так что в вашем случае - я думаю, -, один репозиторий

1. держит его так просто, как это возможно
2. достаточно полностью

Answer 4

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

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