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

Несколько человек пишут код (php,js,mysql,html). Коммитят это. Push-ают. Код отправляется на сервер Bitbucket.

Почти так. Как правило, в организации командного рабочего процесса есть несколько дополнительных правил.

  1. Под каждую отдельную задачу создаётся отдельная ветка разработки.
  2. Разработчик по ходу работы никогда не должен пушить коммиты в ветку master. Он пушит их в свою ветку разработки.
  3. Когда задача доведена до некоторого итога, создаётся запрос на слияние (merge request, pull request). Либо в какой-то иной форме (хоть устно) обозначается готовность ветки к слиянию. Подробнее: Зачем нужен pull request, если есть push?
  4. Предложенная ветка проходит код-ревью, тестирование и какие угодно другие проверки.
  5. В каждом конкретном случае должен быть один ответственный человек, принимающий решение о слиянии. Это может быть тимлид, тестировщик, ещё кто-то — как договоритесь.

Далее вся комманда 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

Как вы будете развертывать приложение — совершенно отдельный вопрос. Если это интерпретируемый код вроде php или js — удобно использовать rsync. Есть более популярный, но гораздо менее надёжный способ развертывания через репозиторий на production-сервере и git-hook. Если доступен только FTP, придётся через FTP.

Стремитесь к тому, чтобы у вас было абсолютно идентичное окружение на всех этапах процесса: разработка, тестирование, staging (если есть), production.

  • Одинаковая ОС
  • Одинаковые версии всех зависимостей
  • Одинаковый способ развертывания, включая конфигурирование
  • Одинаковый способ запуска приложения
  • Всё вышеописанное должно быть описано хотя бы в некотором документе, а в идеале — в коде.

Так вы страхуете свою команду:

  • от (части) багов, которые просачиваются на прод;
  • от феномена «works on my machine»;
  • от серверов-произведений искусства, которые были настроены год назад человеком, который потом уволился, а теперь никто не может сделать то же самое, поэтому в случае поломки заменить их будет нечем