Cosa dovrei includere nel mio repository dai progetti IDE

Dipende davvero da quali dati è e dovrebbe essere deciso caso per caso, forse anche per singoli file. Dai un'occhiata al contenuto di quei file. Più spesso che non puoi dire cosa significano. Roba come la posizione e la dimensione delle finestre dell'IDE è qualcosa che non vuoi 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 qual è il nome del progetto, che si tratta di 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 ugualmente importanti, ad es. org.eclipse.core.resources.prefs contiene informazioni su quale codifica deve essere utilizzata per quali file.

Come metadati del progetto, questa roba merita molto di essere versionata nel controllo del codice sorgente.

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

Per Java, esiste una cosa del genere: Maven . Impone forti convenzioni 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 di Maven e altri che possono automatizzare il processo di creazione del progetto o fare qualsiasi cosa. A volte sembra che le cose rendano le cose inutilmente complesse e ci vuole un po 'di tempo per imparare, ma i benefici in genere valgono la pena.

Artefatti che aiutano il tuo sviluppo e non sono di alcuna utilità per la build / release o il progetto stesso dovrebbe non essere incluso. Il repository dovrebbe essere pulito e in ordine e avere solo le cose che sono rilevanti per il progetto, non il tuo ambiente . Il repository dovrebbe essere incognito delle tue abitudini. E in secondo luogo ti infastidirà inutilmente quando fai qualcosa di simile a git status ... ma hey non ho mai fatto nessuna modifica ... ahh ignora questo.

Consentitemi di dare un esempio più pratico (userò git qui come strumento):

Non vorresti mai un sottomodulo (ricorsivo) all'interno del tuo repository principale per avere un materiale specifico IDE (potrebbe interferire con l'ambiente di progetto principale) perché tutto quello che ti interessa è il codice che è stato scritto da qualcun altro (o tu ) ed è utile all'interno del progetto corrente. Non l'ambiente in cui è stato sviluppato. Probabilmente non vuoi farlo anche a qualcun altro.

Per poter utilizzare le tue impostazioni su una macchina diversa, ti suggerisco di scavare all'interno del tuo IDE e vedere quale supporto fornisce per queste cose. Emacs ha anche init e anche il server Emacs. Oppure puoi creare la tua macro o script personalizzato ( .sh ) che esegue automaticamente l'installazione.

Questo dipende molto 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'altra macchina .

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

Se sai che tutti usano lo stesso IDE, allora puoi probabilmente includere tutto ciò che non è specifico del computer, cioè qualsiasi file / cartella di impostazione solo per l'IDE stesso, in questo modo possono già avere la possibilità di importare progetto come l'IDE si aspetta.

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

Quando più persone sono coinvolte, non metto queste cose nel controllo del codice sorgente. Nel mio team, abbiamo utilizzato un mix di IntelliJ, Sublime Text ed Eclipse. I file IDE aggiungono solo ingombro, e portano a inserire i commit di quei file da altre persone per un IDE che non usi.

Inoltre, il tuo progetto non dovrebbe comunque dipendere dall'IDE. Un server di compilazione non eseguirà il riavvio di Eclipse per compilare il prodotto, quindi dovrebbe già essere privo di IDE. Un punto più piccolo: elimina l'organizzazione personale all'interno del progetto. Ad esempio, in IntelliJ mi piace utilizzare molti moduli all'interno del nostro progetto. Nessun altro usa IntelliJ a preoccuparsi di questo perché non memorizziamo i file .iml (modulo).

Se la tua squadra usa lo stesso IDE, allora è meglio, ma qualcuno commette una cattiva .classpath perché hanno usato un percorso assoluto. Ora tutti quelli che usano l'IDE si preoccupano di ciò.

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