Cosa dovrei includere nel mio archivio dai progetti IDE

10

Voglio aggiungere un progetto che in questo caso viene creato in Netbeans ma questa domanda è generale per la maggior parte degli IDE. È semplicemente, cosa dovrei includere nel mio repository. Ad esempio Netbeans crea una cartella nbproject, eclipse crea una cartella .settings ecc. Dovrei includerli nel mio repository, quali sono i vantaggi / gli svantaggi di includere o meno le impostazioni specifiche del progetto.

In questo caso è un progetto personale, quindi non immagino che altre persone inizieranno a lavorarci, ma sarebbe bello aggiungere il minimo indispensabile delle impostazioni del progetto in modo che il progetto stesso possa iniziare facilmente a lavorare su macchine diverse.

— Daniel Figueroa
fonte

Prendi in considerazione strumenti come Maven con il suo plug-in eclipse (o altro ide) per impostare l'ambiente corretto anziché includere il tuo.

@MichaelT Mi dispiace molto ma non lo seguo davvero, ti dispiacerebbe espanderti?

— Daniel Figueroa,

L'uso di uno strumento di compilazione e la configurazione dell'ambiente per l'ide ti consente di essere certo che l'installazione è la stessa indipendentemente dalla piattaforma (o ide). Anche gli sviluppatori solisti hanno ambienti multipli (ide vs build). Questo semplifica la domanda a chi riceve una risposta "non archiviare nulla di specifico per il proprio ambiente perché sono generati da codice". - lo stesso razionale che non si controlla nelle classi .java generate da jaxb, ma piuttosto dalle istruzioni (file build.xml o .pom) su come costruirle.

Se è "originale" è necessario eseguire il backup. Se cambia e quelli hanno bisogno di tracciamento ed è originale, dovrebbe essere controllato dalla revisione. Il trucco: come strutturare il repository in modo che l'origine rimanga l'origine, mentre le configurazioni della catena di strumenti non inquinano il repository di origine. Lo stesso vale per risorse come immagini, suoni e video ....

— mattnz,

4

Dipende davvero da quali dati sono e dovrebbero essere decisi caso per caso, forse anche per singoli file. Dai un'occhiata al contenuto di questi file. Molto spesso puoi dire cosa significano. Cose come la posizione e le dimensioni delle finestre dell'IDE sono qualcosa che non si desidera nel controllo del codice sorgente.

Ma alcuni dei file di progetto IDE sono metadati di progetto vitali. Non conosco bene Netbeans, ma per eclipse, il file .project dice all'IDE come si chiama il progetto, che è un progetto Web Java, ecc. E il file .classpath contiene informazioni sulle cartelle e le librerie di origine. Alcuni file nella directory .settings possono essere altrettanto importanti, ad esempio org.eclipse.core.resources.prefs contiene informazioni su quale codifica dovrebbe essere usata per quali file.

Come metadati del progetto, questa roba merita moltissimo di essere aggiornata nel controllo del codice sorgente.

Alcuni IDE possono importare metadati di progetto da altri IDE. Sarebbe anche meglio averlo in una forma che non è legata a un IDE specifico.

Per Java esiste una cosa del genere: Maven . Impone convenzioni forti sulla struttura del progetto e consente di specificare i metadati del progetto (come le dipendenze della libreria) in un punto (un file chiamato pom.xml che si trova nella directory principale del progetto e, ovviamente, nel controllo del codice sorgente). Esistono plugin che creano file di progetto IDE dalla configurazione Maven e altri che possono automatizzare il processo di creazione del progetto o fare qualsiasi cosa. A volte sembra che renda le cose inutilmente complesse e ci vuole del tempo per imparare, ma i benefici ne valgono la pena.

— Michael Borgwardt
fonte

1

se non sbaglio, Maven è indipendente dall'IDE. In tal caso, quindi, poiché contiene le impostazioni / i metadati dei progetti, pertanto dovrebbe sicuramente includere nel repository, ma non i "file di progetto IDE" a cui OP sembra riferirsi in modo specifico.

— Bleeding Fingers,

@ hus787: il mio punto è che questi metadati sono abbastanza importanti per essere nel repository, e mentre è fantastico quando lo hai in una forma indipendente dall'IDE, quando non è così è ancora meglio averlo che non farlo averlo.

— Michael Borgwardt,

2

Questo dipende davvero dal tipo di informazioni che vorresti avere sul repository. Se vuoi tutto fino ai file che avevi aperto e che stavi modificando al momento del commit e sei l'unico ad usare il repository, vai avanti e commetti tutto, ma sappi che potrebbe non funzionare su un altro computer .

Se vuoi essere in grado di condividere il tuo codice con altre persone che potrebbero non utilizzare lo stesso IDE, quindi esegui il commit del codice stesso senza alcuna implementazione specifica del progetto.

Se sai che tutti usano lo stesso IDE, allora puoi probabilmente includere qualsiasi cosa che non sia specifica per il computer, ovvero qualsiasi file / cartella di impostazione solo per l'IDE stesso, in questo modo possono già avere la possibilità di importare il progetto come IDE se lo aspetta.

— AMPT
fonte

2

Non dovrebbero essere inclusi artefatti che aiutano il tuo sviluppo e non sono utili alla compilazione / rilascio o al progetto stesso . Il repository dovrebbe essere pulito e ordinato e contenere solo le cose rilevanti per il progetto e non l'ambiente . Il repository dovrebbe essere incognito delle tue abitudini. E in secondo luogo ti guiderà inutilmente quando fai qualcosa di simile a ... ma hey non ho mai fatto cambiamenti ... ahh ignoralo.git status

Lasciami fare un esempio più pratico (lo userò gitqui come strumento):

Non vorrai mai un sottomodulo (ricorsivo) all'interno del tuo repository principale per avere un materiale specifico IDE (potrebbe interferire anche con l'ambiente di progetto principale) perché tutto ciò che ti interessa è il codice che è stato scritto da qualcun altro (o da te) ed è di utilizzo all'interno del progetto attuale. Non l'ambiente in cui è stato sviluppato. Probabilmente non vorrai farlo neanche a qualcun altro.

Per poter utilizzare le tue impostazioni su macchine diverse, ti suggerisco di scavare all'interno del tuo IDE e vedere quale supporto fornisce per tali cose. Emacs ha inite anche il server Emacs. Oppure potresti creare la tua macro o script personalizzati ( .sh) che esegue automaticamente l'installazione.

— Dita sanguinanti
fonte

-1: non sono completamente d'accordo. Queste possono essere informazioni molto importanti e utili e il tuo repository dovrebbe sicuramente includere tali informazioni.

— Michael Borgwardt,

@MichaelBorgwardt cosa succederebbe se in seguito OP pianificasse di passare a qualche altro IDE. Come verranno comprese le impostazioni specifiche dell'IDE del progetto nell'altra? Un esempio sarebbe molto apprezzato.

— Bleeding Fingers,

Alcuni IDE possono importare metadati di progetto da altri IDE. Anche se non ci riescono, questi file sono in genere leggibili dall'uomo e averlo è meglio che non averlo.

— Michael Borgwardt,

E cosa succede se perdi completamente lo spazio di lavoro (mi è successo di recente) e non riesci a invertire le modifiche impostando manualmente le cose come pensavi che fossero prima? Probabilmente mi sono risparmiato ore perché lo spazio di lavoro è stato archiviato. Per non parlare del fatto che in alcuni IDE lo spazio di lavoro includerà elementi come i modelli di codice che sarebbe un problema doveroso impostare manualmente ogni volta.

— Amy Blankenship,

@AmyBlankenship questo è il mio punto, è il tuo spazio di lavoro, come puoi essere sicuro che non interferisca con quello degli altri (tirano e all'improvviso il loro spazio di lavoro viene sostituito da quello del tuo), è meglio tenere quelle cose in un ramo locale separato o potresti usare mercurial per il tuo spazio di lavoro specifico del progetto VC e git per il progetto VC. Per quanto riguarda i modelli di codice, penso che il tuo IDE non sia abbastanza maturo (o non sia stato ancora esplorato correttamente) e se dici che i modelli sono specifici del progetto, suppongo che dovresti cercare modelli nel tuo codice.

— Bleeding Fingers,

1

Se è un progetto personale, dico memorizzare le impostazioni nel controllo del codice sorgente. Personalmente, nulla uccide la mia motivazione più per un progetto che creare di nuovo un ambiente di sviluppo.

Quando sono coinvolte più persone, non metto queste cose nel controllo del codice sorgente. Nel mio team, abbiamo in uso un mix di IntelliJ, Sublime Text ed Eclipse. I file IDE aggiungono solo disordine e comportano il pull in commit di quei file da altre persone per un IDE che non usi.

Inoltre, il tuo progetto non dovrebbe dipendere comunque dall'IDE. Un server di build non avvierà Eclipse per compilare il tuo prodotto, quindi dovrebbe già essere privo di IDE. Un punto più secondario: elimina l'organizzazione personale all'interno del progetto. Ad esempio, in IntelliJ mi piace usare molti moduli all'interno del nostro progetto. Nessun altro che utilizza IntelliJ se ne preoccupa perché non memorizziamo i file .iml (modulo).

Se la tua squadra sta usando lo stesso IDE, allora è meglio, ma qualcuno commette una voce .classpath errata perché ha usato un percorso assoluto. Ora tutti quelli che usano l'IDE se ne preoccupano.

Certo, il rovescio della medaglia è che c'è più installazione quando qualcuno controlla il progetto. Penso che ne valga la pena. Usiamo Ivy per la gestione delle dipendenze e disponiamo di informazioni su configurazione, dipendenze, ecc. Nonostante questo costo iniziale, penso che valga la pena mantenere le impostazioni IDE fuori dal controllo del codice sorgente.

— Kryptic
fonte