Cosa mettere sotto controllo di versione?

Quasi tutti gli IDE creano molti file che non hanno nulla a che fare con l’applicazione in fase di sviluppo, sono generati e mantenuti dall’IDE, così lui sa come compilare l’applicazione, dove si trova il repository di controllo della versione e così via.

Questi file dovrebbero essere tenuti sotto controllo di versione insieme ai file che hanno davvero qualcosa a che fare con l’applicazione (codice sorgente, file di configurazione dell’applicazione, …)?

Il problema è: su alcuni IDE se si crea un nuovo progetto e quindi lo si importa nel repository di controllo versione utilizzando il client / comandi di controllo versione incorporato nell’IDE, quindi tutti questi file vengono inviati al respitory. E non sono sicuro che sia giusto: quali sono i due diversi sviluppatori che lavorano sullo stesso progetto vogliono utilizzare due IDE diversi?


Voglio mantenere questa domanda agnostica evitando riferimenti a qualsiasi IDE particolare, linguaggio di programmazione o sistema di controllo della versione. Quindi questa domanda non è esattamente la stessa di questi:

  • SVN e binari – ma questo parla di binari e SVN
  • Mantieni gli strumenti di compilazione nel controllo della versione? – ma questo parla di strumenti di compilazione (es. mettendo jdk sotto controllo di versione)
  • Quali file di progetto non dovrebbero essere controllati in SVN – ma questo parla di SVN e di dll
  • Mantieni i tuoi file di progetto sotto controllo di versione? – molto simile (non l’ho trovato prima), grazie VonC

    Regole empiriche:

    1. Includere tutto ciò che ha influenza sul risultato della compilazione (opzioni del compilatore, codifiche dei file, impostazioni ASCII / binarie, ecc.)
    2. Includere tutto per rendere ansible l’apertura del progetto da un checkout pulito e la possibilità di compilare / eseguire / testare / eseguire il debug / distribuirlo senza ulteriori interventi manuali
    3. Non includere file che contengono percorsi assoluti
    4. Evitare di includere le preferenze personali (dimensioni della linguetta, colors, posizioni delle windows)

    Segui le regole in questo ordine.

    [Aggiornamento] C’è sempre la domanda che cosa dovrebbe accadere con il codice generato. Come regola generale, metto sempre quelli sotto controllo di versione. Come sempre, prendi questa regola con un granello di sale.

    Le mie ragioni:

    Il codice generato dal controllo delle versioni sembra una perdita di tempo. È generato giusto? Posso recuperarlo premendo un pulsante!

    Veramente?

    Se dovessi mordere il proiettile e generare la stessa identica versione di alcune versioni precedenti senza esito negativo, quanto sarebbe? Quando generi codice, non solo devi ottenere tutti i file di input corretti, devi anche tornare indietro nel tempo per il generatore di codice stesso. Puoi farlo? Sempre? Facile come sarebbe controllare una certa versione del codice generato se lo avessi messo sotto controllo di versione?

    E anche se potessi, potresti mai essere sicuro di non aver perso qualcosa?

    Quindi, da un lato, mettere il codice generato sotto il controllo della versione ha senso dal momento che rende praticamente imansible fare ciò che si intende per VCS: tornare indietro nel tempo.

    Inoltre rende facile vedere le differenze. Anche i generatori di codice sono bacati. Se risolvo un bug e ho generato 150.000 file, è molto utile poterli confrontare con la versione precedente per vedere che a) il bug è sparito eb) nient’altro è cambiato in modo imprevisto. È la parte inaspettata di cui dovresti preoccuparti. Se non lo fai, fammelo sapere e mi assicurerò che non lavori mai per la mia azienda mai 🙂

    Il principale punto dolente dei generatori di codice è la stabilità. Non funziona quando il tuo generatore di codice sputa solo un pasticcio casuale di byte ogni volta che lo fai (beh, a meno che non ti interessi della qualità). I generatori di codice devono essere stabili e deterministici . Li esegui due volte con lo stesso input e l’output deve essere identico fino al bit meno significativo.

    Quindi, se non riesci a controllare il codice generato perché ogni esecuzione del generatore crea differenze che non ci sono, allora il tuo generatore di codice ha un bug. Aggiustalo. Ordina il codice quando devi. Utilizza le mappe hash che preservano l’ordine. Fai tutto il necessario per rendere l’output non casuale. Proprio come fai ovunque nel tuo codice.

    Il codice generato che non potrei mettere sotto controllo di versione sarebbe la documentazione. La documentazione è in qualche modo un objective morbido. Non importa quando rigenera la versione sbagliata dei documenti (per esempio, ha alcuni errori di battitura più o meno). Ma per le versioni, potrei farlo comunque in modo da poter vedere le differenze tra le versioni. Potrebbe essere utile, ad esempio, per assicurarsi che le note di rilascio siano complete.

    Inoltre non controllo i file JAR. Dato che ho il pieno controllo dell’intera costruzione e la piena certezza di poter recuperare qualsiasi versione delle sorgenti in un minuto, so che ho tutto il necessario per costruirlo senza ulteriori interventi manuali , perché avrei bisogno degli eseguibili per ? Anche in questo caso, potrebbe essere sensato inserirli in un repository di rilascio speciale, ma in tal caso, è meglio conservare una copia degli ultimi tre anni sul server Web della propria azienda da scaricare. Pensa: confrontare i binari è difficile e non ti dice molto.

    Penso che sia meglio mettere sotto controllo di versione che aiuti gli sviluppatori a iniziare rapidamente, ignorando tutto ciò che può essere generato automaticamente da un IDE o strumenti di costruzione (ad esempio il plugin Eclipse di Maven genera .project e .classpath – non c’è bisogno di controllarli in ). Evitare specialmente i file che cambiano spesso, che non contengono nient’altro che le preferenze dell’utente, o quel conflitto tra IDE (es. Un altro IDE che usa .project proprio come fa Eclipse).

    Per gli utenti di eclipse, trovo particolarmente utile aggiungere lo stile del codice (.settings / org.eclipse.jdt.core.prefs – formattazione automatica al salvataggio triggersto) per ottenere un codice formattato in modo coerente.

    Tutto ciò che può essere generato automaticamente dai file di configurazione + sorgente non dovrebbe essere sotto il controllo della versione! Causa solo problemi e limitazioni (come quello che hai affermato – utilizzando 2 diversi file di progetto da diversi programmatori).

    È vero non solo per i “file spazzatura” IDE ma anche per i file intermedi (come .pyc in python, .o in c ecc.).

    È qui che entra in gioco l’ automazione di build e i file di build.

    Ad esempio, puoi ancora build il progetto (i due sviluppatori avranno ovviamente bisogno dello stesso software di costruzione), ma a loro volta potrebbero a loro volta utilizzare due IDE diversi.

    Per quanto riguarda il “junk” che viene generato, tendo a ignorarlo di più se lo è. So che questo è inteso per essere indipendente dal linguaggio, ma considera Visual Studio. Genera file utente (impostazioni utente ecc.) Questo non dovrebbe essere sotto il controllo del codice sorgente.

    D’altra parte, i file di progetto (usati dal processo di compilazione) dovrebbero sicuramente essere. Devo aggiungere che se siete in una squadra e siete tutti d’accordo su un IDE, allora il controllo dei file specifici IDE va ​​bene purché siano globali e non specifici e / o non necessari.

    Queste altre domande spiegano bene cosa dovrebbe e non dovrebbe essere controllato nel controllo del codice sorgente, quindi non le ripeterò.

    Secondo me dipende dal progetto e dall’ambiente. In un ambiente aziendale in cui tutti utilizzano lo stesso IDE, può avere senso aggiungere i file IDE al repository. Mentre questo dipende un po ‘dall’IDE, poiché alcuni includono percorsi assoluti alle cose.

    Per un progetto sviluppato in ambienti diversi, non ha senso e risentirà a lungo termine poiché i file di progetto non sono gestiti da tutti gli sviluppatori e rendono più difficile trovare le cose “rilevanti”.

    Tutto ciò che sarebbe devastante se fosse perso, dovrebbe essere sotto controllo della versione.

    A mio parere, qualsiasi cosa necessaria per build il progetto (codice, creare file, media, database con le informazioni richieste sul programma, ecc.) Dovrebbe essere nei repository. Mi rendo conto che specialmente per i file media / database questo è controsenso, ma per me se non riesci a diramarti e poi premi su build il controllo del codice sorgente non sta facendo il suo lavoro. Questo è il doppio per i sistemi distribuiti con creazione / fusione di filiali a basso costo.

    Qualunque altra cosa? Conservalo in un posto diverso. Gli sviluppatori dovrebbero scegliere il proprio ambiente di lavoro il più ansible.

    Da quello che ho visto con il controllo della versione, sembra che la maggior parte delle cose dovrebbe esserci, ad esempio il codice sorgente e così via. Tuttavia, il problema in cui si verificano molti VCS è quando si tenta di gestire file di grandi dimensioni, in genere file binari e, a volte, file audio e grafici. Quindi, il mio modo personale per farlo è di mettere il codice sorgente sotto controllo di versione, insieme a una grafica di piccole dimensioni e lasciare qualsiasi binario ad altri sistemi di gestione. Se è un binario che ho creato io stesso usando il sistema di costruzione dell’IDE, allora questo può essere definitivamente ignorato, perché verrà rigenerato ogni build. Per le librerie di dipendenze, bene è qui che arrivano i gestori dei pacchetti di dipendenza.

    Per quanto riguarda i file generati da IDE (suppongo che siano quelli che non vengono generati durante il processo di compilazione, come i file di soluzione per Visual Studio) – beh, penso che dipenderebbe dal fatto che tu stia lavorando o meno da solo. Se lavori da solo, prosegui e aggiungili: ti permetteranno di ripristinare le impostazioni nella soluzione o qualsiasi altra cosa tu faccia. Lo stesso vale per altri file non-solution come pure. Tuttavia, se si sta collaborando, la mia raccomandazione è no – la maggior parte dei file generati da IDE tendono ad essere, beh, specifici per l’utente, ovvero lavorano sulla macchina, ma non necessariamente su altri. Quindi, potrebbe essere meglio non includere i file IDE generati in quel caso.

    tl; dr dovresti mettere la maggior parte delle cose relative al tuo programma in controllo di versione, escludendo le dipendenze (cose come librerie, grafica e audio dovrebbero essere gestite da qualche altro sistema di gestione delle dipendenze). Per quanto riguarda le cose generate direttamente dall’IDE – beh, dipenderebbe se si sta lavorando da soli o con altre persone.