Risolvere un pasticcio Git

Question

Ho appena ereditato un progetto che è stato mantenuto usando Git. A un certo punto, il codice è stato distribuito su 3 sistemi separati e ciascun sistema ha mantenuto il proprio repository Git decentralizzato.

Ciascuno dei 3 sistemi ha esteso il sistema di base originale in 3 direzioni diverse. Nessuno dei 3 sistemi è stato sincronizzato l'uno contro l'altro. Alcuni cambiamenti sono sul ramo principale, altri su nuovi rami.

Come posso riunire le 3 diverse fonti in modo da poter:

1. trova una base comune con cui lavorare;
2. scopri quali modifiche sono correzioni di bug che dovrebbero essere applicate su tutti e 3 i sistemi; e
3. mantenere i 3 sistemi in modo sano in modo che vi sia un solo ramo comune e separare le personalizzazioni richieste per i 3 diversi sistemi?

Answer 1

Probabilmente inizierei spingendo tutti i repository per separare i rami in un repository centrale, dal quale posso rifare facilmente, unire ecc. tra i rami facilmente.

Un buon strumento di visualizzazione come git-age , gitnub , gitx , giggle può fare miracoli, ma il tuo compito sarà probabilmente piuttosto noioso se non puoi trova i punti di ramificazione. Se sono presenti patch simili applicate a tutti i rami, è possibile utilizzare (interattivo) rebase per riordinare commetti in modo tale che siano nello stesso ordine. Quindi puoi iniziare a "zippare" i tuoi rami, spostando il punto in alto verso l'alto mettendo i commit in master. Una bella descrizione su come riordinare i commit usando rebase è disponibile qui .

Le probabilità che le azioni da intraprendere siano descritte nei collegamenti forniti da Git Howto Index . Un buon cheat sheet è sempre bello avere a portata di mano. Inoltre, sospetto che il follow-up al post di Eric Sinks " DVCS e DAG, Parte 1 " conterrà qualcosa di utile (non è così, ma è stata comunque una lettura interessante).

Ulteriori link utili sono: Git Magic , Git Ready e Guida di SourceMage Git

Spero che tutti i repository avessero buoni messaggi di commit che ti dicessero lo scopo di ogni patch, è quello o la revisione del codice :)

Per quanto riguarda come mantenere le personalizzazioni abbiamo avuto fortuna con quanto segue:

Abbiamo iniziato separando (o mantenendo separato) il codice personalizzato dal codice generico. Quindi abbiamo provato due approcci; entrambi hanno funzionato bene:

1. Tutte le distribuzioni hanno i propri repository in cui è stata mantenuta la personalizzazione.
2. Tutte le distribuzioni hanno il proprio ramo in un repository "personalizzazione".

Dopo il primo schieramento e visto che il secondo era un dato di fatto, abbiamo trascorso un po 'di tempo a cercare di prevedere future personalizzazioni / punti di taglio per ridurre la duplicazione tra i repository personalizzati (alt. 1, che è l'approccio attualmente in uso) e nel base / core repo.

E sì, proviamo a riformulare senza pietà ogni volta che notiamo lo slittamento del core / personalizzazione :)

Answer 2

OK. Dopo un grosso slog, sono riuscito a farlo. Per chiunque intraprenda un compito simile, coinvolgerà molto:

git rebase

comandi e quando le cose sono state rovinate:

git reflog

seguito da

git reset --hard HEAD@{ref}