Прошло чуть более двух лет с момента перехода от устаревшего CVS к Subversion (SVN), и PHP снова в движении : на этот раз — Git . Ну, в конце концов. Переход с CVS на SVN был огромным и занял много месяцев. Потребность в проекте PHP для поддержки своей пользовательской базы, сценариев перехвата (список рассылки коммитов и т. Д.) Означает, что любое изменение программного обеспечения для управления ревизиями означает довольно большие обязательства. Вот почему, несмотря на то, что голосование окончено и пыль улеглась, мы не увидим PHP на Git до конца этого года.
Почему я голосовал за Git?
Следуя тому же миграционному маршруту, что и PHP, для моих собственных потребностей в версиях, начиная с CVS и переходя на Subversion, а затем, совсем недавно, на Git, я из первых рук ощутил преимущества, которые каждая из этих систем приносит своим предшественникам.
Subversion (по крайней мере в v1.5, когда я последний раз использовал его) имел очень плохое управление ветвями. Для существующих репозиториев возможность использовать отслеживание слияний не существовала каким-либо значимым образом, и даже с небольшой командой у нас часто возникали большие сложные конфликты, которые нужно было разрешить. В то время как Git предлагает совершенно новый способ мышления, для меня одно только его управление филиалами стоило отойти от Subversion.
Что это значит для PHP?
Благодаря переходу на Git и его превосходной способности создавать и объединять ветки, разработчикам PHP теперь предоставляется большая гибкость как для внесения, так и для принятия вкладов. Вместо традиционной модели разработки — составления плана и его соблюдения (ха!) Со всеми разработчиками, работающими в одной и той же ветке (например, HEAD), разработчики могут работать в своем собственном темпе в своих ветвях, а затем прийти к консенсусу, по которому их ветви будут составлять данную сборку.
Такое слияние ветвей может быть потенциально огромным сдвигом в цикле разработки PHP, поскольку оно делает множество вариантов доступными для команды. Например, они могут продолжать в том же духе или могут переключиться на ежеквартальный или двухгодичный цикл выпуска. Они даже могут делать выпуски чаще, выпуская функции сразу, как только они станут стабильными. Если функция еще не готова, просто не объединяйте ее.
Кроме того, Git предлагает гораздо больше удобства для разработчиков ядра, многие из которых путешествуют по всему миру и получат выгоду от сценария «локальная фиксация, когда застрял в самолете», который позволяет распределять системы контроля версий. И давайте посмотрим правде в глаза, все, что мы можем сделать, чтобы облегчить жизнь основным разработчикам, выгодно для проекта.
Что это значит для тебя?
Если вы еще этого не сделали, вам нужно начать совершенствовать свои навыки в Git. Я уверен, что мы увидим, если не официальный клон, репозиторий PHP на GitHub раньше, чем позже, что упростит раскладку репозитория и внесение изменений.
С потенциальными изменениями в циклах разработки это также может означать, что новые функции будут доступны вам гораздо быстрее — с учетом того, что большинство компаний, занимающихся виртуальным хостингом, будут отставать (кого это волнует?).
В целом, я чувствую, что переход с Subversion на Git может быть полезен только для проекта PHP и сообщества в целом. И, судя по результатам голосования, переход на Git может быть спорным (хотя я думаю, что справедливее будет сказать, что отказ от Subversion вызвал любые споры), но 78 голосов за миграцию и 52 из них выбрали Git. Довольно ясно, что сообщество разработчиков PHP поддерживает это решение.
Изображение через марему / Shutterstock