Git: как организовать работу нескольких разработчиков с одним репозиторием?
Здравствуйте!
У меня есть несколько вопросов по организации работы с Git, буду рада, если кто-то сможет что-нибудь посоветовать.
Мы собираемся вести разработку на тестовом сервере без использования программирования на локальных компьютерах. Хотим использовать Git, чтобы можно было видеть, кто и когда какие файлы изменял. Я правильно понимаю, что если к одному репозиторию на сервере обращаются несколько разработчиков, то ветки использовать мы не сможем (из-за того, что репозиторий переключается в какюу-то одну ветку, и вести разработку в нескольких ветках одновременно разным разработчикам не получится)?
Второй вопрос - если мы будет программировать в тесте без веток, точнее всё создавать в master, а потом оттуда сливать в бой (в другой удалённый репозиторий), то можно как-то делать push с указанием, какие именно файлы нужно забросить? То есть, чтобы на удалённый репозиторий переливалась не вся ветка master, а некоторые её файлы.
Если это невозможно в git, то может посоветуете, как можно организовать такой процесс разработки? Использование локальных компьютеров отпадает из-за использования Bitrix. То есть, нужно организовать процесс разработки сайта на одном сервере несколькими разработчиками и затем его переливать в бой.
Вы не верно понимаете, как устроен гит. Мне кажется вы пытаетесь описать svn.
Если вашей изначальной целью было создать среду максимально схожую с продакшн серверном, лучше воспользуйтесь Vagrant.
На тестовом разверните один из репозиториев, для тестирования релизов, а bare репозиторий можно разместить, например, на bitbucket.org (если он вам не подходит по какой-то причине, можно на том же тестовом)
А вот по такой схеме можно работать в команде gitflow.
И небольшая автоматизация процесса.
Спасибо за ответ! Я прочитала статью про gitflow, но у меня остался такой вопрос - так же вроде описывается работа одного разработчика? А если два разработчика делают две разные задачи в одном проекте, и им нужно работать одновременно в двух разных ветках одного репозитория, такое сделать возможно?
@Raily Как я и говорил - минимальный и самый простой набор - gitolite. Поставить и разобраться в его настройке можно за 30 минут примерно.
Дальше надо освоить хуки, написать немного кода на bash, поотлаживать его - и все будет хорошо и ровно.
@Raily Да хоть в скольки угодно.
Gitflow можно применить и в вашем проекте. Не заметил сразу проблему с лицензией.
1) Создайте ssh пользователей на тестовом для разработчиков
2) Установите git, gitflow, настройте итп
3) Заведите каждому разработчику по репозиторию на тестовом. (+главный репозиторий можно завести)
4) bare репозиторий по прежнему можно хранить на битбакете или на тестовом.
5) настройте апач, или что вы там используете (Что бы была у каждого своя ссылка например raily.testserver.exampel.com)
6) Примонтируйте папки. Phpstorm может из коробки работать в подобном ключе. Да и с git работает отлично.
Если это обычная сетевая шара - то работает нормально. А если это сервер, и монтирование по sftp - работает отвратительно медленно. И нету смысла - если есть центральный реп.
@Sander_Li Нет, это не быстрее моего варианта. При sftp папке инициализация проекта в IDE может занимать много времени, будут медленно работать саджесты, к тому же не будет постоянной синхронизации с общим кодом, в итоге код может разойтись (это конечно наиболее актуально для core разработок, которыми я занимаюсь, но и прикладным программистам желательно оставаться в актуальном коде). А в моем варианту я в IDE делаю коммит, и просто запускаю в консоли git push origin (нажимаю стрелочку вверх и энтер). И гит довольно резво все закидывает куда надо.
Дополнительно это дает контроль за мерджами в боевую ветку, можно сделать отдельно ветку под предварительный тестинг перед мерджем, и все это будет еще и автоматизировано.
@Sander_Li можно я ещё раз уточню, правильно ли я поняла? Мы создаём центральный репозиторий в тестовой версии сайта, настраиваем там игнор файлов ядра битрикс. Затем создаём в соседних папках репозитории разработчиков командой clone из центрального репозитория. Затем настраиваем ссылки на папки репозиториев разработков, чтобы каждый разработчик в брайзере видел свою версию сайта. Я правильно поняла? Я только не поняла ещё, что значит примонтировать папки?
@kaasius Инициализация проекта занимает определенное время , верно. (минут 30, но это только один раз делается)
Саджесты работают отлично, потому что ide хранит локальную копию файлов.
Код не разойдется. С таким же успехом он и через гит разойдется.
Неужели это удобно каждый раз выполнять git add + git commit + git push?
Даже в IDE не одна кнопка.
Да и куча непонятных комитов, особенно если надо что-то отладить. Что будет с историей? Я считаю это не удобным, но выбор за разработчиками.
@Raily Примерно так. Не забудьте пользователей создать. Иначе будет путаница.
Каждый разработчик со своими доступами должен подключаться по ssh.
Советовал бы использовать bitbucket для bare репозитория и через хуки можно было бы обновлять тестовый и продакшн сервера, например в зависимости от ветки (master, develop) К тому же bitbucket совместим с многими багтрекерами.
Посмотрите видео. На мой взгляд так удобнее всего работать. (Это по поводу "монтирования", есть софт который монтирует папку, но советую делать как в видео. ) Быть может вам понравится вариант @kaasius, выше я описал чем мне не нравится его вариант.
@Sander_Li У меня ещё возник дурацкий, наверное вопрос, я заранее извиняюсь, просто только пытаюсь разобраться с git. Когда я создаю репозитории для разработчиков, я создаю сначала рабочии копии и в них репозитории? Я задаю этот вопрос вот к чему - не получится тогда, что ядро Bitrix окажется во всех рабочих копиях разработчиков? Это же нарушит лицензию?
@DancingOnWater получается, что тогда локальная копия вообще файлы ядра Bitrix видеть не будет? Или будет? Просто без ядра Bitrix тестовая локальная копия сайта не запустится, как надо.
@Raily Ядро битрикса лучше вынести в отдельное место, общее для всех разработчиков. Хранить его в контроле версий не нужно. Локальная версия имеется ввиду личная папка разработчика на тестовом сервере?
Вижу несколько решений.
1) Если путь до битрикса будет одинаковым, то нет проблем.
2) Скрипт деплоя, который скопирует куда нужно битрикс при разворачивании приложения. (Может как-то организовать через менеджер зависимостей или git подмодули, )
3) Локальные конфиги, которые перетирают основные но не поподают под контроль версий.
Интересные статьи 1 , 2.
День добрый.
Ответ на первый вопрос - нет, вы понимаете неправильно, можно сделать все красиво.
Ответ на второй вопрос вытекает из первого - вам не надо программировать без веток.
Сразу отвечая на третий вопрос - возможно настроить различные доступы на различные ветки, сповесить на это все автотесты, деплой на боевой сервер при пуше в ветку release, а на тестовый сервер - при пуше в ветку test.
Заранее отвечая на вопрос "как", скажу слова gitolite, хуки, bare репы, etc. Но если у вас серьезный бизнес - может вам просто нужен аутсорс админ, чтобы это все настроить? Тогда просто свяжитесь со мной, я вам с этим помогу.
Я понимаю, что в голове у человека. И понимаю, как не надо делать. И могу помочь сделать как надо, от совета "так делать не надо, надо так", до разжевывания, и, если надо, установки и настройки.
@kaasius да дело в том, что наша команда только начинает осваивать git, и я там - просто рядовой разработчик, поэтому я не могу принимать решение по поводу аутсорс админа.
Спасибо за ответ! Мне надо понять - нужен нам вообще git или нет.
Я не могу понять вот что. К примеру, есть в Git следующие ветки: master, test1 и test2. Заходит на сервер первый разработчик, переключается в репозитории на ветку test1, делает в ней что-то. Затем в тот же репозиторий заходит второй разработчик и переключается на ветку test2. Весь репозитоирий в этот момент не будет смотреть в ветку test2? У первого разработчика не произойдёт переключения в ветку test2?
Вы неверно понимаете принципы работы git.
Ветки переключаются на локальных машинах разработчиков. Там они могут плодить эти ветки тыщами.
После некоторой работы разработчик мерджит свою рабочую ветку в какую-то ветку, присутствующую в центральном репозитории (локально), после чего делает push в центральный репозиторий.
В свою очередь центральный репозиторий - bare. Это значит, что там нет рабочей ветки, нет как такового кода - только коммиты в нем хранятся. Соответственно, чтобы изменения попали в тестовое окружение - настраивается деплой по хуку этого bare репозитория в тестовый каталог.
То есть структура такая:
- есть центральный репозиторий, в котором нет текущей ветки и кода, только коммиты.
- есть локальные репозитории разработчиков - там есть рабочая ветка, голова, все прелести гита короче. Этот репозиторий создается путем клонирования от центрального.
- есть рабочие репозитории - тестовые окружения на сервере. Их тоже может быть столько, сколько вам надо. При пуше в центральный репозиторий ветки, у которой есть рабочее окружение, в центральном репозитории срабатывает хук, который, грубо говоря, в нужном рабочем репозитории запускает git pull.
На всем этом пути обильно разложены разнокалиберные грабли, которые мы в свое время обходили около двух-трех месяцев. В результате чего появился набор рабочих инструментов, которые делают все, что нужно. Делают это красиво, просто, и весело.
Я знаю, что обычно используются у каждого своя рабочая версия проекта. Ограничения на использование локальной машины создаёт Bitrix, без него бы было всё понятно. А так есть 2 лицензии - для тестовой и боевой версий сайта. Bitrix установлен на сервер, не я выбирала Bitrix, пришла на то, что есть. Вот теперь вопрос - как с этим лучше работать совместно.
Пока склоняемся работать несколько человек над одним репозиторием, но тут возникает много вопросов. Либо нужно будет ставить каждому виртуальную машину с Bitrix.
@kaasius да, в этом Вы правы. Только получается, что код пишется локально, а чтобы его проверить, его нужно каждый раз заливать на тестовый сервер. Получается тогда, что каждый раз для проверки того, что я написала, мне нужно файлы выгружать на тестовый сервер?
@kaasius как-то это очень сложно получается. То есть, код придётся писать "вслепую", чтобы проверить его работоспособность - каждый раз придётся делать коммиты и push в удалённый репозиторий.
