Правильне використання git у невеликій команді

14

Що було б найпростішим способом правильно використовувати git у невеликій команді з близько 5 розробників, на одному сервері працює жива програма?

version-control git

— ОНОЗ
джерело

5

Я б хотів поставити під сумнів використання git у цьому випадку. Немає переваги для використання децентралізованого управління джерелами, коли у вас є всі люди в одній кімнаті з одним виділеним сервером. А ще є накладні витрати на потягнення / натискання на вершину комітетів.

— Ейфорія

10

@Euphoric залежить від ваших інструментів та робочого процесу.

3

@ONOZ, будь ласка, опишіть свій сучасний спосіб роботи більш докладно.

22

@Euphoric - Яке неймовірно вузьке ставлення. Для зручності розгалуження і злиття поодинці gitабо hgб'є більшість централізованих СКС. Я можу зрозуміти, що люди дратують людей, які постійно мучать про те, наскільки великі DVCS, але закопувати голову в пісок і відмовлятися визнавати, що ти можеш розвивати різні та, можливо, більш ефективні робочі процеси з DVCS, ніж без одного, так само погано.

— Марк Бут

8

@Euphoric, використання Git не означає, що ваш контроль над джерелом "децентралізований". Я працюю в невеликій команді, і ми використовуємо Git, і у нас все ще є центральне сховище. Це те, на що ти підштовхуєш. Використання DVCS зазвичай не означає, що кожна людина відтягується від кожної іншої людини без центральної точки.

— Kyralessa

11

Я пропоную вам створити якусь галузь:

виробництво
майстер
місцеві

Виробнича галузь - це "жива" галузь. Чи використовується програма зараз.

Коли потрібне оновлення, розробник може перетягнути головну гілку в локальну гілку. Тоді, можна почати кодувати. Зрештою, просто потягніть та натисніть з локальної гілки розробника на майстер. Керівник проекту може заглянути в головну галузь. Перевірте це. А коли буде готово, можна злити виробництво з майстром. А тепер у вас буде нове програмне забезпечення.

— sensorario
джерело

Якщо ви знаходитесь в консалтинговій або корпоративній ситуації, ви також можете мати відділення для UAT.

— Джон Макінтайр

Погодьтеся, я використовую цей робочий потік.

— Cheung

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

— Люк

1

Через те, що локальну гілку можна назвати як XXX-особливість-ім'я, таким чином, у вас є головна гілка як об'єднання всіх функціональних гілок, які ви хочете у виробництві. Так: оскільки якась функція може бути не включена.

— sensorario

7

Почніть просто і створюйте складніший робочий процес як і коли потрібно.

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

Я б запропонував вам почати з центрального gitсховища і мати всіх, включаючи ваш клон виробництва та тестування.

У своєму сховищі git створіть productionгілку та testгілку.

Розробники повинні працювати у власних локальних або віддалених відділеннях функцій, поки вони не будуть завершені та об'єднані master. Звідси вони можуть бути об'єднані у testгілку для розгортання у тестовому середовищі, а після проходження тестів вони можуть бути об'єднані у productionгілку.

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

— Марк Бут
джерело

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

— wirrbel

@wirrbel Там немає таких речей , як в мерзотникові розгалуження моделі, ви можете реалізувати будь-який розгалуження моделі ви бажаєте , використовуючи gitвідповідно робочого процес. Я пропоную тут простий і, ймовірно, буде кращим для недосвідчених gitкористувачів, ніж Успішна модель розгалуження Git, але AsGbm, ймовірно, буде кращою для більш досвідчених gitкористувачів, але не настільки підходить для деяких команд (люди, які хочуть підтримувати кілька релізів гілки, наприклад). Як я вже казав, проблема AsGbm полягає в тому, що він може виглядати надмірно складним.

— Марк Бут

Я бачу вашу думку. Тільки для мене я почав з AsGbm (а точніше - адаптував його до моїх потреб). Це було ідеально, оскільки я міг бачити, як git можна використовувати інакше, ніж svn

— wirrbel

7

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

— Віатт Барнетт
джерело

Я також використовував це для створення розгалужених моделей за останні кілька років. Це фантастична модель.

— Джон Макінтайр

Великі пальці для посилання

— Рахул Гаутам

0

У вас повинен бути один головний сховище на сервері інтеграції, і кожен розробник повинен його клонувати. Після цього просто робіть потягування і натискання. Розробка нових великих можливостей в окремій галузі. Тут немає ніякої ракетної науки. На живому сервері - ви також повинні клонувати головне сховище. І це гарна практика мати галузь на зразок "живої" для неї.

— Миколи Фоминих
джерело

2

git archive - це ще одна можливість розгортання на живому сервері за умови, що ви насправді не хочете безпосередньо редагувати матеріали на живому сервері

— jk.