GIT рабочий процесс для веб-разработки


12

Давным-давно небольшая команда веб-разработчиков, с которыми я работаю, начала использовать git для веб-разработки. Тогда мы просто посвятили себя постановке или мастерству, а затем часто сливались между ними. Это было лучше, чем ничего, но это был и беспорядок.

Не так давно мы приняли рабочий процесс gitflow. Хотя это, безусловно, лучше, чем хаос, который был до этого, он кажется несколько громоздким и чрезмерно ориентированным на выпуск / этап. Мои коллеги-разработчики часто просят меня уточнить, как это должно работать и что должно сливаться, а что нет. В целом он кажется плохо приспособленным для веб-разработки, где мы часто развертываем код и не отслеживаем конкретные этапы выпуска.

По недавнему предложению друзей я начал изучать GitHub Flow . Чтение поста Скотта Чакона здесь совершенно точно больно:

Итак, почему мы не используем git-flow на GitHub? Ну, главная проблема заключается в том, что мы развертываем все время. Процесс Git-потока разработан в основном вокруг «выпуска». На самом деле у нас нет «релизов», потому что мы внедряем в производство каждый день - часто несколько раз в день.

FWIW, я также рассмотрел этот приятный обзор рабочих процессов на сайте Atlassian: https://www.atlassian.com/git/workflows#!workflow-feature-branch

Однако они ВСЕ выглядят как неудачный выбор для веб-разработки в небольшой команде и снова ориентированы на крупные выпуски приложений, а не частые / ежедневные выпуски.

Это вопрос к SE, который просит сравнить git-поток с github-потоком /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -течь

В общем, это хороший ответ, но, как я уже упоминал в своем комментарии ниже, meta.programmers.SE, похоже, указывает на то, что вопросы об общих лучших практиках рабочего процесса относятся к этому, и я надеялся на более широкий список возможных ответов, чем просто git-flow и github. -поток, в то время как конкретные для веб-разработки Поэтому я думаю, что здесь возникает новый вопрос.

Что, по вашему мнению, является лучшим / предпочтительным рабочим процессом на основе git для небольшой команды веб-разработчиков, работающей над проектами с довольно непрерывным развертыванием? Это GitHub-поток или что-то еще?


Кстати, я задаю
jb510

Обмен вашими исследованиями помогает всем . Расскажите нам, что вы пробовали и почему это не соответствует вашим потребностям. Это свидетельствует о том, что вы потратили время, чтобы попытаться помочь себе, избавляет нас от повторения очевидных ответов и, прежде всего, помогает получить более конкретный и актуальный ответ. Также см. Как спросить
комнат

@gnat Я не уверен, что еще я мог бы поделиться в этом отношении? Gitflow, так ориентированный на выпуск, громоздок. GitHub-Flow предназначен для ежедневного развертывания, но наличие десятков веток, ожидающих слияния, также выглядит как хаос. Я надеялся, что кто-то ответит: «X отлично подходит для веб-разработчиков, потому что Y». Это хорошо отражено в ссылке, которую я предоставил, наверное, я мог бы извлечь цитаты из нее?
jb510

1
@gnat - я полностью переписал вопрос, чтобы показать больше исследований и быть очень конкретным в отношении ответа, который я ищу.
jb510

Ответы:


7

Сначала я хотел бы сделать небольшое резюме о различных рабочих процессах, которые вы изучили, и вы думаете, что они не подходят для того вида разработки, над которым вы работаете:

  • Централизованный ( Источник ): почти как рабочий процесс SVN, но теперь в распределенной среде. Каждый разработчик работает с персональной копией masterи вносит изменения origin/masterнапрямую или по запросу.

  • Характеристика ветки ( Источник ): Ну, это. Каждый разработчик, работающий над определенной функцией, должен работать над определенной веткой, предназначенной только для этой функции. Эта ветвь элемента должна быть создана из masterили из другой ветви элемента. В конце концов все объединяется с master.

  • Gitflow ( источник ): две основные ветви отслеживают историю проекта, developи master. Еще 3 ветви называется hotfix, releaseи featureизменения владения сделаны непосредственно masterдля фиксации важных производственных ошибок, номера изменения версии и других деталей до отпуска или работу по конкретной функции так же , как это ответвление , соответственно.

  • Поток GitHub ( Источник ): Разработчики создают featureветку master. Изменения проталкиваются через запрос на извлечение. Изменения, принятые в систему, master сразу же запускаются ботом GitHub Hubot.

Для части вашего вопроса по разработке ответ зависит от опыта вашей команды. Они приходят из среды SVN? Тогда вам следует придерживаться централизованного подхода, поскольку он больше всего напоминает SVN. Чувствуют ли они себя комфортно, работая с Git? Тогда, возможно, вам не следует пытаться адаптировать рабочий процесс своей команды к какому-либо из них, а реализовывать свой собственный, разработанный в соответствии с вашими потребностями, которые, если я правильно понимаю, это гибкость разработки и быстрое развертывание.

Я также думаю, что вы должны сосредоточиться на улучшении последнего. Из чего состоит ваш конвейер развертывания ? В статье « Непрерывная доставка: надежные выпуски программного обеспечения с помощью автоматизации сборки, тестирования и развертывания » авторы определяют возможные причины нечастых развертываний, некоторые из которых:

  • Процесс развертывания не автоматизирован.
  • Тестирование занимает много времени.
  • Люди не понимают процесс сборки / тестирования / развертывания.
  • Разработчики не следят за тем, чтобы приложение работало, внося небольшие, постепенные изменения и часто нарушая существующие функции.

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


2
+1, ключ к cd - не git или ваш gitflow, а CI и рабочий процесс доставки.
Уайетт Барнетт

Думая много об этом. Спасибо за понимание. Я специально избегаю использовать термин CI, потому что мы не используем CI. Может быть, нам следует, но мы этого не делаем, это просто слишком громоздко для десятков проектов, над которыми мы работаем в течение данной недели, какого-то краткосрочного, какого-то долгосрочного.
jb510

2
@ jb510 - у нас есть аналогичная настройка проекта, я бы не мечтал летать без CI. Переключение контекстов намного проще, когда все тупые, но хрупкие части написаны по сценарию.
Уайетт Барнетт

1
Иногда неспособность легко реализовать CI является признаком того, насколько вам нужен CI в проекте. Нет юнит-тестов? Развертывание все вручную? Множество шагов развертывания? Нужна экспертиза.
Kzqai

1
Я следил за этим вопросом и отвечал на протяжении многих лет. Я надеялся, что другие тоже предложат ответы, но сам по себе это отличный ответ, поэтому, наконец, отметив его как принятый (вероятно, следовало бы сделать это давным-давно)
jb510
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.