Tutorial Git per principianti

Lo sviluppo del software è un lavoro collaborativo. Come ingegnere del software, devi condividere il tuo lavoro con gli altri. Ma la condivisione del codice e della collaborazione può diventare complicata. È difficile tenere traccia di vari cambiamenti che si verificano durante il ciclo di vita di un software. Quindi i team di sviluppo si affidano agli strumenti di controllo della versione per aiutare con il processo di collaborazione del software. Git è uno degli strumenti di controllo della versione più importanti nel settore del software.

Mancia: In questo tutorial, imparerai come utilizzare i fondamenti di Git. Ogni sezione termina con alcune domande. Puoi leggere le domande prima di iniziare a leggere la sezione. Questo ti aiuterà a capire e prestare attenzione ai punti importanti.

Divertiti a imparare git!

GIT: una breve panoramica

Git è un sistema di controllo della versione distribuita. Tiene traccia di eventuali modifiche apportate ai tuoi file e cartelle. Rende più facile salvare il tuo lavoro in corso. Se c'è un problema, è possibile controllare facilmente una versione precedente del file o della cartella. Se necessario, puoi persino ripristinare l'intera base di codice a una versione precedente.

Lo sviluppo di Git è iniziato nel 2005. Il gruppo del kernel Linux utilizzato per mantenere il loro codice in bitkeeper, un sistema di controllo della versione distribuito proprietario. Tuttavia, Bitkeeper ha ritirato il suo uso gratuito del prodotto. Così Linus Torvalds, il creatore e lo sviluppatore principale di Linux, ha progettato un nuovo sistema di controllo della versione distribuita a source aperta che soddisferebbe i requisiti della comunità di sviluppo di Linux. E Git è nato.

Come sistema di controllo della versione distribuita, Git non richiede un'autorità centralizzata per tenere traccia del codice. I controlli della versione centralizzata più vecchi come CVS, SVN o Perforce richiedono ai server centrali per mantenere la cronologia dei cambiamenti. Git può tenere traccia di tutte le modifiche a livello locale e lavorare peer-to-peer. Quindi è più versatile dei sistemi centralizzati.

Domande:

• Perché dovresti usare Git?
• Qual è il vantaggio del controllo della versione distribuita?

Installazione di Git

Per i sistemi Linux che l'installazione di Git è facile. Se si utilizza una distribuzione basata su Debian come Ubuntu, puoi utilizzare APT Installa:

$ sudo apt install git-all

Per Fedora, Rhel o CentOS, puoi usare:

$ sudo dnf installa git-all

Puoi verificare se Git è stato installato, utilizzando il seguente comando:

$ git -version

Dovrebbe mostrarti la versione del git che hai installato, ad esempio:

Git versione 2.17.0

Una volta installato Git, è ora di impostare il tuo nome utente ed e -mail:

$ git config -utente global.Nomina "YourUserName"
$ git config -utente global.email "[email protected] "

È possibile verificare se le configurazioni sono state impostate correttamente utilizzando il seguente comando:

$ git config -list
utente.Nome = yourusername
utente.email = [email protected]

Mancia: È importante impostare l'utente.Nome e utente.e -mail perché queste configurazioni vengono utilizzate per tracciare le modifiche.

Domande

• Qual è il comando per l'installazione di git sul tuo sistema Linux?
• Perché dovresti impostare l'utente.Nome e utente.Configurazione e -mail? Come li imposti?

Comprensione concettualmente Git

Per usare Git, prima devi capire questi quattro concetti:

• Directory di lavoro
• Area di sosta
• Repository
• Repository remoto

La directory di lavoro, l'area di stadiazione e il repository sono locali per la macchina. Il repository remoto può essere qualsiasi altro computer o server. Pensiamo a questi concetti come quattro scatole che possono contenere documenti A1 standard.

Supponiamo che tu stia scrivendo un documento a mano su una carta A1 alla scrivania. Tieni questo documento nella casella della directory di lavoro. In una certa fase del tuo lavoro, decidi di essere pronto a conservare una copia del lavoro che hai già svolto. Quindi fai una fotocopia della tua carta attuale e lo metti nella scatola di stadiazione.

La scatola di stadiazione è un'area temporanea. Se decidi di scartare la fotocopia nella casella di gestione tempo.

Supponiamo di essere abbastanza sicuro di voler conservare il record permanente del documento che hai nella casella di messa in scena. Quindi si crea una fotocopia del documento della casella di stadiazione e lo spostalo nella casella del repository.

Quando lo sposti nella casella del repository, succedono due cose:

1. Un'istantanea del documento viene salvata in modo permanente.
2. Una voce del file di registro è effettuata con l'istantanea.

La voce del registro ti aiuterà a trovare quella particolare istantanea del tuo documento se ne hai bisogno in futuro.

Ora, nella casella del repository locale, hai un'istantanea del tuo lavoro e una voce di registro. Ma è disponibile solo per te. Quindi fai una copia del tuo documento di repository locale insieme al file di registro e lo metti in una scatola nella sala di fornitura dell'azienda. Ora chiunque nella tua azienda può venire e fare una copia del tuo documento e portarlo alla propria scrivania. La scatola nella sala di alimentazione sarebbe il repository remoto.

Il repository remoto è un po 'come condividere il tuo documento utilizzando Google Docs o Dropbox.

Domande:

• Puoi definire la directory di lavoro, la stadiazione, il repository e il repository remoto?
• Puoi disegnare come i documenti si spostano da una fase all'altra?

Il tuo primo repository git

Una volta installato Git, puoi iniziare a creare i tuoi repository Git. In questa sezione, inizializzerai il tuo repository git.

Supponiamo che tu stia lavorando a un progetto di sviluppo web. Creiamo una cartella chiamata Project_Helloworld e cambiamo nella directory:

$ mkdir Project_helloworld
$ CD Project_Hellowlerld

Puoi dire a Git di monitorare questa directory con il seguente comando:

$ git init

Dovresti vedere un output come questo:

Repository git vuoto inizializzato in/utenti/zakh/_work/apprendimento/git_tutorial/
Project_Helloworld/.idiota

Ora qualsiasi file e cartelle all'interno di Project_Helloworld verrà monitorato da Git.

Domande:

• Come si inizializza una directory per essere monitorato da Git?

Comandi GIT di base: stato, registro, aggiunta e commit

Il comando di stato mostra la condizione corrente della directory di lavoro e il comando log mostra la cronologia. Proviamo il comando di stato:

$ git status
Su Branch Master
Commit iniziale
Niente da commettere (crea/copiare file e utilizzare "git aggiungi" per tracciare)

L'output del comando di stato Git sta dicendo che sei sul ramo principale. Questo è il ramo predefinito che Git inizializza. (Puoi creare i tuoi rami. Maggiori informazioni sui rami più tardi). Inoltre, l'output sta dicendo che non c'è nulla da commettere.

Proviamo il comando di registro:

$ git log
Fatal: il tuo attuale "Master" non ha ancora commit

Quindi, è tempo di creare un po 'di codice. Creiamo un file chiamato indice.html:

Ciao mondo

È possibile utilizzare l'editor di testo per creare il file. Dopo aver salvato il file, controlla di nuovo lo stato:

$ git status
Su Branch Master
Commit iniziale
File non tracciati:
(Usa "git aggiungi ..." per includere in ciò che sarà impegnato)
indice.html
Nulla aggiunto per impegnarsi ma file non tracciati presenti (usa "git aggiungi" per tracciare)

Git ti sta dicendo che hai un file chiamato indice.HTML nella tua directory di lavoro non tracciata.

Assicuriamoci l'indice.HTML è monitorato. Dovrai utilizzare il comando ADD:

$ git aggiungi indice.html

In alternativa, potresti usare il "."Opzione per aggiungere tutto nella directory:

$ git aggiungi .

Ora controlliamo di nuovo lo stato:

$ git status
Su Branch Master
Commit iniziale
Modifiche da commettere:
(Usa "git rm -cached ..." per unstage)
Nuovo file: indice.html

Il verde indica che l'indice.Il file HTML viene monitorato da GIT.

Mancia: Come menzionato nelle istruzioni sopra, se si utilizza il comando:

$ git rm -indice Cached.html

Il tuo indice.HTML tornerà allo stato non tracciato. Dovrai aggiungerlo di nuovo per riportarlo alla messa in scena."

Controlliamo di nuovo il registro:

$ git log
Fatal: il tuo attuale "Master" non ha ancora commit

Quindi, anche se Git sta monitorando l'indice.html, non c'è ancora nulla nel repository git sul file. Commettiamo le nostre modifiche:

$ git commit -m "indice di impegno.html "
L'output dovrebbe assomigliare a questo:
[Master (root-commit) f136d22] indice di commissione.html
1 file modificato, 6 inserzioni (+)
Crea la modalità 100644 indice.html

Il testo all'interno delle citazioni dopo il "-m" è un commento che andrà nel file di registro. Puoi usare il commit git senza "-m", ma poi git aprirà un editor di testo che ti chiede di scrivere i commenti. È più facile semplicemente inserire i commenti direttamente sulla riga di comando.

Ora controlliamo il nostro file di registro:

$ git log
commit f136d22040ba81686c9522f4ff94961a68751af7
Autore: Zak H
Data: lunedì 4 giugno 16:53:42 2018 -0700
Indice di commissione.html

Puoi vedere che sta mostrando un commit. Hai commesso con successo le tue modifiche al tuo repository locale. Se vuoi vedere lo stesso registro in modo conciso, puoi usare il seguente comando:

$ git log --oneline
F136D22 INDICE DI COMMITTURA.html

Andando avanti, useremo questa forma del comando di registro perché rende più facile capire cosa sta succedendo.

Iniziamo a modificare l'indice.html. Apri l'indice.File HTML in un editor e modifica la linea "Hello World" in "Hello World! Sono io!"E salvalo. Se controlli di nuovo lo stato, vedrai che Git ha notato che stai modificando il file:

$ git status
Su Branch Master
Cambiamenti non messi in scena per commit:
(Usa "git aggiungi ..." per aggiornare ciò che verrà impegnato)
(Usa "Git Checkout - ..." per scartare le modifiche nella directory di lavoro)
modificato: indice.html
Nessuna modifica aggiunta al commit (usa "git add" e/o "git commit -a")

Il cambiamento è ancora nella tua directory di lavoro. Devi spingerlo nell'area di stadiazione. Usa il comando ADD che hai usato prima:

$ git aggiungi .

Controlla di nuovo lo stato:

$ git status
Su Branch Master
Modifiche da commettere:
(Usa "Git reset head ..." per spostarsi)
modificato: indice.html

Ora le tue modifiche sono nell'area di stadiazione. Puoi impegnarlo nel repository per la custodia permanente:

$ git commit -m "indice modificato.html per un messaggio più felice "
[Master 0586662] Indice modificato.html per un messaggio più felice
1 file modificato, 1 inserzione (+), 1 eliminazione (-)

Puoi controllare il registro per le tue modifiche permanenti:

$ git log --oneline
0586662 Indice modificato.html per un messaggio più felice
F136D22 INDICE DI COMMITTURA.html

In questa sezione, hai imparato a utilizzare i comandi di stato, registro, aggiungere e commit per tenere traccia dei tuoi documenti in GIT.

Domande:

• Cosa fa lo status di git?
• Cosa fa il registro Git?
• Cosa aggiunge Git Aggiungi?
• Cosa fa Git impegnati?

Tornando ai file più vecchi utilizzando il checkout

Quando si impegna un file in git, crea un hash unico per ogni commit. Puoi usarli come identificatori per tornare a una versione precedente.

Supponiamo che tu voglia tornare alla tua versione precedente di Index.html. Innanzitutto, diamo un'occhiata all'indice.HTML nella condizione corrente:

$ cat indice.html



Ciao mondo! Sono io!

Puoi vedere che hai la versione più recente ("Hello World! Sono io!"). Controlliamo il registro:

$ git log --oneline
0586662 Indice modificato.html per un messaggio più felice
F136D22 INDICE DI COMMITTURA.html

L'hash per la versione precedente era F136D22 ("Hello World"). È possibile utilizzare il comando checkout per arrivare a quella versione:

$ git checkout F136d22
Nota: controllando 'F136D22'.
Sei nello stato "Head Head". Puoi guardarti intorno, apportare modifiche sperimentali
e impegnarli e puoi scartare qualsiasi commissione che fai in questo stato
senza influire su qualsiasi filiale eseguendo un altro checkout.
Se si desidera creare una nuova filiale per conservare i commit crei, puoi
Fallo (ora o poi) usando -b di nuovo con il comando checkout. Esempio:
GIT Checkout -B
La testa è ora a F136D22 ... INDICE IMMEGNI.html

Se guardi il contenuto dell'indice.html, vedrai:

$ cat indice.html



Ciao mondo

Ha solo "Hello World". Quindi il tuo indice.HTML è cambiato nella versione precedente. Se controlli lo stato:

$ git status
Testa distaccata a F136d22
Niente da impegnare, la directory di lavoro pulita

Git ti sta fondamentalmente dicendo che la testa non è al più recente commit. Puoi tornare al commit più recente controllando la filiale master usando il seguente comando:

$ git checkout master
La posizione di testa precedente era F136D22 ... INDICE DI IMMEGGIO.html
Passato a Branch 'Master'

Ora se controlli lo stato:

$ git status
Su Branch Master
Niente da impegnare, la directory di lavoro pulita

L'avvertimento rosso è sparito. Inoltre, se controlli il tuo indice.HTML, dovresti tornare all'ultima versione:

$ cat indice.html


Ciao mondo! Sono io!

Il comando checkout ti porta in vari stati. Impareremo di più sul checkout nella prossima sezione.

Domande:

• Come si utilizza il comando Git Checkout per andare a una versione precedente di un file?
• Come si utilizza Git Checkout per tornare all'ultima versione del file?

Checkout, ramifica e fusione

La ramificazione è una delle migliori caratteristiche di Git. Ti aiuta a separare il tuo lavoro e sperimentare di più. In altri sistemi di controllo della versione, la ramificazione ha richiesto tempo e difficile. Git ha reso più facile la ramificazione e la fusione.

Come hai notato nel comando di stato, quando crei un nuovo repository git, sei nel ramo principale.

$ git status
Su Branch Master
Niente da impegnare, la directory di lavoro pulita

Supponiamo che tu stia creando un sito web per il tuo amico David. Vuoi riutilizzare il codice del tuo sito Web. La ramificazione è un'ottima soluzione. Chiamiamo la filiale David_Website.

Puoi emettere il seguente comando:

$ git branch David_website

È possibile utilizzare il seguente comando per vedere tutti i rami:

$ git branch -list
David_Website
* maestro

La stella (*) accanto al maestro significa che sei ancora nel ramo principale. Puoi controllare la filiale David_Website con il seguente comando:

$ git checkout David_website
Passato a Branch 'David_Website'

Ora se controlli di nuovo l'elenco delle filiali, vedi:

$ git branch -list
* David_Website
maestro

Quindi sei sul ramo David_Website.

Cambiamo l'indice.HTML da "Hello World! Sono io!”A“ Hello World! È David!"E poi metterlo in scena e impegnarlo:

$ git aggiungi .
$ git commit -m "sito Web modificato per David"

Se controlli i registri, dovresti vedere:

$ git log --oneline
345c0f4 Sito Web modificato per David
0586662 Indice modificato.html per un messaggio più felice
F136D22 INDICE DI COMMITTURA.html

E il tuo file indice dovrebbe apparire così:

$ cat indice.html



Ciao mondo! È David!

Ora controlliamo di nuovo la filiale principale:

$ git checkout master
Passato a Branch 'Master'

Se controlli lo stato e il registro:

$ git status
Su Branch Master
Niente da impegnare, la directory di lavoro pulita
$ git log --oneline
0586662 Indice modificato.html per un messaggio più felice
F136D22 INDICE DI COMMITTURA.html

Si noti che non hai il tuo terzo commit nel maestro. Perché quel commit è mantenuto solo nella filiale David_Website.

Questo è quello che è successo

Supponiamo che in questa fase decidi, non vuoi continuare il tuo sito web. Sarai solo lo sviluppatore di David. Quindi vuoi unire le modifiche al ramo David_Website al Master. Dal ramo principale, devi solo emettere i seguenti comandi (il comando di stato viene utilizzato per verificare se sei nel posto giusto):

$ git status
Su Branch Master
Niente da impegnare, la directory di lavoro pulita
$ git unire David_Website
Aggiornamento 0586662… 345c0f4
Avanti veloce
indice.html | 2 +-
1 file modificato, 1 inserzione (+), 1 eliminazione (-)

Mancia: Stai apportando modifiche da David_Website a Master. Devi essere sul maestro per raggiungere questo obiettivo.

Ora se controlli il registro sul maestro, vedi che il terzo commit è lì:

$ git log --oneline
345c0f4 Sito Web modificato per David
0586662 Indice modificato.html per un messaggio più felice
F136D22 INDICE DI COMMITTURA.html

Hai unito correttamente il ramo David_website in Master. E il tuo indice.HTML per la filiale Master sembra identico alla filiale David_Website:

$ cat indice.html



Ciao mondo! È David!

Puoi mantenere il ramo David_Website:

$ git branch -list
David_Website
* maestro

Oppure puoi eliminarlo:

$ git branch -d David_website
Branch eliminato David_Website (era 345C0f4).

Dopo la cancellazione, non dovresti più vedere la filiale David_Website:

$ git branch -list
* maestro

Mancia: Durante una fusione, se Git non può unire automaticamente, ti darà errori di conflitto. In tal caso, devi risolvere manualmente i problemi di unione.

Domande:

• Perché hai bisogno di ramificare?
• Come ramifichi e unisci file e cartelle?

Repository remoto

Fino ad ora, tutto il tuo lavoro è stato locale. Hai commesso le tue modifiche in un repository locale. Ma è tempo di condividere il tuo lavoro con il mondo.

Il repository remoto Git è fondamentalmente un'altra copia del repository locale a cui è possibile accedere. È possibile impostare un server e renderlo il repository remoto. Ma la maggior parte delle persone usa GitHub o Bitbucket per questo scopo. Puoi creare repository pubblici gratuitamente lì che possono essere accessibili da chiunque.

Creiamo un repository remoto su GitHub.

Innanzitutto, devi creare un account GitHub []. Una volta che hai l'account, crea un nuovo repository utilizzando il pulsante "Nuovo repository". Usa "Project_Website" come nome del repository (puoi scegliere qualcos'altro se vuoi).

Dovresti vedere una scheda Codice con istruzioni come queste:

... o crea un nuovo repository sulla riga di comando

Echo "# Project_Website" >> ReadMe.MD
git init
git aggiungi readme.MD
git commit -m "primo commit"
git remote aggiungi origine [email protected]: yourusername/project_website.idiota
Git Push -u Origin Master

Copia il seguente comando "Git Remote Aggiungi origine" ed eseguilo nella directory di lavoro:

$ git remote aggiungi origine [email protected]: yourusername/project_website.idiota

Nota: nel tuo caso, il tuo UsUname dovrebbe essere quello che hai usato per creare il tuo account GitHub.

Nel comando sopra, hai incaricato la posizione del repository remoto. Il comando sta dicendo a Git che la "origine" per la tua directory di lavoro project_helloworld sarà "[email protected]: yourusername/project_website.idiota".

Ora spingi il tuo codice dal ramo principale in origine (repository remoto):

$ git Push Origin Master
Contare gli oggetti: 9, fatto.
Compressione delta usando fino a 4 thread.
Oggetti di compressione: 100% (6/6), fatto.
Oggetti di scrittura: 100% (9/9), 803 byte | 0 byte/s, fatto.
Totale 9 (Delta 2), riutilizzato 0 (Delta 0)
Remoto: risoluzione di delta: 100% (2/2), fatto.
A [email protected]: yourusername/project_website.idiota
* [New Branch] Master -> Master

Se aggiorni il tuo browser in GitHub, dovresti vedere che l'indice.Il file HTML è lassù. Quindi il tuo codice è pubblico e altri sviluppatori possono controllare e modificare il codice sul repository remoto.

Come sviluppatore, lavorerai con il codice di altre persone. Quindi vale la pena provare a controllare il codice da Github.

Andiamo a una nuova directory in cui non hai nulla. Sul lato destro del repository GitHub, noterai il pulsante "clone o download". Se fai clic su di esso, dovrebbe darti un indirizzo SSH. Esegui il seguente comando con l'indirizzo SSH:

$ git clone [email protected]: yourusername/project_website.idiota

L'output dovrebbe apparire così:

$ git clone [email protected]: yourusername/project_website.idiota
Cloning in "Project_Website" ..
remoto: conteggio di oggetti: 9, fatto.
Remoto: oggetti di compressione: 100% (4/4), fatto.
Remoto: totale 9 (Delta 2), riutilizzato 9 (Delta 2), reuso da pacchetto 0
Ricevere oggetti: 100% (9/9), fatto.
Risoluzione dei delta: 100% (2/2), fatto.
Controllo della connettività ... fatto.

Creerà un progetto_website nella cartella pulita. Se entri, dovresti vedere l'indice.html dal tuo progetto_helloworld.

Quindi hai raggiunto quanto segue:

• Creato e apportato modifiche in Project_Helloworld
• Caricato il codice su GitHub in Project_Website
• Scaricato il codice da GitHub

Facciamo un altro file dalla nuova directory di lavoro Project_Website:

$ touch readme.MD
$ git aggiungi .
$ git commit -m "aggiunto readme.MD "
$ git Push Origin Master

Se aggiorni la pagina GitHub Project_Website, dovresti vedere il ReadMe.file md lì.

Nota: quando scarichi il codice da GitHub, la directory di lavoro conosce automaticamente l'origine. Non devi definirlo con il comando "Git Add Origin".

Domande:

• Perché devi utilizzare repository remoti?
• Come si imposta il repository locale corrente per connettersi al repository remoto?
• Come clone i repository remoti al tuo computer locale?

Conclusione

Puoi trovare ulteriori informazioni su tutti i comandi nei documenti GIT []. Anche se sono disponibili strumenti UI Git, la linea di comando è il modo migliore per padroneggiare Git. Ti darà una base più forte per il tuo lavoro di sviluppo.

Ulteriori studi:

• https: // git-scm.com/docs
• https: // git-scm.com/book/en/v2
• https: // git-scm.com/video