Descrivere la sorgente interna con i fork
Le persone fanno un fork dei repository quando vogliono modificare il codice in un repository a cui non hanno accesso in scrittura.
Se non si ha accesso in scrittura, non si fa parte del team che contribuisce a tale repository, quindi perché modificare il repository di codice?
Cerchiamo di cercare motivi tecnici per migliorare qualcosa nel nostro lavoro.
È possibile trovare un modo migliore per implementare la soluzione o migliorare le funzionalità contribuendo a o migliorando una funzionalità esistente.
È possibile creare un fork dei repository nelle situazioni seguenti:
- Voglio apportare una modifica.
- Penso che il progetto sia entusiasmante e potrei volerlo utilizzare.
- Voglio usare del codice in quel repository come punto di partenza per il mio progetto.
I team software sono incoraggiati a contribuire a tutti i progetti internamente, non solo ai progetti software.
I fork sono un ottimo modo per promuovere una cultura di open source interiore.
I fork sono un'aggiunta recente ai repository Git di Azure DevOps.
Questa ricetta illustra come eseguire il fork di un repository esistente e contribuire con modifiche upstream tramite una pull request.
Preparandosi
Un fork inizia con tutto il contenuto del repository upstream (originale).
Quando si crea un fork in Azure DevOps, è possibile includere tutti i rami o limitarli solo al ramo predefinito.
Un fork non copia le autorizzazioni, i criteri o le definizioni di compilazione del repository che viene forkato.
Dopo aver creato un fork, i file, le cartelle e i rami appena creati non vengono condivisi tra i repository, a meno che non si avvii una richiesta pull.
Le richieste pull sono supportate in entrambe le direzioni: da fork a upstream o upstream a fork.
L'approccio più comune per una pull request sarà da fork a upstream.
Come eseguire questa operazione
Scegliere il pulsante Fork (1), quindi selezionare il progetto in cui si vuole creare il fork (2). Assegnare un nome al fork e scegliere il pulsante Fork (3).
Quando il fork è pronto, clonarlo usando la riga di comando o un IDE, ad esempio Visual Studio. Il fork sarà l'origine remota. Per praticità, dovresti aggiungere il repository upstream (da cui è stato creato il fork) come remoto chiamato upstream. Nella riga di comando digitare:
git remote add upstream {upstream_url}È possibile lavorare direttamente nel file principale. Questo fork è la copia del repository. Tuttavia, è consigliabile continuare a lavorare in un ramo dell'argomento. Consente di gestire più flussi di lavoro indipendenti contemporaneamente. Inoltre, riduce la confusione in un secondo momento quando si desidera sincronizzare le modifiche nel fork. Effettua e committa le modifiche come faresti normalmente. Al termine delle modifiche, effettua il push nel repository di origine (il tuo fork).
Apri una pull request dal tuo fork al repository principale. Il repository upstream applicherà tutti i criteri necessari per i revisori e le compilazioni. Una volta soddisfatti tutti i criteri, la richiesta pull può essere completata e le modifiche diventano una parte permanente del repository upstream:
Quando la PR (pull request) viene accettata a monte, devi assicurarti che il tuo fork rifletta lo stato più recente del repository. Si consiglia di ribasare sul ramo principale dell’upstream, supponendo che questo sia il ramo di sviluppo principale. Nella riga di comando eseguire:
git fetch upstream main git rebase upstream/main git push origin
Per altre informazioni su Git, vedere: