Робочий процес GIT для одного розробника (рухається від прямого FTP)

Я намагаюся вирішити, чи розумний перехід на VCS для мене. Я єдиний веб-розробник в невеликій організації (5 осіб). Я думаю про VCS (Git) з цих причин: контроль версій, резервне резервне копіювання на місці, централізоване сховище коду (можна отримати доступ з дому).

На даний момент я працюю на сервері в реальному часі. Я запускаю FTP, вношу свої зміни та зберігаю їх, після чого перезавантажуюсь та оновлююсь. Правки, як правило, стосуються тем / файлів плагінів для CMS (наприклад, concrete5 або Wordpress). Це добре працює, але не забезпечує резервного копіювання та контролю версій.

Мені цікаво, як найкраще інтегрувати VCS в цю процедуру. Я б задумав налаштувати Git-сервер на веб-сервері компанії, але мені незрозуміло, як підштовхнути зміни до облікових записів клієнтів (як правило, VPS на одному сервері) - на даний момент я просто входжу в SFTP з їх деталями і роблю зміни безпосередньо.

Я також не впевнений, що сприймало б репозиторій - чи отримає веб-сайт кожного клієнта свій власний?

Будь-яка інформація та досвід були б дуже корисними. Я не думаю, що мені потрібна вся потужність Git будь-якими способами, але базовий контроль версій та доступ до хмарного доступу фактично були б дуже корисними.

EDIT: Я звузив це до двох варіантів, які здаються найбільш розумними. Перша заснована на відповіді ZweiBlumen , згідно з якою правки вносяться на живий сервер і звідти передаються на (зовнішній) сервер Git. Це має перевагу в тому, що мій робочий процес не сильно зміниться (є додатковий крок внесення комісій, але в іншому випадку він ідентичний).

Другий варіант - це локальна робота за допомогою XAMPP, а потім внесення змін з локальної машини. Тільки коли веб-сайт виходить в реальному часі, я завантажую готову статтю на веб-сервер з локальної машини (відразу після остаточного зобов’язання Git). Теоретично це здається нормальним, але якщо сайт після цього вимагає внесення змін, і я вношу їх на живий сервер (як це зазвичай роблю), тоді мені потрібно буде вручну скопіювати змінені файли в моє місцеве репо, після чого зробити ці зміни в Git-сервер. Це здається надмірно складним і, можливо, занадто великим відхиленням від мого поточного робочого процесу.

Я думаю, що на балансі, я дам варіант №1, щоб перейти, і подивіться, як мені дістатися.

git version-control

— melat0nin
джерело

Що потрібно пам’ятати про git (або будь-який інший розподілений VCS), це те, що всі сховища є, принаймні технічно, однолітками: ваш локальний сховище настільки ж «справжній», як і той, що знаходиться на активному сервері або резервному сховищі. Це ваша структура робочих процесів дає їм структуру - тому, якщо ви дійсно хочете продовжувати виконувати основну роботу на сервері, що живе, ви можете ...

— comestorm

Дякую, це добре знати. Притаманна гнучкість Git ускладнює розробку «найкращої практики» вихідної точки - це сила з боку досвідченого користувача POV, але аргументована слабкість від noob's!

— melat0nin

Відповіді:

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

Я впевнений, що існують інші способи управління цим, але я вважаю це досить простим, і я перебуваю в абсолютно такій самій ситуації, як і ви: окремий розробник в невеликій організації (4 людини).

— ZweiBlumen
джерело

Спасибі за Вашу відповідь! Це означає, що ви переносите знімок на свою локальну машину, вносите і вносите зміни, а потім робите запит на витяг з живого сервера (за допомогою SSHing)? Що робити, якщо зміна дійсно невелика? Ви запускаєте локальний веб-сервер для розробки? (Я не міг пройти цей процес для простих змін у CSS. Я б з глузду зійшов!)

— melat0nin

Для незначної зміни CSS я би вніс зміни безпосередньо на сервер, а потім скопіював ці зміни у сховище з сервера. Коли мені доведеться зробити більш серйозну кількість роботи над сайтом, я б тоді оновив сайт на своїй машині розробки з останньою версією сайту із сховища. Я думаю, це не має особливого значення, де ви вносите зміни (сервер чи машина розробників) до тих пір, поки ви здійснюєте їх до сховища.

— ZweiBlumen

То які інструменти ви використовуєте для цього? FTP, щоб змінити файл безпосередньо на сервері, а потім відкрити сеанс SSH у фоновому режимі, щоб робити зобов’язання на сервері Git знову і знову?

— melat0nin

Так, це в основному все. Насправді я використовую Subversion. У нас є сайти в Windows, а також сервери Linux. У віддаленому робочому столі Windows I на них, змініть CSS і виконайте фіксацію за допомогою TortoiseSVN. У Linux я використовую сеанс SSH та vim для внесення змін (але, мабуть, ви також можете FTP зміни).

— ZweiBlumen

Я пішов із вашою пропозицією редагувати на сервері, а потім здійснювати звідти через SSH, що я роблю вже кілька днів. Здається, працює дуже добре, дякую!

— melat0nin

Досить легко створити post-updateгачок , який автоматично оновлює (експорт із git archiveкращим з міркувань безпеки) каталогу даних веб-сервера, коли ви переходите до певної гілки.

Тож десь встановіть сховище git (з міркувань безпеки я б розмістив його на іншому сервері, ніж в Інтернеті) з таким гаком. Звичайно, вам знадобиться тестовий сервер для перевірки великих змін, які можуть бути або на вашій локальній машині, або оновлені, натиснувши на іншу гілку. В будь-якому випадку ви можете обійти його для тривіальної орфографії та виправлень CSS, просто зробивши команду та натисніть.

— Ян Худець
джерело

Я б дотримувався цих кроків:

Налаштуйте віддалений сервер за допомогою належної пари відкритих / приватних ключів для віддаленого натискання / потягу
Налаштуйте тестування та випуск двох гілок
Розробити локально з тестовим середовищем у галузі тестування
Коли ви щасливі, зробіться з відділенням випуску та натисніть на віддалений сервер
Зачекайте на віддаленому сервері, щоб оновити до останньої версії випуску

Налаштуйте по одному репо на кожен веб-сайт, щоб вони не захаращували один одного. Окремі гілки дозволяють вам уникнути того, щоб поточний "хороший" варіант блокування перейшов до того, що ви зараз працюєте, яке може чи не може функціонувати.

— Спенсер Ратбун
джерело

Тож я правильно розумію - є два сервери (1) для Git, (2) живий веб-сервер та одна локальна машина розвитку. Dev робиться локально, а потім переноситься на сервер Git, який має гачок для оновлення живого сервера?

— melat0nin

@ melat0nin Це один із способів зробити це. Ви можете мати доступ до сервера в режимі реального часу з сервера git і як робота з кроном. Або ви можете мати 2 машини. Місцевий розробник і веб-сервер живого виробництва. Таким чином, натискання репо з машини розробників на виробничу машину оновлюється до новітньої гілки випуску кожного разу, коли ви натискаєте.

— Спенсер Ратбун