Azure DevOps Guida

Architettura

La seguente architettura è di un caso reale.

Configurazione

Nella versione gratuita, Azure DevOps Server Express, si prevedono un massimo di 5 utenti. Precondizione è l’installazione di Git sui client e per comodità operativa anche Visual Studio Code. L’installazione standard prevede il seguente scenario.

WebSite DevOps

L’applicazione Web “DevOps” è installata sotto un nuovo Web Site, di default è “Azure DevOps Server”, che dovrebbe avere un binding che non confligga con gli altri site. Un binding indipendente si avrebbe usando una porta diversa da quella standard o usando un hostName\dominio diverso dal resto dei sites.

Questa è la configurazione di default tranne che per il fatto che è installato su D: anziché sul drive C: . Le due applicazioni web (sotto il web site “Azure DevOps Server”) usano application Pool dedicati.

Altra circostanza associata alla configurazione di default è che non si usa la Basic Authentication ma notare che comunquequeue verrà richiesta l’autenticazione di dominio.

Impostazione sul WebSite di default

Per semplificazione, (evitare la comunicazione su porta non standard) e per uniformità di gestione si spostano le due applicazioni web “Azure DevOps Server” e “queue” (che è annidata alla prima) a quello di default “Default Web Site” a patto di continuare ad usare i due application pool dedicati e predisposti per le due applicazioni web. I passi sono anche spiegati su questo post su stackoverflow.com Infine, si abilita la Basic Autentication per l’applicazione web “DevOps”. La situazione dopo le modifiche accennate sarà:

Spostare l’autenticazione da Anonymous a Basic Authentication:

Starting with DevOps

Avvio dell’applicazione da Browser, ogni volta il primo avvio richiede più tempo…. Accedere utilizzando o utenze locali al server o quelle di dominio, conseguenza dell’impostazione dell’applicazione web per lavorare con la Basic Authentication. La prima volta in assoluto ci si trova sulla “DefaultCollection” e verrà richiesta la creazione di un progetto come nel seguente esempio:

Configurazione primo Project

Dopo aver creato un nuovo progetto da aggiungere alla collezione di default si può procedere con la sua customizzazione togliendo ciò che non serve:

                                                                                                           e …

Si settano ad off i tools che non servono:

Aggiungere utenze di progetto

Chi ha creato il progetto, oppure i membri Build Administrator (amministratori della macchina server), possono aggiungere utenti che potranno accedere al repository in qualità di Contributors del Team, quindi: 1. andare nelle impostazioni del progetto (siamo già nel posto giusto dal passaggio precedente oppure andare sulla pagina di Home, selezionare la collection a sx ed infine sul progetto scelto, cliccare sull’ingranaggio “Project Settings” in basso a sx); 2. poi “Security”, sempre sulla toolbar a sx (porre attenzione che non si sia nella Security della collection ma del progetto altrimenti le autorizzazioni riverberano su tutti i progetti della collection); 3. Al centro, nell’elenco dei gruppi, selezionare il progetto sotto “Teams”; 4. dal TAB a dx, selezionare “Members”, infine, cliccare su “+ Add”;

5. selezionare dall’elenco l’utente digitando VF-ROOT\userName NOTA. In DevOps il progetto è considerato un Object (elemento base a cui assegnare permessi) Gli utenti, se non esplicitamente appartenenti anche ad altri gruppi, si intendono Contributors come si evince dal seguente:

E viceversa:

Assegnazione utenti a gruppi

È possibile assegnare agli utenti permessi specifici per gruppo. Nella sezione Project Settings di un progetto possiamo scegliere di aggiungere utenti ai gruppi previsti.

L’appartenenza ad un gruppo assegnerà permessi specifici. Questi gruppi sono specializzati per funzionalità associate, basta flaggare i permessi da associare al gruppo dall’apposita pagina; cliccare su “Repositories”, poi sul tab “Permission”:

Es. gruppo Readers

Oltre ad un Contributor, si aggiunge l’utente Iuri al gruppo Readers associato al progetto. Potrà vedere qualsiasi files ma non potrà editarlo, ecco cosa vedrà:

In particolare, su un file:

Mentre un appartenente a Contributors vedrà:

Nota, segregazione

L’aggiunta di un utente ad un progetto, col procedimento appena esposto, non cambierà le grant specifiche su altri progetti, in altre parole, l’utente precedente non avrà visibilità su altri progetti e su altre collections se non esplicitamente aggiunto. Ecco, ad esempio, quanto vedrà comunque l’amministratore:

mentre l’utente vedrà solo quanto esplicitamente condiviso:

Aggiungere utenze alle Collection

Nei paragrafi precedenti abbiamo dato autorizzazioni a livello di singolo progetto, è possibile dare delle autorizzazioni a livello di collection. Le autorizzazioni di un singolo utente assegnate alla collection si riverberano su tutti i progetti della collection già presenti e futuri.

Si apre la pagina con la configurazione degli accessi. Dopo aver selezionato il gruppo opportuno, cliccare sulla sezione di destra il TAB “Members”, quindi cliccare sul pulsante “+ Add…” ed inserire l’utenza mediante le credenziali di dominio.

Check: Role, Identity, Scope.  

Configurazione dei Client

Su ogni client degli utenti che accederanno all’applicazione Web DevOps devono essere installati i seguenti software gratuiti: - Git per il motore del source versioning locale e per l’interazione col server dov’è installato DevOps. Si può installare senza necessità di disporre dei diritti dai amministrazione, scaricabile al link: https://git-scm.com/downloads , è un software utilizzabile da Prompt comandi (sostanzialmente senza GUI, si interagisce attraverso comandi da tastiera); NOTA è installabile anche senza diritti di amministratore. - Visual Studio Code per la gestione dei documenti o dei progetti con script o codice sorgente mediante apposita GUI. Si può installare senza necessità dei diritti di amministrazione, scaricabile al link: https://code.visualstudio.com/docs/?dv=win64user

Configurazione di Git

Proxy

Dal punto di vista del client le interazioni col server avvengono mediante il software Git locale. Nel caso (ed è questo il caso) si usi un proxy per la navigazione, è necessario impostare una configurazione di Git affinché possa comunicare col server DevOps. Dopo l’installazione di Git si lancerà il seguente comando: C:\> git config –-global http.proxy http://10.74.71.72:8080 Nel caso fosse necessitano l’uso di credenziali, digitare invece: C:\> git config –-global http.proxy http://dominio\utente:password@10.74.71.72:8080

User

È mandatorio che Git abbia configurato il nome utente e l’e-mail, infatti, se non fosse già fatto, Visual Studio Code farebbe scattare il seguente errore:

Per risolvere lanciare “Git Cmd” e digitare (come esempio si imposta l’utente Marco Garbin): git config –-global user.name “Marco GARBIN” git config –-global user.email marco.GARBIN@vodafone.com

Cartella di lavoro

È opportuno che ogni client abbia configurato una cartella sotto la quale collocare tutti i repository da sincronizzare col server DevOps. Ad un primo livello si potranno avere delle cartelle col nome delle collection sotto cui si assegnano progetti e poi nel livello successivo cartelle col nome del progetto da custodire in remoto. All’interno della cartella di progetto si organizzeranno delle cartelle in base alla tipologia di documenti da conservare.

Es. Riferimento al Server remoto

Git si riferirà ai repository del server remoto con la seguente base URL: https://vg1178yw.eito-dublin.local Supponiamo che su un client abbiamo già una cartella con un repository, segue un esempio di file config posto nella cartella nascosta .git , notare la sezione [remote “origin”] che si riferisce al progetto “T_Metodo1” posto all’interno della collezione “DefautCollection”.

 

Operatività

Creare un Repository

L’obiettivo è quello di usare il server, su cui abbiamo installato Azure DevOps Server, come archivio centralizzato/recovery di risorse al fine di disporre di backup, tracciare cambiamenti, ritornare a precedenti versioni, condividere col team documenti utili e sensibili. Le risorse gestite posson essere: • documenti sempre afferenti ad un progetto di dominio al team a cui si appartiene; • software ovvero più files omogenei che costituiscono applicazioni custom. Questi files rappresentano il codice sorgente dell’applicazione implementata internamente. È questa la tipologia sulla quale DevOps dà la massima utilità; tuttavia, alcune funzionalità vanno al di là di quanto serve al VCVI Team. Sul server sono attivi tutta una serie di servizi, tra cui una applicazione Web a cui ogni client potrà accedervi mediante browser. La creazione di un nuovo progetto (insieme di files da raggruppare ed aggiungere ad una collection) e la maggior parte di tutte le altre operazioni possono esser fatte via browser, solo la creazione di una nuova collection deve essere fatta tramite apposita app sul server, Azure DevOps Server Admin Console. Sempre dal nostro browser locale aperto sulla applicazione Web Azure DevOps, dopo aver definito un progetto creeremo il primo repository sul server, sarà una copia in remoto di ciò che si dispone già in locale (che inizialmente terremo distinta dalla cartella che sarà poi operativa). Per la gestione del repository locale potremo usare una applicazione client che integra Git (che è il motore del versioning usato anche a livello server). Ad esempio, possiamo usare Visual Studio Code (VS Code) applicazione gratuita fornita da Microsoft. Relativamente al repository gli step che seguiremo sono: 1. Clonazione in locale del repository remoto, anche se vuoto perché appena creato. All’atto stesso in cui cloniamo il repository selezioneremo l’applicazione client usata per gestire i files di progetto, supponiamo sia VS Code. Contestualmente si aprirà VS Code dandoci una vista sulla cartella che conterrà il “progetto”. Operazione che faremo dal browser direttamente dal client. 2. Aggiungiamo localmente i files che costituiscono il progetto. Il repository sarà consolidato con un’operazione di aggiunta ed infine i files saranno committati definitivamente nel primo “branch”, l’operazione sarà commentata con una opportuna descrizione testuale. 3. Aggiorneremo il server con quanto appena committato al punto precedente. Teniamo presente che il server sarà usato come archivio di riferimento centralizzato e definitivo mentre localmente provvederemo al normale lavoro di sviluppo. Ogni attività di sviluppo avrà, al termine, l’azione di consolidamento\aggiornamento del repository sul server.

  Clonazione in locale Il repository remoto è stato creato ma non ancora “inizializzato” ovvero predisposto a funzionare anche su un client (computer locale all’utente). Per poter lavorare in locale su un client occorrerà una azione di clonazione. È indispensabile una applicazione client ovvero Git o meglio VS Code + Git. Se prima di clonare il repository sul client si eseguirà un primo commit allora si seguirà il “metodo 1”, ovvero la “inizializzazione” altrimenti sarà il “metodo 2” che però, dopo la clonazione, richiederà un primo intervento sul client per collegare il primo branch locale a quello del repository remoto. NOTA la clonazione su un repository locale già esistente creerà una nuova cartella il cui nome terminerà con un progressivo. Creiamo il repository:

Quindi lo inizializziamo scegliando alternativamente tra: Metodo 1 (consigliato) Il repository appena creato sul server si inizializza aggiungendo un primo file (è opzione di default), README.md, e così si predispone il primo branch, main branch, che così com’è sarà poi clonato sul client evitando un passaggio come nel metodo 2.

Dopo di che si aprirà la seguente pagina per cui cliccheremo sul pulsante “Clone” come segue:

Cliccare “Always allow to use ….”, selezionare la cartella destinazione dove verrà collocato il repository ma ancora vuoto (eccezion fatta del file README.md), operazione ripresa nel paragrafo seguente “Apertura app Client – VS Code”. Metodo 2 Il repository è appena stato creato sul server e si sceglie di portarlo subito sul client mediante la azione di clonazione cliccando sul pulsante come indicato di seguito.

Sceglieremo sempre la procedura di clonazione in locale usando il client Visual Studio Code. Eventualmente i client alternativi utilizzabili sono:

Apertura app Client – VS Code Dopo aver cliccato su “Clone in VS Code”, il browser aprirà l’applicazione client Visual Studio Code pertanto chiederà conferma all’utente:

Dopo che VS Code si sarà aperto sarà richiesto di indicare la cartella in locale dove clonare (copiare) il repository remoto.

Assecondare la procedura confermando le richieste delle impostazioni di default. Con la procedura di creazione della directory di lavoro, nella cartella principale, sarà creata automaticamente anche la cartella nascosta “.git” contenente le impostazioni di gestione ed il repository locale di Git. la cartella “.git” conterrà in particolare il file “config”:

Con:

Aggiunta di elementi locali A questo punto possiamo iniziare ad aggiungere files al progetto locale, lo possiamo fare: - direttamente come nel seguente esempio o - alternativamente, aggiungendo files e cartelle già esistenti in altre locazioni agendo da fuori VS Code (ad es. attraverso File Explorer) che comunque ne rileverà automaticamente le modifiche intervenute e proporrà una azione di Commit.

Intervenendo direttamente, cliccando col tasto dx del mouse sotto la regione a sx intestata col nome del repository, creeremo ed aggiungeremo un primo file, “Prova_NuovoFile.txt”, contenete un testo di prova:

Commit locale Dopo aver salvato il file dovremmo committare il file aggiungendo un testo descrittivo che riguarda eventualmente anche altri file o cartelle eventualmente aggiunte o modificate e che costituiranno il set o branch corrente.

NOTA Inserire sempre un commento anche perché a causa di un baco in VS Code dopo aver cliccato su Commit la clessidra andrebbe a vuoto all’infinito ed occorrerà chiudere e riaprire l’applicazione e committare, comunque, con un testo descrittivo. Al termine si aggiorna il server con una azione di Push verso il repository remoto, infatti, dopo aver premuto su “Commit” VS Code si predispone sulla sincronizzazione come descritto nel paragrafo seguente. Push remoto Prima di compiere l’operazione di Push, notare che, se nel frattempo sono intervenute modifiche in remoto scatterà un errore e verrà suggerito di fare prima un Pull (per adeguare la versione corrente a quanto è in remoto, ovviamente se ci son conflitti si risolveranno con richiesta del proprio intervento); fatta l’operazione di Pull si potrà fare Push e comparirà il pulsante Sync Changes come indicato qui di seguito. Sotto il tab “SOURCE CONTROL”, dove prima c’era il pulsante “Commit” dovrebbe comparire il pulsante “Sync Changes”:

Questa operazione è suggerita ma è identica all’azione di Push eseguibile come segue:

Nota Come comportamento di default ogni Push sottende prima un Pull (per acquisire eventuali modifiche intervenute nel frattempo sul server, e dopo l’azione voluta ovvero la Push.

Nel caso si sia scelto il “metodo 2”, in fase di clonazione, allora molto probabilmente avremo il seguente situazione da sistemare localmente:

Situazione sul server DevOps Dopo aver cliccato su “Files” dalla barra laterale sinistra:

Supponendo che altri contributori siano intervenuti per apportare modifiche lo simuliamo aggiungendo una cartella ed un file dalla pagina del portale DevOps del server.

Quindi diamo un nome alla cartella e ne approfittiamo per aggiungere un file:

Riempiamo il file e confermiamo cliccando su Commit.

Infine:

Volendo verificare la storia dai log dei commit cliccare sulla voce “Commit” sulla barra laterale sinistra:

Aggiornamento lato Client, Git pull Tornando a Visual Studio Client sul client, nel frattempo automaticamente associato alla barra laterale della voce Git compare:

Ed al termine della procedura di aggiornamento locale, dopo aver cliccato sull’icona “Explorer” avremo il seguente aggiornamento:

 

Più repository per stesso progetto

Non appena vien creato un nuovo progetto si predispone anche il primo repository che avrà lo stesso nome del progetto. È possibile, non solo rinominare il repository ma anche aggiungerne di altri per segregare opportunamente altri files\documenti. Dopo aver selezionato un progetto, dalla barra laterale cliccare su “Repos”, quindi sulla dropDownList che ha stesso nome del primo progetto:

Quindi supponendo di aggiungere la cartella \ repository destinata alla documentazione “Doc”:

Possiamo rinominare ma in generale gestire tutti i repository associati al progetto:

Si apre la vista sulla lista di repositories disponibili quindi cliccare sui tre puntini laterali:

Questa stessa pagina si ottiene andando in Project settings quindi cliccando sulla voce Repositories che è in basso a sx.

Permessi dei repositories

È una configurazione associata ai progetti.

Ad esempio, è possibile configurare i permessi associati al gruppo utenti “Contributors”:

Interazioni col remote repository

Ogni interazione è successiva alla prima operazione eseguita in assoluto che sarà l’operazione di clone dal repository remoto verso il client, questa operazione costituirà il legame tra il server ed il client. Questo legame è indicato dal riferimento al servizio che è sul Server, notare la sezione [remote “origin”] che è nel file config posto nella cartella .git (che è sotto la radice del repository in locale). Dando per scontato la prima operazione di clone, aperto un repository locale con Visual Studio Code, possiamo interagire col server nei seguenti modi: - Fetch from all remotes, pernde la versione sul server sovrascrivendo tutto ciò che è in locale. - Pull, prende la versione sul server e la fonde, integrandola, nel repository locale. - Push, operazione opposta a quella di Pull, è l’operazione di aggiornamento del repository remoto con quanto è in locale. .

Sincronizzazione

Localmente, dopo l’operazione di commit (che serve a consolidare le modifiche locali), si sincronizza il server inviando le modifiche locali, in questa occasione, se nel frattempo è intervenuta qualche modifica sul server rispetto la versione locale, VS Code provvederà automaticamente ad aggiornare prima la versione locale ed in caso di conflitti si chiederà conferma all’utente su quali azioni intraprendere mediante operazione di merge.

Oppure, in contesti più complessi:

Conflitti

Supponendo che contemporaneamente gli utenti Giuseppe e Marco modifichino il file versione.txt : - Giuseppe ha aggiunto la riga 5: “aggiunto dopo da Giuseppe verifica conflitti”; - Marco ha aggiunto la riga 6 (che è l’ultimo rigo del file senza la modifica contemporanea di Giuseppe): “aggiunta riga 6 da Marco”. Versione di Giuseppe:

Giuseppe fa Commit e poi Push sincronizzando le modifiche.

Versione di Marco:

Marco fa Commit e dopo aver lanciato la sincronizzazione otterrà la seguente notifica di conflitto:

Dopo aver cliccato su “Resolve in Merge Editor”, automaticamente Marco avrà:

Dall’applicazione web del server si può avere la seguente visone dei cambiamenti, “History”:

 

TAG e Branch

TAG

I TAG sono delle etichette, generalmente sono quelle assegnate alle versioni. Un TAG è legato ad un Commit che ha un ID alfanumerico quindi il Tag consente di accedervi senza dovervisi riferire col codice alfanumerico. Si posson creare TAG sia sul server che localmente, è preferibile siano creati sul server perché attualmente quelli creati sul Client rimarranno sul client anche eseguendo un Push. Creare TAG sul Server Ci sono diversi modi per crearli, dalla “Commits” view (che è quella più intuitiva) oppure dalla Tags view. Selezionare un Progetto, quindi posizionarsi su un repository, cliccare su Commits:

Quindi dare una etichetta ed un commento adeguato:

Per visualizzarli:

Oppure meglio se da Commits:

Create TAG dal Client SCONSIGLIATI perché attualmente quelli creati sul Client rimarranno sul client anche eseguendo un Push. Dopo aver apportato una modifica e committata localmente, dopo aver cliccato sull’icona “Source Control”:

In alto alla finestra digitare l’etichetta:

Dopo aver confermato col tasto ENTER, andando col mouse sopra l’ultimo commit dove abbiam appena inserito il TAG:

Aggiornando la vista si ha:

 

Switch versioni

Dal Client

Dal client possiamo cambiare contesto ovvero branch o tag. Purtroppo i Tag non si vedono nel tab “GRAFH” che è a sua volta nel tab “SOURCE CONTROL” del menu a colonna di sinistra, per vedere i tag disponibili si vedranno dopo aver cliccato su “Checkout to …” come si vedrà qui di seguito.

Per cambiare temporaneamente TAG

Nell’ipotesi che prima si siano già creati opportuni TAG. La funzione è “Checkout to …”:

Supponendo che si torni ad una vecchia versione, quella taggata con “Ver_intermedia1” per tornare alla più recente occorrerà scegliere il branch “origin/main”. Da questa situazione:

Per tornare alle origini:

Quindi:

Per tornare alla versione precedente

Per semplicemente annullare l’ultima modifica, NON cliccare su “Commit”, ma:

Altrimenti, se siamo oltre il semplice non commit, per tornare ad una versione committata precedente

Per annullare radicalmente e ritornare ad una precedente versione

Dal client, dopo aver cliccato a sx su “Source control”, selezionata la versione su cui ritornare ed annullare tutto ciò che è seguito, cliccare col tasto dx del mouse e scegliere “Checkout (Detached)”:

Repository in ZIP

Scaricare

Dato un progetto il cui repository di cui vorremmo l’intero contenuto senza usare il Git locale ma scaricandone una versione compressa in file ZIP possiamo produrlo dal portale DevOps come segue:

Scaricato lo zip, esso avrà esattamente la stessa struttura e contenuto del repository remoto:

Il contenuto scaricato sul file system non è un repository Git ma si riproduce soltanto la struttura delle cartelle e relativo contenuto.

Caricare

È possibile fare l’operazione inversa all’operazione descritta nel paragrafo precedente ovvero, sempre dal portale, è possibile caricare un file dal computer locale (anche senza Git o VS Code installati) sul server remoto. Purtroppo, è possibile farlo con un sol file alla volta e non, ad esempio, con uno zip contente tutto un repository.  

Note

Installazione

Subito dopo l’installazione si passa al Wizard di configurazione avviabile anche successivamente lanciando l’App “Azure DevOps Server Administrator Console”:

Modalità avanzata

Account:

Problema della configurazione del Web Site\ web application:

Errori in Configurazione

SQL Server

Ruolo Qui SQL is applied across various job roles beyond traditional development or database administration. In the context of DevOps, it is used for automating database deployments, ensuring data integrity during continuous integration and delivery (CI/CD), and helping teams make data-driven decisions.

  Compatibilità SQL Server on Linux isn't supported. Link qui

 

Access level, Permission, Security groups

Access level Definisce dei limiti alle funzionalità associate agli utenti. Ci sono 3 access level: Stakeholder, Basic e Basic Test Plans. Note Gli amministratori del Server sono di default assegnati ai gruppi: Project Collection Administrators, Team Fondation Administrators, Project Collection Valid Users. Project Collection Administrators: • Hold the highest authority within an organization or project collection. • Perform all operations for the entire collection. • Manage settings, policies, and processes for the organization. • Create and manage all projects and extensions. Project Administrators: • Operate at the project level. • Manage security groups and permissions from the Project settings in the web portal. • Handle permissions for specific objects contributors create within the project.

!!!

 

Dizionario

Termine o comando o funzione Git Significato Esempi Bare repository È un repository nudo ovvero privo dei files di lavoro su cui si può direttamente lavorare per modificarli, è un archivio che ha solo i files di lavoro di Git, il contenuto invece è protetto quindi criptato. Blame Letteralmente "incolpare, dare la responsabilità". Blob È una contrazione di "Binary large object". Ogni versione di un file è rappresentato da un blob, è un termine con cui ci si riferisce ad una variabile o file che possa contenere qualsiasi dato indipendentemente dal sua interpretazione. Branch È una diramazione della versione dell'intero progetto. E un commit a cui s’è data una etichetta per identificarlo. Importante notare che sono gerarchici, ognuno ha un precedente tranne il primo. Il primo branch di default è main o master creato con l’init, un branch è un puntatore a uno specifico commit. Ci posson essere vari branch che corrispondono a versioni importanti del progetto e si possono unire mediante operazione di merge verso il ramo principale o altri, Crea un brach 'develop' copia di master:$ git branch develop$ git push -u origin develop Check in Letteralmente "prendere possesso", "controllare". In Git non esistono i concetti di Check-in e check-out tipici di SVN ma quando si parla di check in si intende eseguire un git commit quindi consolidare le modifiche localmente. ... Check out (letteralmente significa guardare) Il comando git checkout è usato per cambiare tra differenti branch e ripristinare il working tree dei files. Quindi consente di "navigare tra specifici commit o branch del tuo repository. git checkout master è uno dei comandi fondamentali perché indipendentemente dalle versioni più aggiornati ci riporta alla versione ufficiale. Help $ git checkout branch-name $ git checkout master #Per RITORNARE all'ultima versione Per ripristinare un file specifico al suo stato di un particolare commit: $ git checkout commit-hash -- file.txt Cherry pick Copia le modifiche da uno o più commit del ramo di origine in un ramo di destinazione. Commit È un’istantanea (chiamata anche snapshot) del repository ovvero dell’insieme delle risorse da gestire\versionare, poiché ci possono essere vari commit nella storia di un repository ogni commit è identificato univocamente. Git non si limita a memorizzare le differenze tra due versioni successive ma salva l’istantanea (compressa) del contenuto di tutti i file; se un file non cambia contenuto tra due commit viene messo un riferimento al commit precedente. Ogni commit conosce il suo “genitore” (parent commit). downstream Si fa downstream ogni volta che si fa una copia da un repository es con clone, checkout, etc. Fetch Letteralmente "prendere". Azione per prelevare da Git (locale o remoto) sovrascrivendo i file locali, quindiignorando tutte le modifiche locali. Fork Letteralmente "forchetta" ma anche "bivio". Un "fork" in Git è una copia di un repository esistente in cui un nuovo owner si discosta dalla linea di codice\sviluppo ufficiale. Avviene quando uno sviluppatore vuole allontanarsi dal progetto originale. Quando si crea un Fork i precedenti contributori non saranno in grado di committare codice a meno che l'owner non gli dia accesso. Head E' il puntatore al commit corrente. Ad ogni nuovo commit, l’head è aggiornato. LaWorking Copy attuale è quella a cui punta il puntatore head, tuttavia percapire qual è l’head della Working Copy attuale si esegue il comando git log –graph –-all –oneline. master E' il branch master e rappresenta la versione ufficiale del repository (questo non vuol dire che non ce ne siano di più aggiornate ma non sono quella definitiva ma "temporanea" a determinati fini) Object database E' ildatabase chiave/valore conservato nella cartella nascosta .git. lachiave è un valore calcolato in SHA1, il valore è il contenuto del file. Origin E' un'abbreviazione che stà a rappresentare il repository remoto da cui inizialmente si è clonato. Più precisamente è utilizzato al posto dell'URL del repository remoto a cui ci si riferenzia più facilmente. Pull Letteralmente "tirare". E' l’opposto di push) acquisizione\download di un repository remoto da fondere edintegrare localmente. $ git pull origin master Questo comando scarica DAL server tutti il repository sulla tua macchina come un aggiornamento. Push Letteralmente "spingere". Help Operazione di aggiornamento di un repository remoto, da un client si spingono le modifiche nell’archivio remoto. Esegue anche localmente la copia da un brach ad un altro es da master a develop $ git push origin master $ git push -u origin develop -u = Aggiunge upstream reference Remote repository O semplicemente Remote, è un repository su altro computer col quale si può chiedere che lui si allinei al nostro contenuto o ci si può allinearsi al suo i comandi a disposizione per farlo sono rispettivamente: push e fetch. Nel momento in cui si esegue un git clone si crea una copia locale e si salva il riferimento (URL) al repository da cui ha recuperato i dati, tale riferimento prende il nome di “remote”. Repository E' il database locale su file che conserva i vari commit. Snapshot E' un'istantanea dellintero progetto. Ogni volta che si fa un Commit Git crea una immagine di TUTTI i files presenti in quel momento e salva un riferimento chiamato "index". (Git in realtà non salva nuovamente tutti i file per ogni commit, ma crea per ciascuno di essi un collegamento alla sua versione precedente già salvata) Staging area o index fa da tramite tra il file system ed il repository. È uno spazio dove parcheggiare gli oggetti pronti per il prossimo commit mediante il quale finiranno nel repository. Stale Letteralmente "vecchio", "stantio". Riferito ad un branch non più attivo, che ad es è stato rimosso dal server remoto. Può essere anche un broken commit. Stash "metter da parte". Nel mezzo di un lavoro può esser necessario spostarsi temporaneamente su un branch, l'aiuto viene dall'uso del comando git stash. Stash salva nello stack lo stato "sporco" della tua working directory a cui tu potrai accedere successivamente. In ogni istante si può vedere l'elenco degli stash col comando git stash list, per spostarsi su uno stash particolare digitare git stash apply codice (dove codice può esser stash@{n) ) se non si inserisce il codice ci si sposta sull'ultimo stash. help

Tag E' una etichetta/segnalibro che si può dare ad uno specifico oggetto come un commit allo scopo di potervisi riferire in modo semplificato ed umano. Generalmente sono le etichette di versione. Un branch dopo esser creato evolve con successivi commit mentre un tag viene usato per identificare un punto cronologico per potervi accedere successivamente in modo facilitato. Utilizzo tipico dei tag è quello di contrassegnare un determinato rilascio o versione. Son di due tipi: lightweight (privi di info supplementari come data, nome utente), annotated (che associa info come data, nome utente, email utente.., es. git tag -a <TAG_NAME>). Tree Può essere usato in tre accezioni:  working tree: si riferisce alla working directory  tree object: si riferisce alla struttura dati usata da Git per memorizzare cartelle e sottocartelle  internal tree object è un oggetto usato da Git per controllare lo snapshot del commit Upstream Si riferisce al branch principale da cui un dato branch è stato ramificato e a cui eventualmente si possono inviare i cambiamenti (push). Git usa di default "origin" come nome remoto del repository upstream. Quando si fa un cambiamento questo dovrà esser inviato "indietro" facendo upstream in modo che anche gli altri ne abbiamo un aggiornamento dalla sorgente aggiornata (origin). Working copy Detta anche working directory o working tree, è la cartella dove ci sono i file del nostro progetto e sui quali lavoriamo. I files della working copy possono essere in uno dei seguenti stati:  Unmodified,  Untracked, sono tutti quei files che, dopo l'ultimo, son stati aggiunti o modificati. (Sono untracked anche i files 'ignorati')  Modified, se è stato modificato ma non ancora committato.  Staged, messo in un area, stage, e pronto per il commit.  Committed quando è al sicuro nel database locale. Traked sono i files presenti nell'ultimo commit e posson esser: unmodified, modified o staged.

Troubleshooting

Progetti

Mancata creazione di un nuovo progetto

Si cerca di aggiungere un nuovo progetto ad una collezione esistente ma dopo aver inserito nome e descrizione la pagina visualizza la clessidra ma non si aggiorna. Soluzione Probabilmente è fermo il servizio Azure DevOps Server Background Job Agent:

Mappa e Link

---

Azure DevOps Server | Source Control

---

Git - Dizionario | Dizionario

---

Parole chiave: