Командная работа с topic-ветками в Git

#git #git_branch

Только изучаю Git. В голове каша. Не совсем понимаю как командно работать с тематическими/короткоживущим
ветками и при этом не превратить проект и репозиторий в хаос.

Подскажите, верная эта схема или нет? 
На сервере 2 ветки: master, develop. Все работают с develop.
Допустим, какому-то сотруднику нужно создать меню. 


Создаёт новую ветку: git checkout -b feature-menu
Пушит её на сервер: git push -u origin feature-menu
Работает, делает коммиты, пуллит чужие и пушит свои изменения
Кто-то другой делает git checkout -b feature-menu origin/feature-menu и тоже что-то
правит
Когда работа закончена, сотрудник сливает ветку: git checkout develop; git merge
feature-menu; Разрешает конфликты
Делает git pull и git push develop-ветки
Удаляет ветку локально и удалённо git branch -D feature-menu; git push origin :feature-menu;
Готово


Доп. вопрос: После того, как сотрудник1 слил и удалил ненужную ветку (пункт 7), у
сотрудника2, который тоже работал с этой веткой, после пулла она всё равно локально
останется? Нельзя сделать так, что после того как ветка отработала и была удалена с
сервера больше у сотрудников она не появлялась нигде. Или это не нужно?

Доп. вопрос 2: Если сотрудник работает над веткой один. Принято ли её пушить на сервер
или сливать локально и пушить уже develop?
    

Ответы

Ответ 1

Схема выглядит правдоподобно. Единственное, что пушить свежосозданную ветку на сервер
сразу не обязательно, можно и потом. Удалять ветку лучше так git branch -d feature-menu.
-D удалит ветку в любом случае, а -d только если ветка была замерждена.


  Доп. вопрос: После того, как сотрудник1 слил и удалил ненужную ветку (пункт 7),
у сотрудника2, который тоже работал с этой веткой, после пулла она всё равно локально
останется? 


да, локальная ветка никуда не пропадет. Но он может сделать git pull --prune -  тогда
будет удалена.


  Нельзя сделать так, что после того как ветка отработала и была удалена с сервера
больше у сотрудников она не появлялась нигде. Или это не нужно?


Если сотрудник не сделает pull --prune, то она будет у него жить дальше. Но это его
личное дело.


  Доп. вопрос 2: Если сотрудник работает над веткой один. Принято ли её пушить на
сервер или сливать локально и пушить уже develop?


Можно не пушить. Это его личное дело. Но если он вдруг заболеет или его компьютер
решит сходить в ремонт, может быть очень неприятно. Поэтому, если это свои маленькие
эксперименты, то обычно не пушат. Если это код, который решает конкретную задачу (которая
есть в jira или чему то подобном), то лучше пушить.


Ответ 2

Немного дополню отличный ответ KoVadim.


  
  Кто-то другой делает git checkout -b feature-menu origin/feature-menu и тоже что-то
правит
  


Технически можно, главное договориться о таком формате работы, чтобы не было неожиданностей.
Если всё-таки оба одновременно закоммитили в ветку, то один делает git push, а другой
git pull --rebase и разрешает конфликты, если будут. Просто git pull хуже, т.к. появится
мерж-коммит, который в данной ситуации никакой информации не несёт, а только засоряет
историю. 


  
  Когда работа закончена, сотрудник сливает ветку: git checkout develop; git merge
feature-menu; Разрешает конфликты
  Делает git pull и git push develop-ветки
  


Лучше сначала обновить ветку develop, а потом в неё что-то мержить, иначе есть риск
разрешать конфликты два и более раз.

git checkout develop
git pull
git merge feature-menu
git push


Вообще, мерж ветки — задача ответственная. Нередко право мержить в стабильные ветки
есть только у тимлида, который отвечает за ревью кода и за состояние кода в этих самых
стабильных ветках. Если у вас есть тестировщики, договоритесь с ними, когда они будут
тестировать изменения — до мержа или после. Если вы используете GitHub, GitLab, Bitbucket
– подумайте о возможности использовать пулл/мерж-реквесты (pull requests, merge requests).
Совсем не обязательно, что для вашего проекта и команды это будет хорошо и полезно,
но подумать стоит.

Про работу с ветками рекомендую почитать ответы к этому вопросу: Как правильно отправить
релиз на git?.
Обязательно прочитайте все, а не только принятый.
Там изложены разные точки зрения и это поможет сформировать более полную картину.