Invece di un'introduzione
Ciao futuro ingegnere software senior.Nozioni di base su Git
Git è un sistema di controllo della versione distribuito per il nostro codice. Perchè ne abbiamo bisogno? I team distribuiti necessitano di una sorta di sistema di gestione del lavoro. Necessario per tenere traccia dei cambiamenti che si verificano nel tempo. Cioè, passo dopo passo vediamo quali file sono cambiati e come. Ciò è particolarmente importante quando si analizza ciò che è stato fatto all'interno di un'attività: ciò rende possibile tornare indietro. Immaginiamo una situazione: c'era un codice funzionante, tutto andava bene, ma abbiamo deciso di migliorare qualcosa, modificarlo qui, modificarlo lì. Tutto andava bene, ma questo miglioramento ha interrotto metà della funzionalità e ha reso impossibile il lavoro. Allora, qual è il prossimo passo? Senza la Gita bisognerebbe stare seduti per ore e ricordare come tutto era originariamente. E quindi torniamo semplicemente al commit e il gioco è fatto. O cosa succederebbe se due sviluppatori apportassero modifiche al codice contemporaneamente? Senza Git sembra così: hanno copiato il codice dall'originale e hanno fatto quello che dovevano fare. Arriva il momento ed entrambi vogliono aggiungere le loro modifiche alla cartella principale. E cosa fare in questa situazione?.. Non oso nemmeno stimare il tempo per fare questo lavoro. Non ci saranno problemi del genere se usi Git.Installazione di Git
Installiamo Git sul tuo computer. Capisco che ognuno ha un sistema operativo diverso, quindi proverò a descriverlo per diversi casi.Installazione per Windows
Come al solito, devi scaricare il file exe ed eseguirlo. Qui è tutto semplice: clicca sul primo link di Google , installa e il gioco è fatto. Per lavoro utilizzeremo la console bash che forniscono. Per lavorare su Windows, è necessario eseguire Git Bash. Ecco come appare nel menu di avvio:
E questa è già una console in cui puoi lavorare. Per non accedere ogni volta alla cartella con il progetto per aprire git lì, puoi fare clic con il tasto destro del mouse sulla cartella per aprire la console con il percorso di cui abbiamo bisogno: 
Installazione per Linux
Di solito git è già installato e incluso nelle distribuzioni Linux, poiché è uno strumento originariamente scritto per sviluppare il kernel Linux. Ma ci sono situazioni in cui non c'è. Per verificarlo, è necessario aprire un terminale e digitare: git --version. Se c'è una risposta chiara, non è necessario installare nulla. Apri un terminale e installa. Lavoro su Ubuntu, quindi posso dirti cosa scrivere per questo: sudo apt-get install git. E questo è tutto: ora puoi usare Git in qualsiasi terminale.Installazione su macOS
Anche qui bisogna prima verificare se Git esiste già (vedi sopra, come su Linux). In caso contrario, il modo più semplice è scaricare la versione più recente. Se XCode è installato, Git verrà sicuramente installato automaticamente.Configurazione di Git
Git ha un'impostazione utente da cui verrà eseguito il lavoro. Questa è una cosa ragionevole e necessaria, perché quando viene creato un commit, Git prende esattamente queste informazioni per il campo Autore. Per impostare un nome utente e una password per tutti i progetti, è necessario inserire i seguenti comandi:
git config --global user.name ”Ivan Ivanov”
git config --global user.email ivan.ivanov@gmail.com
git config user.name ”Ivan Ivanov”
git config user.email ivan.ivanov@gmail.comUn po' di teoria...
Per rimanere in tema, è consigliabile aggiungere al messaggio qualche parola o azione nuova... Altrimenti non ci sarà nulla di cui parlare. Naturalmente, questo è un po' di gergo e una copia dell'inglese, quindi aggiungerò i significati in inglese. Quali parole e azioni?
- archivio git;
- impegnarsi (impegnarsi);
- ramo;
- unire;
- conflitti;
- tiro;
- spingere;
- come ignorare alcuni file (.gitignore).
Stati in Git
La Gita ha diversi stati che devono essere compresi e ricordati:- non tracciato;
- modificata;
- preparato (messo in scena);
- impegnato.
Cosa significa?
Questi sono gli stati in cui si trovano i file del nostro codice. Cioè, il loro percorso di vita di solito assomiglia a questo:- Un file creato e non aggiunto al repository sarà in uno stato non tracciato.
- Apportiamo modifiche ai file che sono già stati aggiunti al repository Git: sono nello stato modificato.
- Dai file che abbiamo modificato, selezioniamo solo quelli (o tutti) di cui abbiamo bisogno (ad esempio, non abbiamo bisogno di classi compilate) e queste classi con modifiche cadono nello stato messo in scena.
- Viene creato un commit dai file preparati dallo stato messo in scena e va nel repository Git. Successivamente, lo stato graduale è vuoto. Ma modificato potrebbe contenere ancora qualcosa.
Cos'è un impegno
Un commit è l'oggetto principale nel controllo della versione. Contiene tutte le modifiche successive a quel commit. I commit sono collegati tra loro come un elenco collegato singolarmente. Vale a dire: c'è il primo commit. Quando viene creato un secondo commit, (il secondo) sa che viene dopo il primo. E in questo modo puoi tenere traccia delle informazioni. Il commit ha anche le proprie informazioni, i cosiddetti metadati:- un identificatore di commit univoco tramite il quale puoi trovarlo;
- il nome dell'autore del commit che lo ha creato;
- data di creazione del commit;
- un commento che descrive cosa è stato fatto durante questo commit.
Cos'è un ramo
Un ramo è un puntatore a un commit. Poiché un commit sa quale commit lo ha preceduto, quando un ramo punta a un commit, anche tutti quelli precedenti fanno riferimento ad esso. In base a ciò possiamo dire che possono esserci tanti rami che puntano allo stesso commit. Il lavoro avviene sui rami, quindi quando viene creato un nuovo commit, il ramo sposta il puntatore sul commit più recente.
Iniziare con Git
Puoi lavorare solo con un repository locale o con uno remoto. Per elaborare i comandi necessari, puoi utilizzare solo il repository locale. Memorizza tutte le informazioni solo localmente nel progetto nella cartella .git. Se parliamo di remoto, tutte le informazioni vengono archiviate da qualche parte su un server remoto: solo una copia del progetto viene archiviata localmente, le cui modifiche possono essere inviate (git push) al repository remoto. Qui e oltre discuteremo di come lavorare con git nella console. Naturalmente, puoi utilizzare alcune soluzioni grafiche (ad esempio, in Intellij IDEA), ma prima devi capire quali comandi vengono eseguiti e cosa significano.Lavorare con Git in un repository locale
Successivamente, ti suggerisco di seguire tutti i passaggi che ho eseguito mentre leggevi l'articolo. Ciò migliorerà la comprensione e la memorizzazione del materiale. Quindi buon appetito :) Per creare un repository locale, è necessario scrivere:
git init
Ciò creerà una cartella .git nella posizione in cui si trova la console. .git è una cartella che memorizza tutte le informazioni sul repository Git. Non è necessario eliminarlo ;) Successivamente, i file vengono aggiunti a questo progetto e il loro stato diventa Non tracciato. Per vedere qual è lo stato attuale dei lavori, scrivi:
git status
Siamo nel ramo maestro, e finché non ci sposteremo in un altro, tutto rimarrà così. In questo modo puoi vedere quali file sono stati modificati ma non ancora aggiunti allo stato messo in scena. Per aggiungerli allo stato staged, devi scrivere git add. Potrebbero esserci diverse opzioni qui, ad esempio:
- git add -A - aggiunge tutti i file dallo stato staged;
- git aggiungi . - aggiungi tutti i file da questa cartella e tutti quelli interni. Sostanzialmente uguale al precedente;
- git add <nomefile> - aggiunge solo un file specifico. Qui puoi utilizzare le espressioni regolari per aggiungere secondo alcuni schemi. Ad esempio, git add *.java: ciò significa che devi aggiungere solo i file con l'estensione java.
git add *.txt
git status
Da ciò possiamo vedere che l'espressione regolare ha funzionato correttamente e ora test_resource.txt è in uno stato graduale. E infine, l'ultima fase (con un repository locale, con uno remoto ce ne sarà uno in più ;)) - commit e creazione di un nuovo commit:
git commit -m “all txt files were added to the project”
Successivamente, c'è un ottimo comando per esaminare la cronologia dei commit di un ramo. Usiamolo:
git log
Qui puoi già vedere che è apparso il nostro primo commit con il testo che abbiamo trasferito. È molto importante capire che il testo che passiamo deve definire nel modo più accurato possibile cosa è stato fatto durante questo commit. Ciò aiuterà molte volte in futuro. Un lettore curioso che non si è ancora addormentato potrebbe dire: cosa è successo al file GitTest.java? Ora lo scopriremo, usalo per questo:
git status
Come possiamo vedere, rimane nello stato non tracciato e sta aspettando dietro le quinte. O forse non vogliamo aggiungerlo affatto al progetto? A volte succede. Successivamente, per renderlo più interessante, proviamo a modificare il nostro file di testo test_resource.txt. Aggiungiamo del testo lì e controlliamo lo stato:
git status
Qui puoi vedere chiaramente la differenza tra i due stati: non tracciato e modificato. GitTest.java è in stato non tracciato e test_resource.txt è in stato modificato. Ora che ci sono già file nello stato modificato, possiamo osservare le modifiche che sono state apportate ad essi. Questo può essere fatto usando il comando:
git diff
Cioè, puoi vedere chiaramente qui che ho aggiunto hello world! al nostro file di testo. Aggiungi modifiche al file di testo e conferma:
git add test_resource.txt
git commit -m “added hello word! to test_resource.txt”
git log
Come puoi vedere, ci sono già due commit. Allo stesso modo aggiungiamo GitTest.java. Ora nessun commento, solo comandi:
git add GitTest.java
git commit -m “added GitTest.java”
git status
Lavorare con .gitignore
È chiaro che vogliamo archiviare solo il codice sorgente e nient'altro nel repository. Cos'altro potrebbe essere? Come minimo, classi e/o file compilati che creano ambienti di sviluppo. Affinché Git li ignori, è necessario creare un file speciale. Facciamo questo: creiamo un file nella root del progetto chiamato .gitignore, e in questo file ogni riga sarà un pattern da ignorare. In questo esempio, git ignore sarebbe simile a questo:
```
*.class
target/
*.iml
.idea/
```- la prima riga è ignorare tutti i file con estensione .class;
- la seconda riga consiste nell'ignorare la cartella di destinazione e tutto ciò che contiene;
- la terza riga ignora tutti i file con estensione .iml;
- La quarta riga consiste nell'ignorare la cartella .idea.
git status
Chiaramente, non vogliamo accidentalmente (se usiamo git add -A) aggiungere una classe compilata al progetto. Per fare questo creiamo un file .gitignore e aggiungiamo tutto quello che è stato descritto prima: 
Ora aggiungiamo git ignore al progetto con un nuovo commit:
git add .gitignore
git commit -m “added .gitignore file”
git status
Tutto è chiaro) Git ignora +1)
Lavorare con rami e simili
Naturalmente, lavorare in una filiale è scomodo per uno e impossibile quando c'è più di una persona nel team. C'è una filiale per questo. Come ho detto prima, un ramo è semplicemente un puntatore mobile ai commit. In questa parte esamineremo il lavoro in diversi rami: come unire le modifiche da un ramo all'altro, quali conflitti possono sorgere e molto altro. Per vedere l'elenco di tutti i rami presenti nel repository e capire su quale ci si trova è necessario scrivere:
git branch -a
Puoi vedere che abbiamo solo un ramo master e l'asterisco davanti ad esso dice che ci siamo. A proposito, per sapere su quale ramo ci troviamo, possiamo anche utilizzare il controllo dello stato (git status). Successivamente, ci sono diverse opzioni per creare rami (forse ce ne sono altre, io uso queste):
- creare una nuova filiale in base a quella in cui ci troviamo (99% dei casi);
- creare un ramo basato su un commit specifico (1%).
Crea un ramo basato su un commit specifico
Faremo affidamento sull'identificatore di commit univoco. Per trovarlo scriviamo:
git log
Ho evidenziato il commit con il commento “aggiunto ciao mondo...”. Ha un identificatore univoco: "6c44e53d06228f888f2f454d3cb8c1c976dd73f8". Voglio creare un ramo di sviluppo a partire da questo commit. Per questo scriverò:
git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8
git status
git log
Ed è vero: si è scoperto che abbiamo due commit. A proposito, un punto interessante: non c'è ancora alcun file .gitignore in questo ramo, quindi il nostro file compilato (GitTest.class) è ora evidenziato nello stato non tracciato. Ora possiamo rivedere nuovamente i nostri rami scrivendo:
git branch -a
Si può vedere che ci sono due rami - master e sviluppo - e ora siamo allo sviluppo.
Crea un ramo basato su quello attuale
Il secondo modo per creare un ramo è costruirne un altro. Voglio creare un ramo basato sul ramo principale, quindi devo prima passare ad esso e il passo successivo è crearne uno nuovo. Guardiamo:- git checkout master: passa al ramo master;
- git status: controlla se è sul master.
Qui puoi vedere che ci siamo spostati nel ramo master, git ignore funziona già qui e la classe compilata non appare più come non tracciata. Ora creiamo un nuovo ramo basato sul ramo principale:
git checkout -b feature/update-txt-files
Se hai qualche dubbio che questo ramo non sarà uguale a master, puoi verificarlo facilmente scrivendo git log e guardando tutti i commit. Dovrebbero essercene quattro.
Risolvere i conflitti
Prima di capire cos'è un conflitto, dobbiamo parlare di fusione (unione) di un ramo in un altro. Questa immagine può mostrare il processo quando un ramo viene unito a un altro:
ovvero esiste un ramo principale. Ad un certo punto, ne viene creato uno secondario, in cui si verificano i cambiamenti. Una volta terminato il lavoro, è necessario unire un ramo in un altro. Non descriverò varie caratteristiche: voglio trasmettere solo la comprensione nell'ambito di questo articolo e, se necessario, scoprirai tu stesso i dettagli. Quindi, nel nostro esempio, abbiamo creato il ramo feature/update-txt-files. Come è scritto nel nome della filiale, aggiorneremo il testo. 
Ora devi creare un nuovo commit per questo argomento:
git add *.txt
git commit -m “updated txt files”
git log
Ora, se vogliamo unire il ramo feature/update-txt-files in master, dobbiamo andare su master e scrivere git merge feature/update-txt-files:
git checkout master
git merge feature/update-txt-files
git log
Di conseguenza, ora anche il ramo master ha un commit che è stato aggiunto a feature/update-txt-files. Questa funzionalità viene aggiunta in modo da poter eliminare il ramo della funzionalità. Per fare questo scriviamo:
git branch -D feature/update-txt-files
git checkout -b feature/add-header
... делаем изменения в файле
git add *.txt
git commit -m “added header to txt”
Vai al ramo master e aggiorna anche questo file di testo sulla stessa riga del ramo feature:
git checkout master
… обновor test_resource.txt
git add test_resource.txt
git commit -m “added master header to txt”
git merge feature/add-header
E qui possiamo vedere che Git non può decidere autonomamente come unire questo codice e dice che dobbiamo prima risolvere il conflitto e solo dopo effettuare un commit. Ok, apriamo il file contenente il conflitto in un editor di testo e vediamo: 
Per capire cosa ha fatto git qui, devi ricordare cosa abbiamo scritto dove e confrontare:
- tra “<<<<<<< HEAD” e “=======” ci sono le modifiche principali presenti in questa riga nel ramo principale.
- tra “=======” e “>>>>>>> feature/add-header” ci sono modifiche che erano nel ramo feature/add-header.
Vediamo lo stato delle modifiche, la descrizione sarà leggermente diversa. Non ci sarà uno stato modificato, ma non unito. Quindi potremmo tranquillamente aggiungere un quinto stato... Ma credo che questo non sia necessario, vediamo:
git status
Eravamo convinti che si trattasse di un caso diverso, insolito. Continuiamo:
git add *.txt
Nella descrizione noterai che suggeriscono solo di scrivere git commit. Ascoltiamo e scriviamo:
git commit
E questo è tutto: abbiamo fatto così: abbiamo risolto il conflitto nella console. Naturalmente, negli ambienti di sviluppo puoi farlo un po' più facilmente, ad esempio, in Intellij IDEA tutto è impostato così bene che puoi eseguire tutte le azioni necessarie al suo interno. Ma l'ambiente di sviluppo fa molte cose dietro il cofano e spesso non capiamo cosa sia successo esattamente lì. E quando non c’è comprensione, possono sorgere problemi.
Lavorare con repository remoti
L'ultimo passaggio è comprendere alcuni altri comandi necessari per lavorare con un repository remoto. Come ho già detto, un repository remoto è un luogo in cui è archiviato il repository e da cui è possibile clonarlo. Quali tipi di repository remoti esistono? Ci sono tonnellate di esempi:-
GitHub è il più grande repository per repository e sviluppo collaborativo. L’ho già descritto negli articoli precedenti.
Iscriviti al mio account Github . Spesso espongo lì il mio lavoro negli ambiti che studio durante il mio lavoro. -
GitLab è uno strumento per il ciclo di vita DevOps basato sul Web open source che fornisce un sistema di gestione del repository di codice per Git con la propria wiki, sistema di tracciamento dei problemi , pipeline CI/CD e altre funzionalità.
Dopo la notizia che Microsoft ha acquistato GitHub, alcuni sviluppatori hanno duplicato il loro lavoro in GitLab. -
BitBucket è un servizio web per l'hosting di progetti e il loro sviluppo congiunto, basato sul sistema di controllo della versione Mercurial e Git. Un tempo aveva un grande vantaggio rispetto a GitHub in quanto aveva repository privati gratuiti. L'anno scorso anche GitHub ha reso questa funzionalità disponibile a tutti gratuitamente.
-
E così via…
git clone https://github.com/romankh3/git-demo
git pull
Nel nostro caso, non è cambiato nulla in remoto, quindi la risposta è: già aggiornato. Ma se apporto alcune modifiche al repository remoto, quello locale verrà aggiornato dopo averle estratte. E infine, l'ultimo comando è inviare i dati al repository remoto. Quando abbiamo fatto qualcosa localmente e vogliamo trasferirlo su un repository remoto, dobbiamo prima creare un nuovo commit localmente. Per fare ciò, aggiungiamo qualcos'altro al nostro file di testo: 
ora è una cosa comune per noi: creiamo un commit per questo argomento:
git add test_resource.txt
git commit -m “prepated txt for pushing”
git push
Questo è tutto quello che volevo dirti. Grazie per l'attenzione. Iscriviti al mio account GitHub , dove pubblico diversi interessanti progetti di esempio da ciò che studio e utilizzo al lavoro.
link utili
- Il documento ufficiale su Git è in russo . Lo consiglio come guida di riferimento.
- Idiota
GO TO FULL VERSION