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