Porządkowanie bałaganu Git

Question

Właśnie odziedziczyłem projekt, który został utrzymany przy użyciu Git. W pewnym momencie kod został wdrożony na 3 oddzielnych systemach, a każdy system utrzymał zdecentralizowane repozytorium Git.

Każdy z 3 systemów rozszerzył oryginalny system bazowy w 3 różnych kierunkach. Żaden z 3 systemów nie został zsynchronizowany ze sobą. Niektóre zmiany są w gałęzi głównej, inne w nowych oddziałach.

Jak mogę przynieść 3 różnych źródeł ze sobą tak, że mogę:

1. znaleźć wspólną podstawę do pracy z;
2. dowiedzieć się, jakie zmiany stanowią poprawki błędów, które należy zastosować we wszystkich 3 systemach; i
3. utrzymywać 3 systemy w rozsądny sposób, tak aby istniała tylko jedna wspólna gałąź i oddzielne dostosowania wymagane dla 3 różnych systemów?

Answer 1

Najprawdopodobniej zacznę od wypychania wszystkich repozytoriów do oddzielnych oddziałów w centralnym repozytorium, z którego mogę łatwo dokonać reorganizacji, scalić itp. Między oddziałami.

Dobrym narzędziem do wizualizacji, takie jak git-age, gitnub, gitx, giggle może zdziałać cuda, ale twoim zadaniem będzie prawdopodobnie dość uciążliwe, chyba że można znaleźć punkty rozgałęzienia. Jeśli istnieją podobne poprawki zastosowane do wszystkich gałęzi, możesz użyć (interaktywny) rebase, aby zmienić kolejność zatwierdzeń, tak aby były w tej samej kolejności. Wtedy możesz zacząć "zipować" swoje gałęzie, przesuwając punkt rozgałęzienia w górę, wprowadzając commity do wzorca. Miły opis, jak zmienić kolejność zatwierdzeń przy użyciu rebase, można znaleźć pod adresem here.

Szanse są czynnościami, które należy podjąć, są opisane w linkach dostarczonych przez Git Howto Index. Dobry cheat sheet jest zawsze miło mieć w zasięgu ręki. Podejrzewam też, że śledzenie Eric Sinksa po wpisie "DVCS and DAGs, Part 1" będzie zawierało coś pożytecznego (nie było, ale było ciekawe przeczytanie).

Dodatkowe dobry-do-linki są: Git Magic, Git Ready i SourceMage Git Guide

Mam nadzieję, że wszyscy repo był dobry popełnić wiadomości, które mówią Ci cel każdego plastra, to takie lub przegląd kodu :)

Co do tego, w jaki sposób zachować dostosowywanie, mamy szczęście:

Rozpoczęliśmy od oddzielenia (lub zachowania osobnego) niestandardowego kodu od kodu ogólnego. Potem próbowaliśmy dwóch podejść; Oba, które działały poprawnie:

1. Wszystkie wdrożenia mają własne repozytoria, w których dostosowywano dane.
2. Wszystkie wdrożenia mają własną gałąź w repozytorium "dostosowywania".

Po pierwszym wdrożeniu i stwierdzeniu, że drugi był faktem, spędziliśmy trochę czasu próbując przewidzieć przyszłe dostosowania/punkty cięcia w celu ograniczenia powielania w dostosowanych repozytoriach (np. 1, którego używamy obecnie) oraz w repozytorium bazowym/jądro.

I tak, staramy byłaby niemiłosiernie, gdy zauważymy rdzeń/personalizacja rozstali poślizgiem :)

Answer 2

OK. Po wielkim sloganie udało mi się to zrobić. Dla nikogo innego wyruszeniem na podobnym zadaniem, będzie obejmować wiele:

git rebase

poleceń i kiedy sprawy się wkręca się:

git reflog

następnie

git reset --hard HEAD@{ref}