Как организовать работу в команде с помощью git?

Question

[malibujj]

Добрый вечер! Подскажите, как организовать работу для нескольких frontend и backend разработчиков с помощью git ? Как реализовать ветви, локальные репозитории, как правильнее сливать все проекты в один ?

Answer 1

[Максим Мосейчук]

Организацию работы любой работы стоит начать с изучения документации.
Git не исключение. Git новичку кажется довольно сложной штукой (но на самом деле он очень прост). Поэтому начинать нужно с того, что каждого нужно заставить прочитать Pro Git (или русский перевод "Git для профессионалов"). Читать можно не всё, примерно половину книги занимает информация по администрированию (что рядовому разработчику не нужно). Поэтому времени на изучение уйдёт максимум 5 вечеров.

Тогда 90% вопросов уйдут сами собой.
Не будет тупых вопросов "как удалить коммит", "как правильно мержить", "как пушить" и прочее, что часто проскакивает на тостере.

Из личного опыта.

Ну а по поводу организации ветвления - каноничный GitFlow, либо более удачный (на мой взгляд) GitlabFlow. Или что-то своё, git на это не накладывает никаких ограничений.

Поверьте, работа в команде, которая не умеет пользоваться git, превращается в ад и Израиль.

Answer 2

[Евгений]

Мне кажется, что здесь сложно дать однозначный ответ. Для начала, каждый разработчик должен изучить основные принципы и команды Git. Я много раз сталкивался (и продолжаю сталкиваться) с тем, что разработчики заучивают 2-3 команды (git commit/git pull/git push) и просто долбят их вообще не понимая, что эти команды делают. IDE делают этот процесс еще хуже, потому что там даже не надо задумываться над тем, что вбиваешь, разработчик просто нажимает кнопочку и получает грязь в репозитории. А потом в Slack-чате кричит: «Я все сделал по бумажке! Как мне сказали, сделал git commit и git push, это ваш долбаный git напортачил!» (на самом деле слышал такое и не раз).

Затем можно сделать репозиторий например, с ветками master и ветками, в которые разработчики добавляют новые фичи (или исправляют баги). Например, add-new-image-upload. Так называемые feature-branch'и. При заканчивании работы в feature-бранче, сливать их с master. Высший пилотаж — делать rebase перед слиянием, чтобы не загромождать историю бесполезными merge commits. Еще боле высший пилотаж — перейти на git-flow, который автоматизирует работу с бранчами master, development, feature branches, hotfixes, release branches. Но забегать вперед не стоит.