I prodotti di un processo di costruzione appartengono a un repository?

No. I binari generati non appartengono al tuo repository. Devi tenerli in una specie di negozio, ma affidarli alla tua storia è una cattiva idea.

Tutti i sistemi VCS sono a conoscenza di un problema di alcuni con l'archiviazione dei file binari risultanti, sebbene i problemi particolari varieranno a seconda dell'implementazione. Alcuni sono comuni ad entrambi i sistemi.

I sistemi centralizzati, come TFS, devono spesso confrontare i file sul sistema locale con la versione più recente sul server. Hanno un tempo di confronto più difficile rispetto ai file di testo normali, quindi fare in modo che controlli costantemente quei file binari rallenterà il tuo ambiente di sviluppo.

Git, d'altra parte, usa gli hash del contenuto dei repository per determinare se un file è cambiato. (Fatto divertente: lo sha è in realtà l'hash risultante dell'intero repository.) Questo rende il controllo molto veloce, ma poiché Git memorizza l'intero file ad ogni commit, invece del solo delta, la memorizzazione di binari leggermente diversi gonfierà le dimensioni di il tuo repository molto.

Però tutti i sistemi hanno lo stesso difetto quando si tratta di archiviare gli output di build nel proprio repository. È un PITA totale che il tuo VCS pensi che qualcosa sia cambiato solo perché hai costruito la soluzione.

Immagina che questo scenario avvenga una dozzina di volte al giorno:

Si tira su il codice sorgente più recente. Sei paranoico, quindi prima di cambiare qualcosa, costruisci il progetto per assicurarti che il tuo ambiente sia impostato correttamente e l'ultimo ragazzo a impegnarsi non abbia infranto la build. Ora il tuo VCS pensa che qualcosa sia cambiato, anche se nulla ha.

Quindi, ignori quelle modifiche in sospeso e vai avanti con il tuo lavoro. Sei un buon sviluppatore, quindi commetti una mezza dozzina di piccole modifiche e le invii per la revisione. Quando i tuoi colleghi vanno a rivedere le modifiche, tutto ciò che vedono sono una dozzina di binari modificati. Devono vagliare tutti questi file per trovare il cambio di una linea che hai fatto.

Ti sembra efficace?

Capisco che intendevi un repository di codice sorgente, ma è interessante che tu abbia appena detto "un repository", perché molte organizzazioni memorizzano i loro binari in un diverso tipo di repository chiamato repository artefatto , specialmente aziende con architetture di microservizi o altre architetture altamente componenti.

Ciò consente di compilare semplicemente il microservizio su cui si sta lavorando e di inserire i binari già compilati per il resto del sistema per i test di integrazione locali. Strumenti come Maven o Gradle possono fare la risoluzione delle dipendenze delle librerie della tua azienda nelle tue repository locali e nelle librerie di terze parti nei repository su Internet.

Ma no, nel controllo del codice sorgente vuoi solo memorizzare il modulo preferito per apportare modifiche.

Questo è solo per aggiungere alla risposta di RubberDuck.

Tutto ciò che ha detto è vero. Ma c'è un altro motivo per cui i file binari non vengono usati con un VCS. I VCS sono progettati tenendo conto della programmazione e il tipo di file fondamentale con cui i programmatori lavorano sono i file sorgente . I file di origine sono basati sul testo, ovvero sono strutturati come una sequenza di linee (che sono esse stesse sequenze di caratteri) separate dal carattere di nuova riga. Anche gli altri tipi di file comuni con cui i programmatori lavorano, come i file di impostazione e di configurazione, sono generalmente basati sul testo.

Quindi, con questo formato in mente, il VCS confronta i file riga per riga (anche se alcuni funzioneranno con una granularità ancora più fine). Questa tecnica fallisce completamente per i file non di testo (binari). Ovviamente binario è una categoria di grandi dimensioni; qualsiasi formato binario avrà ovviamente il proprio formato interno (jpg, mp3, rdb, ecc.), ma questi differiscono in modo selvaggio e non sono basati sulla linea.

Affinché un VCS possa funzionare con qualsiasi tipo di file, deve comprenderne la struttura. È possibile creare un VCS che comprenda il formato binario di alcuni dump del database e possa confrontare i database tabella per tabella o anche riga per riga. Ma questo è impossibile da fare per ogni tipo di file e comunque il ROI è basso. Ecco perché ci limitiamo ai file di testo.