Git/GitHub: fork, unione secondaria o sottomodulo per codice esterno?

Question

Mi piacerebbe incorporare un progetto esistente (ospitato su GitHub) come parte del mio progetto (in una sottodirectory) mantenendo la storia e la capacità di aggiornare quel progetto. Ho scoperto che non ci può essere di circa tre approcci:

1. Forcella il progetto originale, spostare il contenuto originale in una sottodirectory e spingerlo al mio repo GitHub.
2. Inizializzare un nuovo repository, creare un sottostruttura unire con il repository esistente e passare al repository GitHub.
3. Clona il repository esistente, crea un nuovo repository principale, inserisci il repository clonato in quello principale come sottomodulo , push.

La (1) variante potrebbe essere quella preferibile su GitHub in quanto possono probabilmente condividere le fonti. Ma logicamente il mio progetto non è un fork di quello esistente. Piuttosto quello esistente è solo un modulo. Inoltre non sono sicuro se spostare il codice esistente in una sottodirectory potrebbe non creare problemi. Probabilmente preferirei la (2) variante in quanto esiste un solo repository. (3) richiederebbe di lavorare con diversi repository ma logicamente è il più vicino alla mia situazione.

Ho studiato un bel po ', ma non ne sono sicuro. Cosa consiglieresti in questa situazione? Grazie in anticipo!

Answer 1

Se il ciclo di vita dello sviluppo dei due progetti (quello su GitHub e il tuo) è diverso, l'approccio del sottomodulo è migliore.
I.e: se si modifica il progetto senza modificare sistematicamente l'altro progetto GitHub, è necessario considerare l'approccio del sottomodulo.

Tuttavia, per implementare questo, si avrebbe bisogno di una combinazione di (1) e (3):

• se non si può contribuire (push) direttamente al progetto GitHub, è necessario forcella esso (1).
• quindi è necessario fare riferimento a quel progetto biforcuto come sottomodulo nel progetto (3).

Essa vi permetterà di consultare una revisione specifica del progetto GitHub, consentendo di aggiornare quel modulo e fare spinta specifica per esso (come descritto in "true nature of submodules").
Ma una volta aggiornato il sottomodulo, non dimenticate di impegnare il vostro progetto (che è il "progetto genitore" per il sottomodulo), al fine di registrare la nuova revisione del sottomodulo a cui state facendo ora riferimento.