Jak zacząć używać Git do różnych baz kodu z różnych serwerów?

Kontekst: Niedawno odziedziczyłem zestaw projektów w mojej firmie i staram się rozwiązać kilka podstawowych problemów związanych z ich obsługą. Mianowicie, poprzedni programiści (którzy nie są już z firmą) nie używali żadnej formy kontroli źródła, tworzyli niewiele dokumentacji i tak naprawdę nie mieli dobrych procesów programistycznych.

Więc teraz mam trzy serwery projektów (programistyczne, inscenizacyjne, produkcyjne), które składają się głównie ze stron internetowych i aplikacji oraz narzędzi zbudowanych dla aplikacji innych firm i interfejsów API, których używamy, aż do sklepów skryptów SQL i innych rzeczy. Moją pierwszą myślą było wprowadzenie tego wszystkiego do Gita przed wprowadzeniem zmian i poprawek, ale trudno mi znaleźć najlepszy sposób, aby to zrobić.

Wiele wcześniejszych prac rozwojowych wykonano bezpośrednio na serwerach produkcyjnych, co spowodowało podział między bazą kodu każdego serwera. Nie jest od razu jasne, gdzie leżą wszystkie różnice - widzę poprawki błędów po stronie produkcyjnej, które nie są przenoszone na rozwój / etapowanie, a także nowe funkcje rozwoju, które nie zostały przeniesione na etapy / produkcję .

Pytanie: Jaki byłby najlepszy sposób, aby je uporządkować i przenieść do Git? Jak mam uporządkować moje repozytoria / oddziały, aby uwzględnić różnice w kodzie?

Rozważałem dalszy rozwój od klonowania kodu serwera produkcyjnego i utrzymywanie baz kodu programistycznego / testowego jako odniesienie historyczne. Czy byłby to na początek punkt, biorąc pod uwagę, że i tak nie wiem nic o kodzie deweloperskim / pomostowym? Mógłbym po prostu utworzyć repozytorium serwerów produkcyjnych dla każdej strony internetowej, narzędzia, zestawu skryptów itp., Stworzyć gałęzie dla istniejącego kodu deweloperskiego / pomostowego, a wszelkie nowe prace rozwojowe rozgałęziłyby się z bazy kodu serwera produkcyjnego. Czy to ma sens?

Wciśnij elementy produkcyjne do mastergałęzi nowego repozytorium. Utwórz z niego developgałąź, a następnie połącz z nią serwer pomostowy. Możesz skończyć z konfliktami, które należy rozwiązać. Raz te zostaną rozwiązane, tworzyć inny feature_branchod developi połączyć serwer deweloperski do niego. Rozwiąż wszelkie pojawiające się konflikty.

To daje ci 3 gałęzie, które reprezentują twoje środowisko produkcyjne, inscenizacyjne i programistyczne. Produkcja -> master, inscenizacja -> develop, rozwój -> feature_branch. Wszystkie prace rozwojowe są zatem wykonywane feature_branchesi łączone z developgałęzią tylko wtedy, gdy funkcja jest wykonywana, testowana i stabilna. Ponieważ jest stabilny, może być używany jako inscenizacja. Wytnij releasegałąź, developgdy będziesz gotowy do wypuszczenia, związaj luźne końce, połącz ją master, a następnie otrzymasz nową wersję produkcyjną.

Jednym z twoich pierwszych zamówień biznesowych po skonfigurowaniu powinno być scalenie z feature_branchpowrotem w develop*, a następnie z developpowrotem w master. Należy pamiętać, że feature_branchmogą zawierać kod niesprawdzone i funkcji, dlatego należy zachować ostrożność podczas łączenia go w developczym master. Po wykonaniu tej czynności wszystkie gałęzie powinny zawierać ten sam kod, a wszelkie prace rozwojowe na serwerze produkcyjnym są teraz przenoszone z powrotem na „serwer” programistyczny.

W tym modelu każdy projekt byłby w swoim repozytorium, a repo to miałoby gałąź masteri develop, plus feature_branchesza każdą wykonywaną pracę.

EDYCJA, aby odpowiedzieć na komentarze: Tak, to jest Gitflow.

Ta strategia (lub ogólnie Gitflow) utrzymuje istniejący system 3-poziomowy (produkcja, przemieszczanie, rozwój) z wyraźną ścieżką łączenia od rozwoju do produkcji. Importowanie baz kodów w ten sposób pozwala również na synchronizację gałęzi przy zachowaniu status quo w produkcji - przynajmniej do czasu przetestowania połączeń. Osiąga to kilka celów: kontroluje kod źródłowy, synchronizuje i łączy różne bazy kodowe (więc nie ma już poprawek błędów w produkcji, ale nie rozwija) i zapewnia przyjemny proces do wykorzystania w przyszłości (proces, który jest dobrze zdefiniowany i używane przez wiele osób / zespołów / firm). Jeśli PO stwierdzi, że Gitflow nie jest dobrze dostosowany do jego projektów / zespołów / firmy, gdy go używa / firma rozwija się, wówczas „

* Możesz wyciąć inną gałąź funkcji i usunąć wszelkie oczywiste nowe funkcje i scalić tę gałąź w develop(a następnie w master). Dzięki temu nie musisz testować nowych funkcji oprócz wszystkich innych testów, które będziesz wykonywać.

Mam zamiar polecić stagingkod jako najlepszą linię bazową dla pierwszego importu. To dlatego, że nie nastąpią zmiany production, które nie są staging, ze względu na hot fix, ale znacznie mniej, jeśli jakiekolwiek zmiany staging, które nie są production. Podobnie są zmiany development, których nie ma staging, ze względu na nowe funkcje, ale prawdopodobnie znacznie mniej, jeśli żadnych zmian w stagingnich nie ma development.

Uwaga: po początkowym imporcie nie chcesz stagingbyć punktem odniesienia. Jest to tylko sytuacja tymczasowa, ponieważ zmiany nie były wcześniej śledzone. Operacje rozgałęzień przebiegają znacznie płynniej, jeśli dodajesz zmiany zamiast je usuwasz. Po początkowym imporcie przejdź do dowolnego modelu rozgałęziania, który najlepiej odpowiada Twoim potrzebom.

Tak więc sprawdź stagingkod w staginggałęzi, a następnie zrób, git checkout -b master stagingaby utworzyć mastergałąź i sprawdź tam kod produkcyjny. Następnie zrób a, git checkout -b development stagingaby utworzyć swój developmentoddział i sprawdź tam swój kod programistyczny.

Teraz sprawdź swój developmentoddział i połącz master się z nim. Pozwoli ci to rozwiązać prawdopodobnie dużą liczbę konfliktów scalania, zachowując masterjednocześnie zapis tego, co faktycznie jest w produkcji. developmentteraz zawiera wszystkie zmiany z każdego środowiska. Możesz teraz przejść na model rozgałęzienia, który najbardziej Ci odpowiada.

Warto mieć historię. Utworzyłbym repozytorium (lub jedno dla każdego produktu) z najbardziej stabilnego środowiska. Twórz gałęzie lub pliki różnicowe dla innych.

Na wysokim poziomie:

1. Utwórz nowe repozytorium
2. Z produkcyjnej kopii roboczej: dodaj wszystko, zatwierdź i wypchnij
3. Kasa główna do nowego katalogu
4. Dla każdego dodatkowego środowiska XYZ
   1. Utwórz oddział Archive-XYZ
   2. Zamień wszystko na XYZsource (oprócz .git)
   3. dodaj wszystko, zatwierdz i wypchnij

Alternatywnie, jeśli jesteś sceptyczny co do jego wartości, git diff > XYZ.diffzamiast faktycznie zatwierdzać i wypychać i zarchiwizować pliki różnic.

Tak czy inaczej, powinieneś zakończyć się stanem, w którym możesz łatwo porównać kod działający w każdym środowisku, którego możesz użyć do ustalenia jednego punktu początkowego dla każdego projektu. A jeśli coś się zepsuje, teoretycznie będziesz w stanie porównać swoje zmiany z dowolnym z trzech środowisk.