Я являюсь руководителем группы в нашей компании по веб-разработке, и я хотел бы внедрить рабочий процесс Git в нашу команду. Читая документацию и статьи, я нашел следующую структуру полезной для нас:

У нас есть хранилище в Bitbucket.Мастер считается, что ветвь содержит только стабильный код. Каждый разработчик должен создать свою собственную ветку и внедрить функции / исправления в своемсвоя ветка. Как только он решает, что его код готов, он создает хорошую историю ветвлений (используя rebase, редактировать, cherry-pick и т. Д.) И отправляет ее в Bitbucket, где создает запрос на получение ветки master. QA проверяет функциональность и одобряет (или не одобряет) ее, затем я проверяю код и, если все в порядке, объединяю его работу в master (путем ускоренной перемотки вперед или перебазирования для лучшей истории фиксации).

Но эта схема хороша только в том случае, когда на ветке работает один разработчик. В нашем случае у нас почти всегда есть два разработчика для одной ветви, так как один разработчик работает надна стороне сервера (PHP), а другой -сторона клиента (HTML / CSS / JS). Как эти двое должны сотрудничать таким образом, чтобы история коммитов оставалась чистой?

Серверный разработчик создает базовую структуру файлов HTML, и клиентская разработка должна получить эту структуру. Логично было бы для сервера dev создать ветку, а для клиента dev создать собственную ветку, основанную на ветке сервера dev. Но это означает, что серверный разработчик долженпубликовать его ветка в Bitbucket, что сделает егодля него невозможно перебазировать или изменить коммиты, которые уже опубликованы.

Другой вариант - подождать, пока server dev закончит свою работу, опубликует ветку с хорошей историей коммитов и забудет об этом, и только после этого клиентский dev начнет работать в этой ветке, но это приведет к задержкам, что еще хуже.

Как вы справляетесь с таким сотрудничеством в ваших рабочих процессах?