Un flusso di lavoro gerarchico funziona così. Supponiamo che sospetti che ci sia un bug nel kernel di Linux che influisce sul nostro prodotto. Clona il codice sorgente del kernel in una directory locale e inizio a sperimentare con il codice. Ad un certo punto, chiedo l'aiuto di un collega, quindi spingo le mie modifiche fino a un repo privato sul mio profilo aziendale github in modo che possa trascinarle.
Alla fine verifichiamo che si tratta di un bug e abbiamo una rozza soluzione / bozza di concetto, ma vorremmo risolvere questo bug nel kernel ufficiale, e ha bisogno di una notevole quantità di lavoro per implementare la correzione della qualità di produzione . Creiamo un repo sull'impresa privata dei github della nostra azienda per coordinare questo lavoro.
Quando la correzione è pronta per la pubblicazione, istituiamo un repo pubblico sull'account github pubblico della nostra azienda, in cui la nostra commissione di revisione open source può approvare qualsiasi modifica prima che sia resa pubblica.
Cominciamo a coordinarci con le persone responsabili del sottosistema Linux appropriato, perfezionando le nostre modifiche fino a quando non le approvano e le inseriamo nel loro repository.
Il proprietario del sottosistema si coordina con uno dei luogotenenti di Linus Torvalds per far accettare la nostra modifica insieme ad altre recenti modifiche nel sottosistema.
Il tenente invia grossi gruppi di modifiche da più sottosistemi a Linus Torvalds per l'approvazione. Alla fine li inserisce nel kernel della linea principale.
Tutti questi repository hanno proprietari diversi, visibilità diversa e regole diverse per ottenere il codice incluso in essi. Alcuni sono di proprietà di società completamente separate. Senza il controllo della versione distribuita, dovresti copiare e incollare manualmente il codice in nuovi sistemi ogni volta che hai oltrepassato i limiti di proprietà, perdendo la cronologia.