Поясните принципы web-разработки через bitbucket

Здравствуйте! День назад освоил азы Bitbucket, поставил SourceTree. Суть вопроса: правильно ли я понимаю алгоритм разработки через Bitbucket?
Несколько человек пишут код(php,js,mysql,html). Коммитят это. Push-ают. Код отправляется на сервер Bitbucket; Далее вся комманда Pull-ами синхронизирует код у себя на машинах; Код то на FTP должен лежать. Как это делать на FTP? Или я не понимаю матчасть?))
Мысль приходит мне что нужно запускать код на клиентах. ТО есть каждый член комманды запускает код через что хочет. Хоть денвер хоть опенсервер хоть ручками поставленный Apache+MySQL+PHP.
Поясните падовану плиз, о седовласые мастера!

Ответ

Несколько человек пишут код(php,js,mysql,html). Коммитят это. Push-ают. Код отправляется на сервер Bitbucket;
Почти так. Как правило, в организации командного рабочего процесса есть несколько дополнительных правил.
Под каждую отдельную задачу создаётся отдельная ветка разработки. Разработчик по ходу работы никогда не должен пушить коммиты в ветку master. Он пушит их в свою ветку разработки. Когда задача доведена до некоторого итога, создаётся запрос на слияние (merge request, pull request). Либо в какой-то иной форме (хоть устно) обозначается готовность ветки к слиянию. Подробнее: Зачем нужен pull request, если есть push? Предложенная ветка проходит код-ревью, тестирование и какие угодно другие проверки. В каждом конкретном случае должен быть один ответственный человек, принимающий решение о слиянии. Это может быть тимлид, тестировщик, ещё кто-то - как договоритесь.
Далее вся комманда Pull-ами синхронизирует код у себя на машинах;
Тоже почти так.
Команда git pull фактически включает в себя две: git fetch + git merge. С первой обычно не бывает проблем, вторая может застопориться на конфликтах. Я обычно обновляю master, а потом делаю rebase текущей ветки на него
git fetch # посмотрим, что к нам пришло git log --oneline --graph --decorate --all
# обновим master git checkout master git merge origin/master # или просто git pull
# переставим текущую ветку на новый master. # при наличии конфликтов лучше разрешить их сейчас, чем потом при слиянии в master git checkout myfeature git rebase master
Код то на FTP должен лежать. Как это делать на FTP? Или я не понимаю матчасть?))
Не путайте хранение кода и развертывание приложения. Хранится код внутри гита, в его собственной базе данных. На сервере вроде Bitbucket вообще нет тех файлов, которые лежат у вас в рабочей папке, потому что это bare-репозиторий и там есть только собственное хранилище.
Как вы будете развертывать приложение - совершенно отдельный вопрос. Если это интерпретируемый код вроде php или js - удобно использовать rsync. Есть более популярный, но гораздо менее надёжный способ развертывания через репозиторий на production-сервере и git-hook. Если доступен только FTP, придётся через FTP. Подробнее: Настройка и развертывание проекта c помощью Git
Мысль приходит мне что нужно запускать код на клиентах. ТО есть каждый член комманды запускает код через что хочет. Хоть денвер хоть опенсервер хоть ручками поставленный Apache+MySQL+PHP.
Стремитесь к тому, чтобы у вас было абсолютно идентичное окружение на всех этапах процесса: разработка, тестирование, staging (если есть), production.
Одинаковая ОС Одинаковые версии всех зависимостей Одинаковый способ развертывания, включая конфигурирование Одинаковый способ запуска приложения
Всё вышеописанное должно быть описано хотя бы в некотором документе, а в идеале - в коде.
Так вы страхуете свою команду:
от (части) багов, которые просачиваются на прод; от феномена "works on my machine"; от серверов-произведений искусства, которые были настроены год назад человеком, который потом уволился, а теперь никто не может сделать то же самое, поэтому в случае поломки заменить их будет нечем