Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Se si prevede di consolidare più progetti Di Azure DevOps in un unico progetto, è probabile che ci si stia chiedendo cosa fare con tutti i repository:
- È consigliabile spostare progetti o unirli?
- Dovresti conservare la storia o solo i progetti più recenti?
Prerequisiti
| Categoria | Requisiti |
|---|---|
| Accesso al progetto | Membro di un progetto. |
| Autorizzazioni | - Visualizzare il codice nei progetti privati: almeno l'accesso di base . - Clonare o contribuire al codice nei progetti privati: membro del gruppo di sicurezza Contributors o con le autorizzazioni corrispondenti nel progetto. - Impostare le autorizzazioni del ramo o del repository: le autorizzazioni di gestione sono autorizzazioni per il ramo o il repository. - Modifica ramo predefinito: i criteri di modifica sono autorizzazioni per il repository. - Importare un repository: membro del gruppo di sicurezza Amministratori del Progetto o autorizzazione per la creazione del repository a livello di progetto Git impostata su Consenti. Per altre informazioni, vedere Impostare le autorizzazioni del repository Git. |
| Servizi | Repository attivati. |
| Tools | Optional. Usare i comandi az repos: CLI di Azure DevOps. |
Annotazioni
Nei progetti pubblici gli utenti con accesso stakeholder hanno accesso completo a Azure Repos, tra cui visualizzazione, clonazione e contributo al codice.
| Categoria | Requisiti |
|---|---|
| Accesso al progetto | Membro di un progetto. |
| Autorizzazioni | - Visualizzare il codice: almeno l'accesso di base. - Clonare o contribuire al codice: membro del gruppo di sicurezza Collaboratori o delle autorizzazioni corrispondenti nel progetto. |
| Servizi | Repository attivati. |
Qual è lo scenario?
Come illustrato, è necessario spostare il MigrationDemo repository da FabrikamOld al nuovo progetto del Fabrikam team.
Come faccio a spostarmi?
Sono disponibili due opzioni per lo spostamento, come descritto qui. La funzionalità di importazione è più semplice, ma è disponibile solo in Azure DevOps Services e Team Foundation Server 2017 Update 1 e versioni successive.
Utilizzare la funzionalità di importazione del repository Git
Quando si usa la funzionalità Importa repository, è possibile importare un repository Git nel progetto team da Team Foundation Server, Azure Repos o qualsiasi altro provider di codice sorgente Git come GitHub. Per altre informazioni, vedere Importare un repository Git in un progetto.
Eseguire manualmente la migrazione del repository Git
Crea un repository Git vuoto
In Esplora CODICE selezionare il nome del repository. Selezionare Nuovo repository dall'elenco, selezionare Git come tipo e assegnare un nome.
Dopo aver creato il repository, vengono visualizzate istruzioni dettagliate per iniziare. Copia l'URL clone negli Appunti.
Importante
Deselezionare l'opzione Crea automaticamente collegamenti per gli elementi di lavoro indicati in un commento di commit se si prevede di importare da una raccolta di progetti diversa o da un repository Git esterno. In caso contrario, Azure DevOps associa i commit agli elementi di lavoro esistenti di progetti team non correlati nella raccolta di progetti team.
Eseguire il mirroring del repository
Passare a un prompt dei comandi per gli sviluppatori e al percorso del repository locale (di origine) per il MigrationDemo repository in FabrikamOld. Eseguire il git clone --mirror comando usando l'URL di clonazione. La riga di comando è git clone --mirror https://demo-fabrikam.visualstudio.com/DefaultCollection/Fabrikam/_git/MigrationDemo.
In questo caso il clone --mirror comando è ridondante perché il repository remoto è bare. Viene usato qui come modo sicuro e semplice per configurare il telecomando.
Eseguire il push del repository
Eseguire il git push per push delle modifiche locali nel repository remoto di destinazione.
L'opzione --mirror viene usata sia con i comandi clone che push. L'opzione garantisce che tutti i rami e gli altri attributi vengano replicati nel nuovo repository.
Convalidare il nuovo repository
Passare al portale Web di Azure DevOps e convalidare il nuovo repository e la cronologia nell'hub CODE .
Verificare che tutti i rami siano stati spostati nel nuovo repository.
Configurare il nuovo repository
Verificare che le autorizzazioni e i criteri siano configurati correttamente per il nuovo repository. È possibile configurare la sicurezza dopo aver creato un repository Git vuoto o in questa fase. Riconfigurare le compilazioni per connettersi al nuovo repository. Infine, inviare una notifica agli utenti del repository originale per aggiornare i propri remoti in Visual Studio o eseguendo il git remote set-url origin comando .
> git remote set-url origin https://demo-fabrikam.visualstudio.com/DefaultCollection/Fabrikam/_git/MigrationDemo
Importante
Ricordarsi di pulire il progetto originale eliminando il repository (prestare attenzione, non c'è alcun annullamento) o bloccando i rami in modo che nessuno continui ad aggiornarlo accidentalmente.
Per ulteriori informazioni sulla pianificazione delle raccolte di progetti del team e dei progetti del team, vedere TFS Planning, Disaster Avoidance and Recovery, e TFS on Azure IaaS Guide.