Przepływ pracy GIT dla jednego dewelopera (przejście z prostego FTP)

Próbuję zdecydować, czy przejście na VCS jest dla mnie sensowne. Jestem programistą internetowym w małej organizacji (5 osób). Myślę o VCS (Git) z następujących powodów: kontrola wersji, tworzenie kopii zapasowych poza siedzibą, scentralizowane repozytorium kodów (dostęp z domu).

W tej chwili ogólnie pracuję na serwerze na żywo. Przesyłam FTP, wprowadzam zmiany i zapisuję je, a następnie ponownie ładuję i odświeżam. Zmiany dotyczą zwykle plików motywów / wtyczek dla CMS (np. Concrete5 lub Wordpress). Działa to dobrze, ale nie zapewnia tworzenia kopii zapasowych i kontroli wersji.

Zastanawiam się, jak najlepiej zintegrować VCS z tą procedurą. Chciałbym założyć serwer Git na serwerze internetowym firmy, ale nie jestem pewien, jak wypchnąć zmiany do kont klientów (zwykle VPS na tym samym serwerze) - w tej chwili po prostu loguję się do SFTP z ich danymi i robię zmiany bezpośrednio.

Nie jestem również pewien, co rozsądnie reprezentowałoby repozytorium - czy strona internetowa każdego klienta otrzyma własną?

Wszelkie spostrzeżenia lub doświadczenia byłyby naprawdę pomocne. Nie sądzę, że potrzebuję pełnej mocy Git w jakikolwiek sposób, ale podstawowa kontrola wersji i de facto dostęp do chmury byłyby naprawdę przydatne.

EDYCJA: zawęziłem to do dwóch opcji, które wydają się najbardziej rozsądne. Pierwszy opiera się na odpowiedzi ZweiBlumen , w której zmiany są dokonywane na serwerze na żywo i stamtąd przekazywane do (zewnętrznego) serwera Git. Ma to tę zaletę, że mój przepływ pracy niewiele się zmieni (jest dodatkowy etap dokonywania zatwierdzeń, ale poza tym jest identyczny).

Drugą opcją jest lokalna praca za pomocą XAMPP, a następnie zatwierdzanie zmian z lokalnego komputera. Dopiero po uruchomieniu witryny przesyłam gotowy artykuł na serwer internetowy z lokalnego komputera (natychmiast po ostatecznym zatwierdzeniu do Git). Teoretycznie wydaje się to w porządku, ale jeśli później witryna wymaga poprawek i robię je na serwerze na żywo (jak zwykle), muszę ręcznie skopiować zmienione pliki w moim lokalnym repozytorium, a następnie zatwierdzić te zmiany w Serwer Git. Wydaje się to nadmiernie skomplikowane i być może jest to zbyt odejście od mojego obecnego przepływu pracy.

Myślę, że w sumie dam opcję nr 1 i zobaczę, jak sobie radzę.

To, co robię (z Subversion, ale będzie działać również z Gitem), to przypisywanie wszystkiego do jednego repozytorium Subversion, ale oczywiście podział na projekty, gałęzie, tagi, jeśli to konieczne. Następnie kasuję te repozytoria na serwer na żywo. Dlatego kiedy dokonuję zmiany na moim komputerze deweloperskim i przesyłam ją do repozytorium, często jest to po prostu aktualizacja zaktualizowanej kopii na serwerze na żywo, aby zmiany zostały wprowadzone w życie. Dodatkową zaletą jest to, że jeśli muszę dokonać szybkiej poprawki na serwerze na żywo, przesyłam to do repozytorium z serwera i aktualizuję kopię roboczą na moim komputerze programistycznym.

Jestem pewien, że istnieją inne sposoby zarządzania tym, ale uważam to za dość proste i jestem w dokładnie takiej samej sytuacji jak Ty: pojedynczy programista w małej organizacji (4 osoby).

Łatwo jest utworzyć post-updatezaczep , który automatycznie aktualizuje (z git archivepowodów bezpieczeństwa preferowany jest eksport ) katalog danych serwera WWW po przejściu do określonej gałęzi.

Więc skonfiguruj gdzieś repozytorium git (ze względów bezpieczeństwa umieściłbym je na innym serwerze niż w sieci) z takim hakiem. Będziesz oczywiście potrzebował serwera testowego do testowania większych zmian, które mogą być albo na twoim komputerze lokalnym, albo zaktualizowane przez przeniesienie do innej gałęzi. W obu przypadkach można go ominąć w przypadku trywialnej pisowni i poprawek CSS, po prostu wykonując zatwierdzenie i wypchnięcie.

Wykonałbym następujące kroki:

1. Skonfiguruj serwer zdalny z odpowiednią parą kluczy publiczny / prywatny do zdalnego push / pull
2. Skonfiguruj dwa oddziały testowania i wydania
3. Rozwijaj lokalnie za pomocą środowiska testowego w branży testowej
4. Gdy będziesz zadowolony, połącz się z gałęzią wydania i wypchnij serwer zdalny
5. Zaczep na zdalnym serwerze, aby zaktualizować do najnowszej wersji wydania

Skonfiguruj po jednym repozytorium na stronę internetową, aby się nie zaśmiecały. Oddzielne gałęzie pozwalają uniknąć blokowania bieżącej blokady „dobrej” wersji do tego, nad czym aktualnie pracujesz, co może, ale nie musi, działać.