Si fa presto a dire patta, mai credere ciecamente a quello che sentenzia il signor Rezzonico: ovvero quando la comprensione di GIT viene prima dell’ uso dei comandi sparati sulla Shell Bash

Partiamo subito con web developer Umbria dalla http://www.chessgames.com/perl/chessgame?gid=1303535 dove una delle varianti porta a un certo punto alla posizione qui a lato e l’autore che scrive di questa partita in un libro afferma che il bianco con la spettacolare 1 Ah1!! avrebbe portato a casa il mezzo punto ma dopo 1..Th3 2 Af3 Tg3 non prende matto chiede web developer Umbria, episodio narrato nei dettagli da Bagnoli nel suo scacchi matti 3 e mezzo. E ora liquidata la parte gastronomica scacchistica passiamo al lavoro con l’obiettivo di elevare le nostre competenze. Hai provato ad approcciarti a GIT e non ci hai capito una acca? Hai provato a fare dei rituali per cercare di capire che cosa é un Branch o una Commit o una Repository ma tutto quello che hai ottenuto pagando dalla maga é solo un forte mal di testa? Niente paura ci pensa web developer Umbria! Certamente abbiamo a che fare con un problema didattico perché prima dovresti avere uno schema chiaro della struttura del sogtware GIT (tradotto sta per idiota sottointendendo dunque che con questo servizio di hosting dedicato che hai dei vantaggi rispetto alla gestione dei server come costi avrai sempre una copia del tuo software free condivisibile) e solo dopo cimentarti da SHELL BASH da windows o altro sistema operativo. GitHub è di gran lunga il più grande hosting Git di progetti open source ed è anche uno dei pochi che offre sia un hosting pubblico sia privato.Sicuramente avrai sentito parlare di SUBVERSION (SVN) quel software professionale che teneva traccia di tutti i cambiamenti del tuo progetto in una architettura client-server ma qui parliamo piuttosto di una formula PEER-TO-PEER che ha una funzione di ponte tra la tua directory (ecco che cosa é una REPOSITORY) in locale e l’area clonata sulla nuvola GIT che tiene traccia di tutte le ramificazioni (BRANCH) e i nodi di aggiornamento modifiche file (la famosa COMMIT) durante il proseguimento del tuo progetto. Questa lunga dissertazione curata da CEO Faraoni Enrico Umbriaway Consulting ti aiuta a iniziare con Git e ti dà una comprensione generale dei concetti fondamentali di Git. Repository, Albero di lavoro, Commit. In primo luogo, dobbiamo introdurre alcuni termini specifici per Git che possono avere significati diversi in altri sistemi di controllo di versione come Subversion. I sistemi di controllo di versione centralizzati classici come Subversion (SVN) dispongono di cosiddetti “copie di lavoro”, ognuna delle quali corrisponde ad esattamente a un repository. Le copie di lavoro SVN possono corrispondere all’intero repository o solo ad alcune parti. In Git, d’altra parte, si tratta sempre di repository (locali). L’albero di lavoro di Git è la directory in cui è possibile modificare i file ed è sempre parte di un repository. I cosiddetti repository nudo, usati sui server come repository centrali, non dispongono di un albero di lavoro. Supponiamo di avere tutti i file correlati al progetto in una directory C: \ my-project. Quindi questa directory rappresenta il repository, che consiste della struttura di lavoro (contenente tutti i file da modificare) e dei metadati repository allegati che si trova nella directory C: \ my-project \ .git. Come per tutti i sistemi di controllo delle versioni, evidenzia web developer Umbria, esiste tipicamente un repository centrale che contiene i file di progetto. Per creare un repository locale, devi clonare il repository centrale remoto. Quindi il repository locale è collegato al repository remoto, che, dal punto di vista del repository locale, è denominato origine. La fase di clonazione è analoga alla prima verifica SVN per ottenere una copia di lavoro locale. Dopo aver creato il repository locale che contiene tutti i file di progetto dall’origine, è possibile ora apportare modifiche ai file nella struttura di lavoro e impegnare queste modifiche. Saranno archiviati solo nel repository locale, in modo da non avere neanche bisogno di accedere a un repository remoto quando si impegna. In seguito, dopo aver commesso un paio di modifiche, puoi spingerli sul repository remoto. Altri utenti che hanno i propri cloni del repository di origine possono tirare dal repository remoto per ottenere i cambiamenti agognati. I rami possono essere utilizzati per memorizzare serie indipendenti di impegni nel repository, ad esempio per risolvere i bug per un progetto software rilasciato, contemporaneamente sviluppando nuove funzionalità per la prossima versione del progetto. Git distingue tra due tipi di rami: rami locali e rami remote. Nel repository locale puoi creare quanti rami locali ti piace. I rami a distanza, d’altro canto, sono rami locali del repository di origine. In altre parole: la clonazione di un repository remoto clona tutti i suoi rami locali che vengono poi memorizzati nel repository locale come rami remote. Non puoi lavorare direttamente su rami remoti, ma devi creare rami locali, che sono “collegati” ai rami remoti. Il ramo locale viene chiamato ramo di tracciamento e il corrispondente ramo remoto del ramo remoto. Il ramo principale locale predefinito creato da Git viene chiamato master, che è analogo al tronco di SVN. Quando si clona un repository remoto, il master traccia l’origine / master del ramo remoto. Quando spingete le modifiche dal tuo ramo locale al repository di origine, queste modifiche verranno propagate anche al ramo tracciato (remoto). Allo stesso modo, quando prelevi i cambiamenti dal repository di origine, queste modifiche verranno memorizzate anche nel ramo tracciato (remoto) del repository locale. Per ottenere le modifiche del ramo tracciato nel tuo ramo locale, le modifiche remote devono essere unite dal ramo tracciato. Questo può essere fatto direttamente quando si richiama il comando Pull in SmartGit o successivamente richiamando esplicitamente il comando Merge. Un’alternativa al comando Merge è il comando Rebase. Il metodo da utilizzare da Pull (Unione o Rebase) può essere configurato in Repository | Settings nella scheda Pull. I rami sono solo indicatori da connettere. Ogni ramo è semplicemente un puntatore denominato a un commit. Un particolare puntatore unico per ogni repository è il HEAD che punta al commit lo stato dell’albero di lavoro attualmente corrisponde. Il HEAD non può solo indicare un commit, ma anche un ramo locale, che in sé punta a un commit. Effettuare le modifiche creeranno un nuovo impegno in cima al commit o al ramo locale che il HEAD sta puntando. Se il capo indica un ramo locale, il puntatore del ramo verrà spostato in avanti al nuovo commit; Così il capo indirizzerà indirettamente anche il nuovo impegno. Se il HEAD indica un commit, la stessa HEAD viene spostata in avanti al nuovo commit. Un commit è l’equivalente Git di una revisione SVN, cioè una serie di modifiche memorizzate nel repository insieme a un messaggio di commit. Il comando Commit viene utilizzato per memorizzare le modifiche dell’albero di lavoro nel repository locale creando così un nuovo commit. Poiché ogni repository inizia con un commit iniziale e ogni successivo commit è direttamente basato su uno o più genitori, un repository forma un “grafico commit” (o tecnicamente parlando, un grafico diretto dei nodi di commit), con ogni commit che è Un discendente diretto o indiretto del commit iniziale. Quindi, un commit non è solo un insieme di modifiche, ma, a causa della sua posizione fissa nel grafico di commit, rappresenta anche uno stato di repository unico. Gli impegni normali hanno esattamente un commit di un genitore, il commit iniziale non ha alcun genitore impegnato e le cosiddette fusioni connettono due o più genitori impegnati. L’Indice è una cache intermedia per la preparazione di un commit. Con SmartGit puoi usare pesantemente l’Indice oppure ignorare completamente la sua presenza – è tutto su di te. Il comando Stage consente di salvare i contenuti di un file dall’albero di lavoro nell’Indice, sottolinea web developer Umbria. Se si esegue un file precedentemente controllato dalla versione, ma ora è mancante nell’albero di lavoro, verrà contrassegnato per la rimozione. Utilizzando esplicitamente il comando Remove è lo stesso effetto, come si può abituare a SVN. Se si seleziona un file con modifiche all’Indice, l’invocazione di Commit vi darà l’opzione di eseguire tutte le modifiche effettuate. Se hai impostato alcune modifiche di file e ha successivamente modificato nuovamente il file dell’albero di lavoro, puoi utilizzare il comando Disdetta per ripristinare il contenuto del file dell’albero di lavoro alle modifiche in fase memorizzate nell’Indice o al contenuto del file memorizzato nel repository(HEAD). Quando disattivando i cambiamenti precedentemente eseguiti, i cambiamenti pianificati verranno spostati all’albero di lavoro, se quest’ultimo non è stato modificato nel frattempo, in caso contrario le modifiche pianificate verranno perse. In entrambi i casi, l’indice verrà ripristinato nel contenuto del file HEAD. La visualizzazione delle modifiche della finestra principale di SmartGit può mostrare le modifiche tra HEAD e l’indice, oppure tra l’indice e lo stato dell’albero di lavoro del file selezionato. Puoi passare da entrambe le visualizzazioni cliccando il pulsante HEAD sinistro o il pulsante destro dell’albero di lavoro. I separatori di linea rilevati e attesi sono visualizzati nel titolo della visualizzazione Modifiche. I singoli cambiamenti o le modifiche della linea interna possono essere messe in scena e non presenti (se i separatori di linea non sono mescolati). L’Editor indice mostra una vista a 3 ante di HEAD, Index e Tree Working. L’indice e lo stato dell’albero di lavoro di un file possono essere modificati liberamente, ad es. Per aggiungere ulteriori modifiche all’Indice che non sono disponibili nell’Albero di lavoro. Ci sono alcune situazioni particolari in cui gli impegni non possono essere eseguiti, ad esempio quando una fusione è fallita a causa di un conflitto. In questo caso, è possibile completare la fusione in due modi: oppure risolvendo il conflitto, impostando le modifiche del file e eseguendo il commit sulla radice dell’albero di lavoro o ripristinando l’intera struttura di lavoro. Con web developer Umbria in uno dei prossimi articoli prenderemo in considerazione una guida analoga per l’uso specifico dei comandi.

Annunci

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google photo

Stai commentando usando il tuo account Google. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...