Qual è la migliore pratica con git per implementazioni di più lingue?

Question

Quindi ho alcuni repository git privati ​​che sono implementazioni linguistiche diverse (Python, Java, ecc.) Di un algoritmo. Ogni implementazione è funzionalmente identica, esegue gli stessi passaggi e fornisce lo stesso risultato. Attualmente, questi sono pronti contro termine separati, ma mi chiedevo se non li dovrei unificare in un unico repository, con le directory che indica il linguaggio, come:

master 
    - java 
    - python 
    - ruby 

ho potuto utilizzare un git-repo combinare comando per preservare la storia , quindi non è un problema. Ero solo curioso di sapere come fare al meglio.

Answer 1

Ho avuto questa stessa domanda con Mercurial e un algoritmo (COBS) che volevo implementare in C e Python.

Alla fine ho deciso di dividerlo in repository separati (anche se l'implementazione di Python includeva un'estensione C con codice simile all'implementazione C semplice). Il mio ragionamento è stato il seguente:

• Volevo disporre della numerazione delle versioni indipendente delle implementazioni e delle versioni indipendenti.
  • git describe è una funzionalità utile per identificare una versione basata sull'ultimo tag annotato. Con una sola implementazione nel repository, l'utilizzo di git describe è semplice. Tuttavia, se diverse implementazioni con numeri di versione separati si trovano nell'unico repository, l'utilizzo di git describe diventa più complicato, richiedendo l'utilizzo dell'opzione --match per limitare i tag con un prefisso specificato. per esempio. git describe --match "python*" moduli Python
• Il modo vengono generalmente organizzati (Python module packaging best-practices), ha reso più senso per me per mantenere l'implementazione di Python separata e indipendente.
• A parità di tutti gli altri, tendo a favorire una modularità più fine.

Answer 2

È una chiamata difficile. Probabilmente ciò che è "il migliore" si ridurrà alle preferenze personali e/o alle specifiche delle circostanze.

Da un lato, ogni directory non è tecnicamente "correlata" a nessun altro. Mentre implementano lo stesso algoritmo, nessuno dipende da nessuno degli altri (quindi da un punto di vista del codice sorgente puro, non sono correlati). Di solito, le cose non correlate sono meglio lasciate in repository separati (per ragioni identificate nella risposta di Craig McQueen).

Tuttavia, poiché lo do implementa lo stesso algoritmo, è possibile che, se è necessario modificare l'algoritmo, è necessario apportare modifiche molto simili a tutte le directory. In tal caso, è possibile che abbia senso eseguire tutte le modifiche come un singolo commit. Supponiamo che tu decida che l'algoritmo deve supportare "dinglehop virtuali". Dovresti aggiungere il supporto a ciascuna directory e creare un singolo commit il cui messaggio è "Aggiungi supporto per dinglehopper virtuali". Questo è bello perché se in seguito decidi che l'aggiunta del supporto virtuale per il dinglehopper era errata, ora puoi ripristinare solo un singolo commit. L'alternativa consiste nel fare tre commit separati in tre repository separati e quindi ripristinare tre commit separati da tre repository separati.

Ancora una volta, è una chiamata difficile. Non penso che ci sia una regola chiara, dura e veloce da seguire.