Я перехожу к Git из SVN. В SVN у меня было несколько проектов eclipse в одном репозитории SVN, который удобен для просмотра проектов. Я собирался перейти к созданию одного репозитория Git для проекта eclipse, но EGit предлагает сделать иначе.
Руководство для EGit предлагает поместить несколько проектов в один репозиторий Git.
Рассматривая аналогичные вопросы такие как это, предлагайте один проект в репозитории.
Какой подход - лучшая практика и что люди реализуют?
Это зависит от того, насколько тесно связаны эти проекты. Задайте себе следующие вопросы:
Если вы поместите их все в один, некоторые вещи сверху будут проще. Вам нужно будет только развернуть /tag/stash/commit в одном репозитории, а не делать это для каждого репозитория отдельно.
Но если вам нужно иметь, например, отдельные циклы выпуска для проектов, тогда необходимо, чтобы каждый проект был создан в независимом репозитории.
Обратите внимание, что вы всегда можете разделить репозиторий позже или объединить несколько репозиториев в один, не теряя истории.
Комбинация немного сложнее, чем разбиение, поэтому я сначала поеду в один репозиторий и посмотрю, как это происходит.
Я использую 1 репо за проект.
Некоторые рассуждения:
Когда вы обнаруживаете, что вы перепутали что-то после нескольких коммитов, гораздо проще исправить, когда это только один проект. Просто подумайте, вы выполнили два других проекта, и теперь вам нужно исправить фиксацию, которую вы сделали в третьем проекте.
Как сказал Федор, ваша история и журнал намного чище. Он показывает только коммиты для этого проекта.
Он работает лучше с рабочим процессом разработки, который у меня есть. У меня есть ведущее подразделение для производства, разработка ветки для, ну, разработка, и я создаю ветки для реализации функций (здесь вы можете прочитать подробнее: http://blog.avirtualhome.com/development-workflow-using-git/)
Когда вы работаете в команде и "делитесь" с репо git, членам команды действительно нужны все остальные проекты?
Просто несколько мыслей, но что это сводится к: Делайте то, что работает для вас.
У меня есть несколько проектов (проекты Eclipse) и пробовали разные вещи, чтобы узнать, что лучше всего работает с точки зрения реальной ежедневной разработки. Вот что я нашел, и я думаю, что большинство людей найдет то же самое, если они будут отслеживать результаты и объективно анализировать результаты.
Короче говоря, следующие правила дадут наилучшие результаты:
Следующие рекомендации объясняют этот процесс для определения того, какие проекты следует размещать в одном репозитории более подробно:
Если проект не тесно связан с каким-либо другим проектом (например, проект может быть открыт без открытия других проектов, а другие проекты не будут использоваться при открытии проекта при их открытии), то вы должны определенно поместите его в свой собственный репозиторий по причинам, указанным в ответах выше этого.
Если проект зависит от других проектов или других проектов, зависит от проекта, тогда он сводится к тому, насколько они связаны друг с другом, насколько хорошо они могут быть упакованы вместе и как легко они могут быть отделены от друг друга.
A) Например, проект тестирования, содержащий классы тестов junit для тестирования классов основного проекта, представляет собой случай, когда два проекта очень связаны друг с другом, могут быть легко упакованы вместе и не могут быть легко отделены друг от друга, Эти проекты должны быть помещены в один и тот же репозиторий по причинам, описанным ниже в части C.
B) В случае, когда один проект полагается на другой проект, чтобы обеспечить какие-то общие ресурсы, действительно сводится к тому, насколько хорошо они могут управляться вместе и насколько легко они могут быть отделены друг от друга. Например, если проект с общими ресурсами опирается на многие проекты, его следует поместить в свой собственный репозиторий, потому что на другие несвязанные проекты влияют изменения в проекте совместного исходного кода. В подобном случае проект общих ресурсов должен быть отделен от зависимых проектов, а не напрямую связан с зависимыми проектами. (Например, было бы лучше создать файлы архивов с версией [Jar файлы с таким именем, как "projectName".1.0.1.0.jar, например] и включить копию этих в каждый проект вместо совместного использования ресурсов путем связывания проектов вместе.)
C) Если несколько проектов связаны, их можно легко вводить вместе, но их нельзя легко отделить друг от друга, тогда это зависит от того, насколько они тесно связаны друг с другом.
I) Если проекты помещаются в один репозиторий, тогда проекты будут храниться в синхронизации друг с другом в репозитории каждый раз, когда есть фиксация, которая может быть реальной спасательной программой, если проекты тесно связаны. Однако это также создает проблемы, отмеченные в ответах выше этого.
II) Если проекты помещаются в отдельные репозитории, вам придется позаботиться о том, чтобы они синхронизировались друг с другом и не забудьте включить какой-то механизм для указания того, какие коммиты принадлежат одной и той же точке синхронизации (возможно, что-то вроде включения одного и того же номера точки синхронизации в комментарии для фиксации каждого проекта, когда группа транзакций выполняется по проектам.)
III). Таким образом, в таких случаях почти всегда лучше объединить эти проекты в единый репозиторий, чтобы уменьшить накладные расходы человеческих усилий на синхронизацию коммитов и избежать человеческой ошибки, если коммиты должны быть отменены. Единственный раз, когда было бы лучше разместить их в отдельных хранилищах, это когда только один из проектов меняется регулярно, а другие связанные проекты редко меняются.
Я думаю, что этот вопрос связан с тем, на который я ответил здесь. в основном Git по своей природе поддерживает очень тонкую гранулированную структуру, когда речь идет о проектах/хранилищах. Я читал и преподавал, что 1 репозиторий для каждого проекта - почти всегда лучшая практика. Вы почти ничего не теряете, сохраняя отдельные проекты и выигрывая, как описывали другие.
Возможно, с ней будет работать более эффективно, если вы создадите несколько репозиториев git.
Если вы создадите ветку, только файлы проекта будут разветвлены, а не все проекты. Малый проект будет быстрее анализировать, совершать. Операции занимают меньше времени.
Журнал также будет более понятным. Вы можете сделать более гранулированную конфигурацию, если у вас будет несколько репозиториев git.