Задать вопрос

Как вы используете Git во front-end?

Собираюсь делать front-end на основе Gulp + tars (Пока я - единственный человек).
Как вы организовали свой git-workflow, что добавили в .gitignore, какая структура веток, как часто делаете коммиты и тд?

Что я планирую:
  • Будет главная ветка master
  • Для каждой страницы (index, about, contact и проч.) буду создавать по ветке.
  • Также для каждой такой ветке будет еще одна - bugs, на которую я буду переключаться если будут скидывать какие-то баги по странице.
  • В конце все сливать в master.


В .gitignore добавлю все, кроме папки source (в которой буду работать).

С одной стороны мне кажется это незамысловатой структурой, но удобной, а с другой - чувство, что я не учел еще много вещей
  • Вопрос задан
  • 1523 просмотра
Подписаться 4 Оценить 1 комментарий
Решения вопроса 1
@fetis26
Ну, за фронтенд!
Какая-то замороченная, если не сказать неправильная структура.
В общем случае вам пока хватит 2 веток: master где лежит стабильный код и develop для разработки.
В игноре обычно лежат node_modules и любые генерируемые файлы.
Частота коммитов на ваш вкус. Обычно в него стараются положить какую-то законченную работу. Чем коммит меньше по изменения, тем легче отслеживать изменения в истории.

Я так понимаю никакой системы ведения задач нет?
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
romy4
@romy4
Exception handler
> Как вы используете Git во front-end?
да

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

вы задолбаетесь с мерджами
одна задача — одна ветка. потом сразу мердж в мастер.
Ответ написан
SuccessVM
@SuccessVM
Программирование - творчество
В основу системы контроля версий Git был заложен принцип «веток». Где каждая ветка подразумевает собой либо новую функциональность, либо исправление предыдущей функциональности, при этом сами ресурсы/файлы повторно не копируются, как при том же svn. Отсюда вывод, что новая ветка – это изменение как одного какого-либо файла, так и совокупность изменений, в результате которых будет реализована или исправлена какая-либо функциональность конечного продукта. Основное правило: всё, что попадает в master, должно работать и собираться без ошибок. Из основного правила вытекает второе правило, другие ветки необходимо создавать только из ветки master.

В .gitignore ты добавляешь любые файлы, которые необходимо игнорировать – это в основном исполняемые файлы или библиотеки (.exe, .dll и т.д.), в случае с компилируемыми языками программирования или например сторонние библиотеки, например тот же Gulp или Grunt, в данном случае нет смысла отслеживать данные библиотеки, т.к. этим занимаются другие разработчики. В моей практике в систему контроля версий попадали файлы с ресурсами (форматы Photoshop, Flash, Illustrator и т.д.), но лучше разбить на разные проекты и код не смешивать со статикой.

Существуют готовые подходы к разработке с использованием систем контроля версий на основе Git. Ознакомься с GitFlow:

782a1be3.png

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

Полезные статьи:

Comparing Workflows - кратко и понятно описаны разные подходы к разработке с использованием Git, в том числе и GitFlow.

Удачная модель ветвления для Git – перевод одноимённой статьи о подходе GitFlow.

Understanding the GitHub Flow – ещё один набор привил особенно для любителей GitHub.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы