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

Давно невелика команда веб-розробників, з якими я працюю, почала використовувати git для веб-розробки. Тоді ми просто зобов’язалися безпосередньо влаштовувати або освоювати, а потім часто зливатися між ними. Це було краще, ніж нічого, але це теж був безлад.

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

За останніми пропозиціями друзів я почав дивитися на GitHub Flow . Читання публікації Скотта Чейкона тут ідеально відповідає цьому:

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

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

Однак вони ВСІ схожі на поганий вибір веб-розробки в невеликій команді і знову орієнтовані на основні випуски додатків, а не часті / щоденні випуски.

Це питання над SE просити порівняти git-flow з github-flow /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -потік

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

Зважаючи на це, що ви вважаєте найкращим / бажаним робочим процесом на основі git для невеликої команди з веб-розробників, яка працює над проектами з досить постійним розгортанням? Це github-flow чи щось інше?

По-перше, я хотів би зробити короткий підсумок різних робочих процесів, які ви розглянули, і, на вашу думку, не підходять для того, на який розвиток ви працюєте:

• Централізоване ( Джерело ): майже схоже на робочий процес SVN, але зараз у розподіленому середовищі. Кожен розробник працює над особистою копією masterта надсилає зміни origin/masterбезпосередньо або за допомогою запиту на виклик.

• Особливість галузі ( Джерело ): Ну, що. Кожен розробник, який працює над певною функцією, повинен працювати над певною галуззю, присвяченою лише цій функції. Ця гілка функцій повинна бути створена masterз іншої гілки або з неї. Врешті-решт все зливається назад master.

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

• Потік GitHub ( Джерело ): Розробники створюють featureвідгалуження master. Зміни висуваються через запит на тягу. Зміни, прийняті до того, master щоб їх негайно розгорнув бот GitHub Hubot.

На розробну частину вашого запитання відповідь залежить від фону вашої команди. Вони походять із середовища SVN? Тоді вам слід піти з централізованим підходом, оскільки саме той найбільше нагадує SVN. Чи їм комфортно працювати з Git? Тоді, можливо, вам не слід намагатися адаптувати робочий процес вашої команди до будь-якого з них, але реалізувати свої власні, створені відповідно до ваших потреб, які, якщо я добре розумію, - це гнучкість розвитку та швидке розгортання.

Я також думаю, що вам слід зосередитись на покращенні останніх. Як складається ваш трубопровід розгортання ? У " Постійній доставці: Надійне випуск програмного забезпечення за допомогою автоматизації побудови, тестування та розгортання " автори визначають можливі причини нечастого розгортання, деякі з яких:

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

Чи звучить хтось із них як щось, що ви могли б покращити? Можливо, ви могли б розповісти нам трохи більше про те, як ви та ваша команда поводиться з цією частиною проекту.