Управление версиями для [закрытой] разработки PHP
6 ответов
Похоже, что Git вполне может достичь ваших целей. Поскольку он является распределенным, он отлично подходит для локальной работы, поскольку вы можете выполнять большинство операций (commit, revert, diff, patch) без подключения к центральному серверу. Вы также можете избежать того неприятного момента, когда кто-то выкладывает новый код в продакшн, а кто-то другой работает над ним, а затем приходится решать сложную задачу слияния этих двух версий кода вместе (git предоставляет для этого полезный инструмент под названием rebase).
Вы отметили, что некоторые крупные проекты используют Hg (Mercurial), но есть и довольно крупные проекты, использующие Git, такие как ядро Linux, X.org, Android и Debian.
Я использую git для всех своих сайтов: он молниеносен, эффективен и прост в использовании.
Правка: Если вы хотите начать использовать Git, я бы порекомендовал вам немного почитать, прежде чем приступать к работе. Неправильное начало может привести к ужасным последствиям в дальнейшем. Если вы следуете Agile Workflow, вам стоит ознакомиться с этим. Вот сайт, на котором я узнал большую часть своих ноу-хау по Git.
Прошу прощения, у меня не было намерения начинать священную войну DVCS. Я собираюсь попробовать Git.
Определенно Mercurial. Хотя вы можете использовать Git или SVN, Mercurial лучше по двум причинам:
- По сравнению с Git: хорошая интеграция с Windows.
- Против SVN: Распространяется.
Если вы не хотите запускать сервер Mercurial самостоятельно (что в любом случае довольно просто), существует множество доступных сервисов. Kiln + FogBugz - ОТЛИЧНАЯ комбинация. Также есть CodeBaseHQ (также поддерживает Git и SVN), Bitbucket и многие другие.
Прежде чем перейти к ней, я настоятельно рекомендую вам прочитать хотя бы учебник Джоэла Спольски , но я настоятельно рекомендую вам также прочитать Mercurial: The Definitive Guide .
Контроль версий - невероятный инструмент, даже когда вы работаете в одиночку, а когда вы работаете с кем-то еще, он просто незаменим. Я бы рекомендовал использовать git. Он очень быстрый, имеет действительно большой набор доступных инструментов и, конечно же, имеет github.com. Mercurial в принципе так же хорош, как и git, но работает немного медленнее и не имеет github.
О том, почему стоит использовать git, читайте http://whygitisbetterthanx.com/
Вот симпатичный учебник по началу работы с git: http://www-cs-students.stanford.edu/~blynn/gitmagic/index.html
Вы можете использовать SVN, Git, Mercurial.
Самая большая проблема заключается в том, чтобы все были дисциплинированы в использовании контроля версий и не ленились.
Да, контроль версий поможет. Чтобы начать, я вижу два важных вопроса для вас:
хостинг или самоуправление? Хотите ли вы разместить это сами на сервере или хотите, чтобы служба позаботилась об этом за вас? Есть причины выбрать любой из этих вариантов, но если вам не очень нравится управлять сервером, обратите внимание на вариант с хостингом.
SVN или Git Есть и другие, но это главные претенденты с открытым исходным кодом.
Плюсы и минусы (мое мнение):
SVN: Хорошие учебники и довольно легко освоить. Требования к обучению невелики (я проделал небольшую часть работы). SVN очень хорошо работает с командой, расположенной в одном месте, большим количеством проектов и т.д. При ограниченном количестве ветвей (вам может не понадобиться ни одной), она надежна. Существует множество интеграций с другими инструментами.
Git: Начало работы может быть немного сложнее, чем с SVN. Некоторые документы хороши, но многие из них предполагают довольно глубокое понимание внутренних механизмов. Когда вы освоитесь, он обладает большой гибкостью, но я видел, что почти все, кто начинал работать с ним, спотыкались в самом начале. Даже проработав с ним несколько месяцев, люди спорят о том, какие шаблоны лучше использовать. Он действительно хорош для проектов на одного человека (где вы хотите отслеживать историю) и для распределенных проектов, таких как GitHub. Я использую Git даже для небольших совместных команд, потому что мне нравится скорость и гибкость.
Учитывая то, что вы говорите о своей команде, я бы, вероятно, рекомендовал попробовать SVN. Там будут лучшие ресурсы, чтобы помочь вам начать работу, и вы с меньшей вероятностью разочаруетесь в нем.
Надеюсь, это поможет.