При разработке всегд используются системы контроля версий, обычно это git. Есть популярная система работы с ветками и репозиториями git-flow, но она больше подходит для оупенсурс разработки. В обычном же проекте обычно всё чуть по другому.

Обычно есть один главный репозиторий с UI для него вроде github, gitlab или bitbucket. Заводятся две рабочие ветки:
1. master — продакшен код
2. develop — текущая разработка

Разработчик делает ветку от develop с названием по номеру в системе трекинга и кратким описанием: для фичи git checkout -b feature/PRJ-123—task-description origin/develop или для багофикса использует другой префикс ветки git checkout -b bug/PRJ-123—bugfix origin/develop. Разработка фичи ведётся в этой ветке, делаются коммиты. Хорошая практика требует всё оформлять в один коммит, чтобы затем было удобно смотреть историю, делать git blame и видеть весь затронутый функционал. Если фича длинная и делалось несколько коммитов, то их нужно объединить в один git rebase -i HEAD~3. Здесь хорошая статья по теме git squash. Либо можно делать одним коммитом в который подливать правки через amend — git commit -a. ВАЖНО перед пушем подлить свежий девелоп и делать это через rebase, чтобы ваши правки в истории были последними.
git fetch
git rebase origin/develop

После этого отправляем правки в главный репозиторий. И там делаем пулл реквест в ветку develop.

Важно что ветки master и develop закрыты на запись, чтобы никто случайно не пушнул туда измения. Все заливки туда делаются через pull request. Смержили develop с фичей, сделали пулреквест из develop в master, смержили. Дальше по вкусу делаем либо релиз брант от мастера, либо тегаем версию мастера git tag -a v0.1 -m «tag version 0.1».

Дальше CI по релизной ветке или тегу всё деплоит в прод, а вы идёте пить пиво.

Есть пару типичных проблем:

1. Боязнь rebase. Данная команда переписывает историю, её ни в коем случае нельзя использовать в общих ветках master и develop. Но в личных фичебранчах это нужно делать обязательно чтобы правки не перемешались или не затерли чужие изменения.
2. Много коммитов в фиче бранче, которые вмержены без squash. Из-за этого в дальнейшем тяжело работать в команде, потому что история разнесена по кускам и нельзя нормально блеймить.
3. Не делаются релизные бранчи-теги, из-за чего можно получить сломанный мастер и неудобство при откате. Хотя CI можно и на коммит в мастере настроить.
4. Хотфиксы. Они нужны для быстрых изменений на проде, в то время как у вас в девелопе уже есть накопившиеся изменения. Хотфикс ветки делаются от master и пулреквест сразу в мастер. Затем делается ветка от develop и туда cherry-pick коммита с фиксом. Хотфиксы очень плохо и бывают конфликты при переносе в develop, лучше их избегать.
5. И последняя проблема — это выбор пива. Большую часть жизни я пил тёмное, но последние годы экспериментирую и предпочитаю томатное, фруктовое и кисляки. Надеюсь этот выбор будет единственной проблемой при работе с git.