Вы управляете версией отдельных приложений или всего проекта или обоих?
Итак, у меня есть проект Django. Мне было интересно, должен ли я поместить каждое приложение в свой собственный репозиторий git, или лучше просто поместить весь проект в репозиторий git, или мне нужно иметь репозиторий git для каждого приложения, а также репозиторий git для проект?
Благодарю.
6 ответов
Это действительно зависит от того, будут ли эти повторно используемые приложения фактически использоваться за пределами проекта или нет?
Единственная причина, по которой он может вам понадобиться в другом репо, заключается в том, что другие проекты с отдельными репозиториями могут нуждаться в его использовании. Но вы всегда можете разделить это позже. Создание git-репо - это дешево, так что это одна из тех вещей, которые вы можете сделать позже, если это станет необходимым. Сложность сразу усложнит вам жизнь, так что не стесняйтесь ждать, пока вы не поймете, что это необходимо
YAGNI это больше, чем просто код.
Мне нравятся ответы Тома или Алекса, за исключением того, что они не имеют реального обоснования позади них
("проще иметь один репозиторий на группу разработчиков"?
"Значительное количество людей могут быть заинтересованы в извлечении (или отслеживании изменений) отдельных приложений"
Зачем?)
Прежде всего, один или несколько репозиториев - это решение администрирования на стороне сервера (с точки зрения ресурсов сервера).
SVN легко настраивает несколько репозиториев на одном сервере, тогда как у ClearCase будет свойvob_server"процесс на VOB, что означает: вам не нужно более ста VOB на сервер (Unix) (или более 20-30 на сервере Windows).
Git специфичен: установка репозитория обходится дешево, доступ к нему может быть легким (через простой общий путь) или может включать процесс (демон git). Последнее решение означает: "не слишком много хранилищ, к которым можно получить доступ напрямую извне". (к ним можно получить косвенный доступ через субмодули, на которые ссылается суперпроект)
Затем идет администрирование на стороне клиента: насколько сложной будет конфигурация рабочего пространства, когда задействованы одно или несколько хранилищ. Как клиент может ссылаться на правильную конфигурацию? (список меток, необходимых для ссылки на правильные файлы).
SVN будет использовать внешние компоненты, git "submodules", и в обоих случаях это добавляет сложности.
Вот почему ответ Тома может быть правильным.
Наконец, есть аспект управления конфигурацией (ссылка в ответе Алекса). Вы можете пометить часть репо нет?
Если вы можете (как в SVN, где вы на самом деле делаете svn-копию части репо), это означает, что вы можете использовать компонентный подход, где несколько групп файлов имеют свой собственный жизненный цикл и свои собственные теги (установленные на их собственный индивидуальный темп).
Но в Git это невозможно: тег ссылается на коммит, который всегда относится ко всему репозиторию.
Это означает "системный" подход, когда вам все равно нужен только весь проект (в отличие от ответа Алекса"смотреть отдельные приложения - я никогда не наблюдал его в реальной жизни"). Если это так (если вам нужна вся система в любом случае), это не важно.
Но для тех из нас, кто мыслит в терминах "независимых групп файлов", это означает, что git-репозиторий фактически представляет отдельную группу файлов (со своим собственным ритмом в терминах эволюции и тегирования), причем потенциально супер-проект ссылается на эти хранилища как подмодули.
Это не ваша повседневная установка, поэтому для независимых проектов я бы порекомендовал только несколько или одно Git-репо.
Но для более сложного взаимозависимого набора проектов... вы должны понимать, что при создании Git "хранилище" представляет собой согласованный набор файлов, которые должны развиваться с той же скоростью, что и все. И не "все" всегда могут уместиться в один набор файлов (если "все" достаточно сложно). Следовательно, в этом случае потребуется несколько хранилищ.
И сложный набор взаимозависимых проектов тоже происходит в реальной жизни;)
Я не эксперт по git, но я не верю, что подходящая стратегия будет отличаться от стратегии для hg, или даже, в данном случае, для svn, так что я все равно собираюсь дать свои 2 цента;-),
Репо для приложения имеет смысл только в том случае, если значительное количество людей может быть заинтересовано в извлечении (или отслеживании изменений) отдельных приложений; теоретически это может иметь место, но я никогда не наблюдал этого в реальной жизни - в основном, люди, которые заинтересованы в проекте, заинтересованы в нем в целом. Поэтому я бы избежал осложнений и превратил весь проект в один репо.
Почти всегда проще иметь один репозиторий на группу разработчиков, независимо от того, сколько у вас продуктов. В конце концов вы захотите поделиться кодом между проектами (даже несколькими отдельными сайтами DJango!), И это будет гораздо проще сделать только с одним репозиторием.
Во что бы то ни стало, создайте красивую структуру папок в этом хранилище. Тем не менее, одна проверка из git (возможно, из подпапки) должна дать вам все файлы, необходимые для вашего тестового сайта (python, templates, css, jpegs...), а затем вы просто скопируете httpd.conf и так далее в завершить установку.
Если у вас есть многократно используемые приложения, поместите их в отдельное хранилище.
Если вы беспокоитесь о количестве частных репозиториев, обратите внимание на bitbucket (если вы решили сделать их открытыми, я советую github)
Есть хороший способ включить ваши собственные приложения в проект, даже используя теги версий:
Недавно я нашел способ сделать это с помощью тегов buildout и git (я использовал svn: externals для включения приложения, но недавно переключился с svn на git).
Сначала я попробовал mr.developer, но, не получая этого, я нашел альтернативу для mr.developer:
Я обнаружил, что gp.vcsdevlop очень прост в использовании для этой цели.
см. https://pypi.python.org/pypi/gp.vcsdevelop
В итоге я поместил это в свой файл компоновки и сразу же заработал (мне пришлось добавить pip require.txt в мое приложение, чтобы оно заработало, но в конце концов это хорошо):
vcs-update = True
extensions =
gp.vcsdevelop
buildout-versions
develop-dir=./local_checkouts
vcs-extend-develop=git+git@bitbucket.org:<my bitbucket username>/<the app I want to include>.git@0.1.38#egg=<the appname in django>
develop = .
в этом случае он выгружает мое приложение и клонирует его в тег версии 0.1.38 в проект в подразделе./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.
РЕДАКТИРОВАТЬ 28 августа 2013
О работе в local_checkouts для общих приложений, включенных в gp.vcsdevelop:
(и обработайте предупреждение, обсужденное в remakr выше)
git push origin + master, похоже, испортил историю коммитов для общего кода
Таким образом, способ работы в директории local_checkout такой:
перейти к локальной проверке (после bin/buildout, чтобы проверка была главной):
cd localcheckouts/<shared appname>
Создайте новую ветку и перейдите к ней следующим образом:
использование git checkout -b 'issue_nr1' (например, название ветви здесь названо в честь проблемы, над которой вы работаете)
и после того, как вы закончите работать в этой ветке, используйте: (после обычных git add и git commit)
git push origin issue_nr1
после тестирования и завершения сливаем ветку обратно в мастер:
Первая проверка мастера:
git checkout master
обновление (возможно, только когда другие коммиты за это время)
git pull
и слиться с мастером (где вы находитесь прямо сейчас):
git merge issue_nr1
и, наконец, нажмите это слияние:
git push origin master
(в частности, благодаря этому упрощенному руководству по git: http://rogerdudler.github.io/git-guide/) и через некоторое время, чтобы очистить ветки, вы можете удалить эту ветку
git branch -d issue_nr1
Используют ли эти отдельные приложения общий код и библиотеки? Если это так, то они действительно принадлежат одному и тому же репозиторию, что позволяет вам увидеть влияние новых изменений при запуске одного пакета тестирования.
Если они совершенно независимы и независимы, это не имеет значения. Просто для здравомыслия, простоты сборки и удобства упаковки, я предпочитаю хранить весь проект в объединенном хранилище. Тем не менее, мы обычно работаем в очень маленьких командах. Таким образом, если общий код не используется, вопрос в том, какой метод наиболее удобен и эффективен для всех заинтересованных сторон.