How do you use Git in the front-end?

Question

git

I'm going to make a front-end based on Gulp + tars (I'm the only person for now).
How did you organize your git workflow, what did you add to .gitignore, what is the branch structure, how often do you commit, etc.?
What I'm planning:

• There will be a master branch
  
• For each page ( index, about, contact , etc.) I will create a branch.
  
• Также для каждой такой ветке будет еще одна - bugs, на которую я буду переключаться если будут скидывать какие-то баги по странице.
  
• В конце все сливать в master.
  

В .gitignore добавлю все, кроме папки source (в которой буду работать).
С одной стороны мне кажется это незамысловатой структурой, но удобной, а с другой - чувство, что я не учел еще много вещей

Answer 1

Какая-то замороченная, если не сказать неправильная структура.
В общем случае вам пока хватит 2 веток: master где лежит стабильный код и develop для разработки.
В игноре обычно лежат node_modules и любые генерируемые файлы.
Частота коммитов на ваш вкус. Обычно в него стараются положить какую-то законченную работу. Чем коммит меньше по изменения, тем легче отслеживать изменения в истории.
Я так понимаю никакой системы ведения задач нет?

Answer 2

> Как вы используете Git во front-end?
да
> Для каждой страницы (index, about, contact и проч.) буду создавать по ветке.
безумие)
вы задолбаетесь с мерджами
одна задача — одна ветка. потом сразу мердж в мастер.

Answer 3

В основу системы контроля версий Git был заложен принцип «веток». Где каждая ветка подразумевает собой либо новую функциональность, либо исправление предыдущей функциональности, при этом сами ресурсы/файлы повторно не копируются, как при том же svn. Отсюда вывод, что новая ветка – это изменение как одного какого-либо файла, так и совокупность изменений, в результате которых будет реализована или исправлена какая-либо функциональность конечного продукта. Основное правило: всё, что попадает в master, должно работать и собираться без ошибок. Из основного правила вытекает второе правило, другие ветки необходимо создавать только из ветки master.
В .gitignore ты добавляешь любые файлы, которые необходимо игнорировать – это в основном исполняемые файлы или библиотеки (.exe, .dll и т.д.), в случае с компилируемыми языками программирования или например сторонние библиотеки, например тот же Gulp или Grunt, в данном случае нет смысла отслеживать данные библиотеки, т.к. этим занимаются другие разработчики. В моей практике в систему контроля версий попадали файлы с ресурсами (форматы Photoshop, Flash, Illustrator и т.д.), но лучше разбить на разные проекты и код не смешивать со статикой.
Существуют готовые подходы к разработке с использованием систем контроля версий на основе Git. Ознакомься с GitFlow:
GitFlow - это набор правил, при котором заранее оговорено, в какой ветке будет вестись разработка, в какой тестирование, в какой исправление ошибок и т.д. GitFlow особенно подойдёт для масштабных проектов с командой. В случае небольшого проекта, вполне хватит стандартных веток.
Полезные статьи:
Comparing Workflows - кратко и понятно описаны разные подходы к разработке с использованием Git, в том числе и GitFlow.
Удачная модель ветвления для Git – перевод одноимённой статьи о подходе GitFlow.
Understanding the GitHub Flow – ещё один набор привил особенно для любителей GitHub.