Controllo il codice generato nel controllo del codice sorgente o no? [duplicare]

Come regola generale, i file generati non appartengono al repository del codice sorgente.

Il rischio maggiore che si esegue quando si inseriscono questi file nel repository è che non sono sincronizzati con la loro origine e la generazione viene eseguita con file di protocollo buffer diversi da quelli che si penserebbero in base ai file .proto.

Alcuni motivi per deviare dalla regola generale sono

• L'ambiente di compilazione non può gestire automaticamente il passaggio di generazione aggiuntivo. Se devi generare i file manualmente per ogni build, potresti anche metterli nel VCS. Quindi riduce il rischio di una mancata corrispondenza della versione a causa del minor numero di persone che devono eseguire la fase di generazione.
• Il passaggio generazionale rallenta notevolmente la tua build
• Dopo averli generati, i file vengono ulteriormente modificati a mano. In tal caso, non sono più realmente file generati e quindi appartengono al VCS.
• I file di origine cambiano molto raramente (ad esempio provengono da una terza parte che fornisce solo aggiornamenti ogni pochi mesi circa).

Innanzi tutto, il software di controllo delle versioni è lì per aiutarti a svolgere il tuo lavoro. Quindi, la prima domanda che fai non dovrebbe essere "dovrei inserire X nel controllo della versione?" ma piuttosto "mi aiuterà a mettere X in controllo di versione?". Spesso questi due hanno la stessa risposta, ma non sempre.

In altre parole, invece di chiedere a noi se pensiamo che questi file debbano essere in controllo di versione o meno, chiedi a te stesso se farlo è utile per tu . Se la generazione dei file è veloce, qual è il valore nel salvataggio dei dati generati? I tuoi script di build sono progettati in modo tale da generare sempre i file, oppure prima guardano se c'è qualcosa sul disco?

Devi anche chiederti se è importante avere una registrazione concreta di ciò che è andato in una build. Se è necessario riprodurre con precisione una build, potrebbe esserci un valore nell'avere quei file nel controllo del codice sorgente. È ipotizzabile che una build futura possa utilizzare una versione più recente dello strumento che genera file leggermente diversi, sebbene un'altra opzione sia anche il controllo della versione degli strumenti stessi.

La linea di fondo è, non preoccuparti tanto di ciò che dovresti o non dovresti fare basandoti sulle idee di qualcun altro di uno standard, fai ciò che è meglio per il tuo progetto. Solo tu puoi rispondere perché non conosciamo tutti i vincoli e i requisiti con cui hai a che fare.

Molti file in .net vengono generati automaticamente da Visual Studio; tuttavia, di solito li controlliamo in modo che chiunque verifichi il codice sorgente abbia una versione completa che crea e gira. (Vedi, per esempio, le classi fatte da file xsd per deserializzare xml.)

Vorrei vedere questi file allo stesso modo; sono codice sorgente C # che è stato generato tramite uno strumento ma che è necessario per la creazione del programma. Pertanto, controllali.

Se non ci saranno modifiche ai file generati, non ha senso inserirli nel controllo della versione. Non si mettono i binari compilati anche nel controllo della versione, giusto? Una regola di base con controllo della versione è che non devi mettere nulla nel controllo di versione, che può essere generato da altri file. Naturalmente se la generazione è in qualche modo complicata o richiede molto tempo, potrebbe non essere pratico.

Sembra che tu ti stia riferendo a ciò che Il programmatore pragmatico chiama la generazione di codice passivo .

Passive code generators save typing. [...] Once the result is produced, it becomes a full-fledged source file in the project; it will be edited, compiled, and placed under source control just like any other file.

Uses:

• Creating new source files
• Performing one-off conversions among programming languages
• Producing lookup tables and other resources that are expensive to compute at runtime

Inserirò i file di origine generati per uno dei seguenti elementi:

• Se hai intenzione di modificare il codice C # generato
• Se vuoi evitare di dover generare il codice prima di eseguirlo in ambienti dev? Per esempio. se uno strumento deve essere installato per fare la generazione
• Se il processo di generazione è lungo