Comments 14
Практикуется подобное в проекте, над которым работаю.
Очень удобно, в том числе для тестеров. Так как фичи и баги не пересекаются.
Очень удобно, в том числе для тестеров. Так как фичи и баги не пересекаются.
Хорошей идеей будет написать плагин с разграничением прав доступаВозьмите gitolite.
И к нему же можно прикрутить выполнение скриптов)) Такую схему использую сейчас, угнетает количество «забытых» веток. Сейчас пытаюсь перейти на тупую верификацию кода по обновлению и автоматизированный запуск unit-тестов, а установку и удаление проекта максимально упростил до make [un]instal, чтобы каждый отлаживался на своей машине.
Тут вот как раз очень полезная штука подоспела! blog.gitlabhq.com/continuous-integration-server-from-gitlab/
Хочу попробовать её, чтобы все мои вычислительные сервера работали автоматически с одной версией кода.
Хочу попробовать её, чтобы все мои вычислительные сервера работали автоматически с одной версией кода.
Как раз недавно разобрался с установлением прав доступа к веткам
Небольшие улучшения, которые можно добавить:
1. #!/bin/sh -> #!/usr/bin/env sh
2. git clone ветки делать не с центра, а со своего мастера
3. ВСЕ настройки вынести в конфиг, который рядом лежит и подключается через «source» или точку. Вот тогда уже уже можно и на гитхабе выкладывать.
4. А зачем нам миллиард «GIT_SSL_NO_VERIFY=true» — типа переменная только для одной команды ставится? Можно же это один раз сделать с помощью чего-то типа env
5. В хуке oldrev тоже может быть zero`м. А, хотя в update`ах этого по-мойму не бывает.
6. А зачем апач тута вообще? nginx + php-fpm наше всё! :) Или Одмины не желают?
зы: Про проекты понятно, а вот про тестирование в бранчах не совсем. Правильно ли это? А если мы в бранче потестили, заливаем в develop/master и у нас бажок? Лучше наверное тестить в главных ветках, а в бранчах — как некое предварительное лдя девелопера.
1. #!/bin/sh -> #!/usr/bin/env sh
2. git clone ветки делать не с центра, а со своего мастера
3. ВСЕ настройки вынести в конфиг, который рядом лежит и подключается через «source» или точку. Вот тогда уже уже можно и на гитхабе выкладывать.
4. А зачем нам миллиард «GIT_SSL_NO_VERIFY=true» — типа переменная только для одной команды ставится? Можно же это один раз сделать с помощью чего-то типа env
5. В хуке oldrev тоже может быть zero`м. А, хотя в update`ах этого по-мойму не бывает.
6. А зачем апач тута вообще? nginx + php-fpm наше всё! :) Или Одмины не желают?
зы: Про проекты понятно, а вот про тестирование в бранчах не совсем. Правильно ли это? А если мы в бранче потестили, заливаем в develop/master и у нас бажок? Лучше наверное тестить в главных ветках, а в бранчах — как некое предварительное лдя девелопера.
У нас тоже нечто подобное построено, только вместо баша трудится питон. тоже создаются копии сайтов под бранчи, причем при пуше в репозиторий, в бранче на разработке происходит пулл, т.е. там всегда актуальная версия. Естественно все это на локальном серваке, на боевой выкладываем вручную
Почему вы используете в примерах domain.ru, а не example.com?
Правильно ли я понимаю, что под каждую ветку создается свой клон репозитория, который удаляется, когда удаляется ветка в исходном репе? Если да, то как быть с файлами, которые нужны для работы сайта, но находятся под гитигнором? Имею ввиду конфиг БД и т.п.
git push origin :branchname
от стажера/ученика/опечатки обеспечит массу приятных минут. :)
Sign up to leave a comment.
Групповая разработка сайтов через git — автоматическое создание/удаление сайтов из git-бранчей