Как правильно пушить коммиты?

Question

[lucky4]

Очень долгое время работал с гитом, но это были всего лишь учебные проекты, где я все могу кидать в master xD

Теперь меня интересует несколько ситуаций:
1) Пока продукт не сделан окончательно, то в master ветке должно хранится только README.md и пустой проект?
2) К примеру, вот разработчик начинает делать проект -> ему нужно создать отдельную ветку, к примеру "dev" ? И после этого, как он создал ветку dev, он должен от нее сделать еще на каждую новую "фичу" новую ветку от dev?

То есть, к примеру, разработка АПИ. Разработчику сказали сделать endpoint'ы для Categories(CRUD). И какие его должны быть действия?
1) Создавать новую ветку от dev;
2) Запушить в новую ветку коммиты;
(И тут вопрос -> должен ли разработчик коммитить все что сделал одним коммитом? или ему нужно к примеру, models папку - закоммитить как "models / entities" и тд прочие папки с файлами?)
3) Нужно ли делать merge разработчику после проверки высшего по рангу товарища? И куда это должно быть в dev?

Answer 1

[Saboteur]

Никаких "должен одним коммитом или не должен" не существует

Если ты один, ты можешь вести только один мастер.

Если команда - вы договариваетесь в команде, как вам удобнее, оформляете это в правила и следуете.

Продукты бывают разные.
Довольно распространет git-flow, но его бездумное применение приводит к бардаку и оверинжинерингу.

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

Второй вариант использования фича-бренча - это pull request, если вы используете какой-нить code review, и перед пушем в мастер должны быть выполнены дополнительные действия - ручной код ревью или какие-от автоматические тесты, в общем что там в вашем CI наделаете.

Бывает, что одновременно разрабатывается несколько версий, тогда и "мастеров" может быть несколько (релизные ветки).

В простых проектах, обычно просто договариваются о name-convention для веток, с которыми потом проще генерировать различные release-notes, или в названии ветки включать номер тикета в багтрекере.

Answer 2

[iBird Rose]

1) Когда продукт не сделан окончательно - это можно сравнить с твоими учебными проектами. Также хоть в мастер пуш. Вся "правильная" работа с git начинается, когда проект уже зарелизили. Потому что теперь продакшн нельзя ломать.
2) В остальном логика верна. Делаешь ветку для фичи и ведешь ее.

должен ли разработчик коммитить все что сделал одним коммитом? или ему нужно к примеру, models папку - закоммитить как "models / entities" и тд прочие папки с файлами?

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

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

ну тут также как обговорите.