Lo schiacciamento si impegna da più sviluppatori in un singolo commit

4

Lavoro in un grande gruppo di sviluppo software e recentemente abbiamo effettuato il passaggio da Clearcase a Git. Alcune previsioni sono state fatte per quanto riguarda la qualità della linea principale in quanto sarebbe diventato troppo rumoroso e ingestibile con i commit di centinaia di sviluppatori e che il repository diventerebbe troppo grande troppo rapidamente.

L'attuale proposta per risolvere questo problema è che quando i team di feature apportano modifiche alla linea principale (questo può accadere ogni settimana o giù di lì, e ci sono più team che lavorano in parallelo sul prodotto) un singolo sviluppatore sarebbe responsabile dello schiacciamento più commit da più sviluppatori in un singolo commit.

L'approccio di cui sopra mi preoccupa principalmente perché la funzionalità 'git bisect' e 'git blame' sarebbe compromessa (un singolo sviluppatore ora rappresenterebbe il lavoro di più sviluppatori). Ho risposto alle seguenti proposte:

  • Per affrontare il rumore nella linea principale, ogni sviluppatore dovrebbe schiacciare un singolo commit prima di creare una richiesta di pull. Questa sembra essere una pratica standard.
  • Per far fronte alle dimensioni del repository, gli sviluppatori potrebbero eseguire clonazioni e innesti poco profondi (entrambi gli approcci sono dettagliati qui: link )

Finora non sono stato in grado di convincere nessuno che questi sarebbero stati buoni approcci. FWIW Ho anche proposto di utilizzare Gitflow come principale workflow di sviluppo per separare i rami di sviluppo e rilascio, ma anche questo non ha ottenuto alcuna trazione. Personalmente penso che fintanto che gli sviluppatori si schiacciano in un singolo commit prima di generare una richiesta di pull quindi va bene ... avere commit da molti sviluppatori diversi nella mainline è praticamente un non-problema dopo quel punto, mostra solo che un sacco di il lavoro è in corso.

Quindi la mia domanda a quelli di voi che lavorano su grandi progetti in Git: avere molti commit in arrivo sulla vostra linea principale è effettivamente un problema, costringendovi così a ricorrere a soluzioni come lo schiacciamento di commit da più sviluppatori in singoli commit?

    
posta daecks 30.08.2015 - 20:29
fonte

2 risposte

5

Nella mia azienda, non abbiamo mai avuto davvero problemi con troppi commit. La chiave per organizzare è creare rami ben denominati e fare il tuo lavoro in essi. Ciò aiuta a organizzare non solo i commit, ma il gruppo in via di sviluppo nel suo complesso.

Sì, senza diramazioni, potrebbe diventare un gran casino, ma con loro, la tua gestione può semplicemente sfogliare i commit che li usano senza dover schiacciare i commit insieme.

Lo schiacciamento di più commit in single non ha senso, poiché in questo modo è più difficile recuperare le singole modifiche.

    
risposta data 30.08.2015 - 21:48
fonte
2

Invece di un singolo repository con una tonnellata di filiali e tutti i codici che si incanalano in un unico punto, considera molti repository distinti. E, usa un server di build CI per costruire dai repository. Infine, invia gli artefatti di build come WAR o MSI o altro a un server Nexus o Nuget aziendale. In questo modo, puoi gestire separatamente i cicli di vita di ciascun piccolo modulo. Qualsiasi interdipendenza tra i moduli può essere caricata dal tuo server Nexus / Nuget durante la compilazione utilizzando il software di build di gestione delle dipendenze come Maven o MSBuild.

    
risposta data 01.09.2015 - 00:09
fonte

Leggi altre domande sui tag