Вы управляете версией невидимых приложений или всего проекта или обоих?

Ответ 1

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

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

YAGNI это не просто код.

Ответ 2

Мне нравится Tom's или ответы Алекса, за исключением того, что им не хватает реального обоснования за ними
( "проще иметь один репозиторий для команды разработчиков"?
"значительное количество людей может быть заинтересовано в выводе (или просмотре изменений) отдельных приложений"
почему?)

Прежде всего, один или несколько репозиториев - это решение на стороне сервера (с точки зрения ресурсов сервера).
SVN легко настраивает несколько репозиториев за одним сервером, тогда как ClearCase будет иметь свой собственный "vob_server" процесс на VOB, что означает: вы не хотите более ста VOB на (Unix) сервер (или более 20-30 на Сервер Windows).
Git в частности: установка репозитория дешева, доступ к нему может быть простым (через простой общий путь) или может включать процесс (демон git). Последнее решение означает: "не к большому количеству репозиториев, доступных непосредственно извне". (к ним можно обращаться косвенно через подмодули, на которые ссылается суперпроект)

Тогда существует клиентское администрирование: насколько сложна конфигурация рабочего пространства, когда задействован один или несколько репозиториев. Как клиент может ссылаться на правильную конфигурацию? (список меток, необходимых для ссылки на правильные файлы).
SVN будет использовать внешние, git "подмодули", и в обоих случаях это добавляет сложности.
Вот почему ответ Tom может быть правильным.

Наконец, существует аспект управления конфигурацией (ссылка на ответ Alex). Можете ли вы пометить часть репо? Если вы можете (например, в SVN, где вы фактически делаете SVN-копию части репо), это означает, что вы можете иметь компонентный подход, где несколько групп файлов имеют свой собственный жизненный цикл и их собственные теги (установленные в их собственном индивидуальном темпе).
Но в Git это невозможно: тег ссылается на фиксацию, которая всегда относится ко всему репозиторию.
Это означает "системный" подход, где вы все равно хотите всего проекта (в отличие от "просмотра отдельных приложений - я никогда не видел его в реальной жизни" ) от Ответить Alex). Если это так (если вы все равно хотите всю систему), это не важно.

Но для тех из нас, кто думает в терминах "независимых групп файлов", это означает, что репозиторий git фактически представляет собой отдельную группу файлов (с собственным ритмом в терминах эволюции и пометки), с потенциально суперпроект, ссылающийся на эти репозитории как подмодули.
Это не ваша повседневная настройка, поэтому для независимых проектов я бы рекомендовал только несколько или один репозиторий git.
Но для более сложного взаимозависимого набора проектов... вам нужно понять, что по сути git был задуман, "репозиторий" представляет собой согласованный набор файлов, которые должны развиваться в том же темпе, что и все. И не "все" может всегда вписываться в один набор файлов (если "все" достаточно сложно). Следовательно, в этом случае потребуется несколько репозиториев.
И сложный набор взаимозависимых проектов действительно происходит и в реальной жизни;)

Ответ 3

Я не эксперт git, но я не считаю, что соответствующая стратегия будет отличаться от одной для hg или даже в этом случае svn, поэтому я собираюсь дать свои 2 цента ' в любом случае, -).

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

Ответ 4

Практически всегда проще иметь один репозиторий для каждой команды разработчиков, независимо от того, сколько у вас продуктов. В конце концов вам захочется поделиться кодом между проектами (даже несколькими отдельными сайтами DJango!), И это намного проще сделать только с одним репозиторием.

Во что бы то ни стало, создайте красивую структуру папок WITHIN в этом репозитории. Тем не менее, одна проверка из git (возможно, из подпапки) должна предоставить вам все файлы, необходимые для вашего тестового сайта (python, templates, css, jpegs...), а затем вы просто скопируете httpd.conf и так для завершения установки.

Ответ 5

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

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

Ответ 6

Если у вас есть многоразовые приложения, поместите их в отдельное репо.

Если вас беспокоит количество частных репозиториев, посмотрите на bitbucket (если вы решили сделать их с открытым исходным кодом, я совет github)

В проект можно включить собственные приложения, даже используя теги версии:

Недавно я узнал, как сделать это с помощью buildout и git tags (Я использовал svn: externals, чтобы включить приложение, но недавно переключился с svn на git).

Сначала я попробовал mr.developer, но пока это не получилось, я нашел альтернативу для mr.developer:

Я обнаружил, что gp.vcsdevlop очень прост в использовании для этой цели.

см. https://pypi.python.org/pypi/gp.vcsdevelop

Я закончил, положив это в свой файл buildout и сразу же запустил его (мне пришлось добавить в приложение app pip.txt, чтобы он работал, но это все-таки хорошо):

vcs-update = True
extensions =
    gp.vcsdevelop
    buildout-versions
develop-dir=./local_checkouts

[email protected]:<my bitbucket username>/<the  app I want to include>[email protected]#egg=<the appname in django>

develop = .

в этом случае он вытаскивает мое приложение и клонирует его к тегу версии 0.1.38 в проект в subdit./local_checkouts/ и развивает его при запуске bin/buildout

Изменить: примечание 26 августа 2013

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

вы получите это предупреждение при попытке выполнить обычную команду "git push origin master":

To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.

EDIT 28 августа 2013

О работе в local_checkouts для общих приложений, включенных в gp.vcsdevelop:

(и обработать предупреждение, описанное выше в remakr)

git push origin + master, похоже, испортил историю фиксации для общего кода

Таким образом, способ работы в каталоге local_checkout выглядит следующим образом:

войдите в местную проверку (после бункера/сборки, чтобы проверка была ведущей):

cd localcheckouts/<shared appname>

Создайте новую ветку и перейдите к ней следующим образом:

используйте git checkout -b 'issue_nr1' (например, имя ветки указано здесь после проблемы, с которой вы работаете)

и после того, как вы закончите работу в этой ветки, используйте: (после обычных git add и git commit)

git push origin issue_nr1

при проверке и завершении слияния ветки назад в ведущем устройстве:

сначала проверьте мастер:

git checkout master

update (возможно, только нужно, когда другие коммиты в среднем)

git pull

и слияние с мастером (где вы сейчас находитесь):

git merge issue_nr1

и окончательно нажмите это слияние:

git push origin master

(с особой благодарностью этому упрощенному руководству по git: http://rogerdudler.github.io/git-guide/) и через некоторое время, чтобы очистить ветки, вы можете удалить эту ветку

git branch -d issue_nr1