Sistemes de control de versions

Disposar d’un sistema de control de versions resulta imprescindible a l’hora d’afrontar la implementació de qualsevol aplicació mínimament complexa, ja que proporcionen als desenvolupadors l’opció de desfer canvis i tornar a versions anteriors del desenvolupament fàcilment.

Aquests sistemes estan pensats per treballar principalment amb fitxers de codi, és a dir, fitxers de text pla i altres tipus de continguts com imatges, vídeos o fitxers d’àudio normalment no es desen utilitzant el mateix sistema (el conjunt de canvis a cada línia) sinó que s’han de desar sencers.

Això en determinats tipus de projectes pot presentar un problema, ja que els requeriments d’espai pel sistema de control de versions poden ser molt grans i poden produir-se errors si no es té en compte.

El lloc on es desen els conjunts de canvis s’anomena repositori. Normalment es tracta d’un directori on es troben tots els fitxers del projecte i les dades amb l’historial de canvis, cosa que permet fer una còpia d’aquests fitxers en qualsevol moment concret, determinat pel seu número de versió. Cada cop que s’afegeixen canvis al repositori es crea una nova entrada a l’historial de canvis on s’inclou el número de versió i a partir d’aquest número és possible restaurar aquest estat.

Cal distingir entre els repositoris locals i els repositoris remots. Segons l’eina utilitzada, un repositori remot es troba en un servidor independent o es tracta d’un repositori local d’un altre equip. En qualsevol dels dos casos el concepte més important és que els repositoris poden sincronitzar-se de manera que diferents usuaris poden treballar en el mateix projecte i els mateixos fitxers simultàniament.

L’estructura d’un sistema de control de versions es pot interpretar com un arbre, on el tronc és on es pugen els canvis realitzats a l’aplicació i poden crear-se branques per treballar en noves característiques o solucions d’errors que més endavant s’afegiran al tronc. D’aquesta manera es pot treballar de forma segura en una branca sense que els canvis del treball en progrés afectin la branca principal.

Hi ha diversos casos en què una branca no torna a fusionar-se amb el tronc. Per exemple, es podria crear una branca per comprovar si una funcionalitat és viable o si una implementació diferent d’una funcionalitat existent millora el rendiment i, segons el resultat, fer la fusió amb la branca principal o descartar-la.

En altres casos pot crear-se una branca per mantenir els canvis d’una versió anterior (per exemple, la versió 1 del programari) mentre que al tronc es treballa amb una nova versió (per exemple, la versió 2). D’aquesta manera, tot i que a la branca principal es treballa amb una nova versió, si es detecten errors a la versió 1 poden solucionar-se i pujar aquests canvis a la branca corresponent a la versió 1 (per distribuir-los als clients que encara utilitzin aquesta versió).

No hi ha límit en el nombre de branques que poden crear-se. Per exemple, un programari podria tenir 4 branques per mantenir al mateix temps 4 versions diferents. A la figura podeu veure la representació d’un repositori on la línia de color gris és el tronc i les línies blava, vermella, groga i verda representen diferents branques.

Segons la seva arquitectura, els sistemes de control de versions poden dividir-se en els següents tipus:

• Sistemes centralitzats: fan servir una arquitectura client-servidor on tots els clients connecten amb el servidor per pujar o baixar els canvis, i l’equip local no guarda cap historial dels canvis.
• Sistemes distribuïts o descentralitzats: cada usuari té una còpia completa de tots els fitxers, l’historial de canvis i les pujades i baixades es realitzen entre els repositoris de cada usuari per sincronitzar-se entre ells.

Els sistemes centralitzats presenten l’avantatge de reduir el pes del projecte en els clients, ja que aquests només contenen una còpia dels fitxers i no dels canvis anteriors. Per contra, si falla el servidor cap dels clients podrà ni baixar els canvis ni pujar els nous. En el pitjor dels casos, si es perden les dades del servidor, es perdria tota la informació del repositori (si no hi ha còpia de seguretat).

En el cas dels sistemes distribuïts, si un client falla no hi ha cap problema, perquè pot recuperar-se el repositori complet juntament amb l’historial de canvis de qualsevol altre equip, de manera que només es perdria la informació no pujada des del client que ha fallat. L’inconvenient és que com que no hi ha un servidor central s’han de sincronitzar tots els repositoris entre ells o seleccionar un repositori com a central i fer que tots els repositoris facin servir el mateix per pujar i baixar els canvis.

Actualment, l’opció més popular és una mescla entre els dos sistemes: utilitzar un servidor central com GitHub, ja que es tracta d’una plataforma molt segura, i fer servir als clients un sistema distribuït (Git).

Una altra característica important per diferenciar entre tipus de controls de versions és el sistema de concurrència utilitzat:

• Fusió (merge): quan es produeix un conflicte perquè s’han fet canvis sobre un fitxer que ha estat modificat, es resol fusionant els fitxers (automàticament o manualment).
• Bloqueig (lock): quan un usuari modifica un fitxer, aquest es bloqueja de manera que cap altre usuari pot modificar-lo.

Cal tenir en compte que alguns dels sistemes de control de versions ofereixen totes les opcions, és a dir, poden utilitzar-se com a sistema centralitzat o distribuït i permetre l’ús dels models de concurrència de fusió i de bloqueig.

Cal tenir en compte que no tots els sistemes de control de versions utilitzen els mateixos termes per referir-se als mateixos conceptes. Per aquest motiu és important familiaritzar-se amb la terminologia. A continuació, trobareu una llista amb el nom en català dels termes més comuns i el nom o noms en anglès relacionats:

• Repositori (repository o depot): fa referència al lloc on es guarden els fitxers actuals i l’històric de canvis.
• Tronc (trunk o master): és la branca principal d’un repositori de la qual surten la resta de branques.
• Branca (branch): és una bifurcació del tronc o branca mestra de l’aplicació que conté una versió independent de l’aplicació i a la qual poden aplicar-se canvis sense que afectin ni el tronc ni altres branques.
• Cap (head o tip): fa referència a la versió més recent d’una determinada branca o del tronc. El tronc i cada branca tenen el seu propi cap, però per referir-se al cap del tronc de vegades s’utilitza el terme HEAD, en majúscules.
• Còpia de treball (working copy): fa referència a la còpia local dels fitxers que s’han copiat del repositori, que és sobre la qual es fan els canvis (és a dir, s’hi treballa, d’aquí el nom) abans d’afegir aquests canvis al repositori.
• Bifurcació (fork): consisteix a crear un nou repositori a partir d’un altre. Aquest nou repositori, al contrari que en el cas de la clonació, no està lligat al repositori original i es tracta com un repositori diferent.
• Clonar (clone): consisteix a crear un nou repositori que és una còpia idèntica d’un altre, ja que conté les mateixes revisions.
• Pujar (commit o check in): és afegir els canvis locals al repositori. Cal destacar que no els envia al servidor; els canvis queden emmagatzemats al repositori local que s’ha de sincronitzar.
• Baixar (check out): és copiar a l’àrea de treball local una versió des d’un repositori local, un repositori remot o una branca diferent.
• Pull: és l’acció que copia els canvis d’un repositori (habitualment remot) en el repositori local. Aquesta acció pot provocar conflictes.
• Push o fetch: són accions utilitzades per afegir els canvis del repositori local a un altre repositori (habitualment remot). Aquesta acció pot provocar conflictes.
• Canvi (change o diff): representa una modificació concreta d’un document sota el control de versions.
• Sincronització (update o sync): és l’acció de combinar els canvis fets al repositori amb la còpia de treball local.
• Conflicte (conflict): es produeix quan s’intenten afegir canvis a un fitxer que ha estat modificat prèviament per un altre usuari. Abans de poder combinar els canvis amb el repositori s’haurà de resoldre el conflicte.
• Bloqueig (lock): alguns sistemes de control de versions en lloc d’utilitzar el sistema de fusions el que fan és bloquejar els fitxers en ús, de manera que només pot haver-hi un sol usuari modificant un fitxer en un moment donat.
• Fusionar (merge o integration): és l’acció que es produeix quan es volen combinar els canvis d’un repositori local amb un remot i es detecten canvis al mateix fitxer en tots dos repositoris i es produeix un conflicte. Per resoldre aquest conflicte s’han de fusionar els canvis abans de poder actualitzar els repositoris. Aquesta fusió pot consistir a descartar els canvis d’un dels dos repositoris o editar el codi per incloure els canvis del fitxer a totes dues bandes. Cal destacar que és possible que un mateix fitxer presenti canvis en molts punts diferents que s’hauran de resoldre per poder donar la fusió per finalitzada.
• Versió (version o revision): és el conjunt de canvis en un moment concret del temps. Es crea una versió cada vegada que s’afegeixen canvis a un repositori.
• Etiqueta (tag, label o baseline): permet afegir una etiqueta a una pujada per poder identificar aquesta pujada concreta d’una forma més entenedora. Per exemple, es pot etiquetar la primera versió d’un programari (1.0) o una versió en la qual s’ha solucionat un error important.
• Tornar a la versió anterior (revert): descarta tots els canvis produïts a la còpia de treball des de l’última pujada al repositori local.

Hi ha molts sistemes de control de versions, tant gratuïts com de pagament. Entre les opcions més populars, per ordre de popularitat, hi ha:

• Git: és el programari més popular amb diferència. Es tracta d’un sistema distribuït, fa servir el model de concurrència de fusió i és gratuït.
• Subversion (SVN): es tracta d’un sistema centralitzat, permet fer servir el sistema de fusió o bloqueig i és gratuït.
• Team Foundation Server (TFS): és un programari desenvolupat per Microsoft que pot utilitzar les arquitectures centralitzades o distribuïdes i fer el model de fusió o bloqueig. És gratuït per a equips petits i projectes de codi lliure, mentre que en altres casos cal pagar una subscripció.
• Mercurial: es tracta d’un sistema distribuït, fa servir el model de fusió i és gratuït.

Com que tant Git com GitHub ofereixen una integració molt bona amb el programari de desenvolupament (entorns de desenvolupament i eines de gestió de projectes), aquesta combinació s’ha tornat molt popular i és utilitzada per projectes de programari lliure, empreses i institucions.

Git és d’un programari de control de versions que utilitza un sistema distribuït i, per consegüent, cada usuari que clona un repositori obté una còpia completa dels fitxers i l’historial de canvis.

Tot i que Git és un sistema distribuït, pot utilitzar-se una còpia del repositori en un servidor de manera que tots els usuaris pugin i baixin els canvis d’aquest repositori per facilitar la sincronització.

Cal tenir en compte que Git és un programari força complex i inclou moltes característiques avançades per a la gestió de revisions i la visualització dels canvis. En aquests materials només es mostren les accions més habituals per poder treballar amb aquesta eina.

Git es troba disponible a la majoria de plataformes, incloent Linux, Windows, macOS i Solaris. A la pàgina oficial podeu trobar l’enllaç per descarregar-lo per als diferents sistemes operatius: goo.gl/BGGTMT.

Tot i que Git ofereix una interfície gràfica, en aquests materials s’utilitza mitjançant la línia d’ordres.

El procés d’instal·lació en qualsevol sistema operatiu és molt senzill. En aquesta secció podeu llegir com instal·lar-lo a Windows:

1. Descarregueu l’instal·lador des de l’enllaç següent: goo.gl/pykTra.
2. Un cop finalitzada la descàrrega, feu doble clic sobre l’instal·lador.
3. Apareix la pantalla que mostra la llicència del programari. Feu clic a Continuar.
4. Apareix la pantalla que mostra les opcions d’instal·lació. No cal que canvieu res.
5. La següent pantalla ofereix tres opcions. Deixeu marcada l’opció per defecte: utilitzar Git des de la línia d’ordres de Windows (vegeu la figura).
6. La següent pantalla ofereix dues opcions. Deixeu marcada l’opció per defecte: utilitzar la biblioteca OpenSSL (vegeu la figura).
7. La següent pantalla mostra tres opcions. Deixeu marcada l’opció per defecte, ja que és l’opció recomanada per Windows per a projectes multiplataforma (vegeu la figura).
8. La següent pantalla mostra dues opcions: utilitzar un emulador de terminal o fer servir la consola de Windows. Podeu marcar qualsevol de les dues opcions.
9. La darrera pantalla mostra opcions per configurar opcions extres. Deixeu les opcions per defecte marcades (activar el sistema de cau i activar el gestor de credencials de Git) i feu clic a Instal·lar.

Un cop instal·lat, obriu la finestra del símbol del sistema (o la terminal, segons el sistema operatiu) i escriviu:

git --version

El resultat ha de ser similar al següent:

git version 2.14.1.windows.1

En cas que no funcioni correctament, proveu de reinstal·lar-lo i assegureu-vos que a la pantalla d’opcions per ajustar la variable d’entorn PATH heu seleccionat la segona opció: Use Git from the Windows Command Prompt.

El primer pas per començar a treballar amb Git un cop instal·lat és clonar un repositori ja existent o crear-ne un de nou. En aquesta secció es descriu pas a pas com crear un nou repositori i com treballar amb el repositori local i la còpia de treball amb Windows, però en altres sistemes operatius les ordres són les mateixes.

Primer heu d’obrir una finestra del símbol del sistema (o terminal) i crear un directori on s’inicialitzarà el repositori anomenat proves-git:

md proves-git

A Linux i macOS l’ordre serà:

mkdir proves-git

Entreu dintre del directori amb l’ordre següent:

cd proves-git

Inicialitzeu el repositori amb l’opció init de Git:

git init

El resultat ha de ser semblant al següent:

Initialized empty Git repository in D:/Users/Xavier Garcia/proves-git/.git/

Aquesta ordre inicialitza el sistema de control de versions i crea una carpeta oculta (anomenada.git) on hi ha tota la informació del repositori. Podeu entrar dintre de la carpeta amb l’ordre:

cd .git

El contingut de la carpeta serà similar al següent:

 El volumen de la unidad D es Disco local
 El número de serie del volumen es: 9222-DEE6

 Directorio de D:\Users\Xavier Garcia\proves-git\.git

18/08/2017  18:05               130 config
18/08/2017  18:05                73 description
18/08/2017  18:05                23 HEAD
18/08/2017  18:05    <DIR>          hooks
18/08/2017  18:05    <DIR>          info
18/08/2017  18:05    <DIR>          objects
18/08/2017  18:05    <DIR>          refs
               3 archivos            226 bytes
               4 dirs  1.668.150.059.008 bytes libres

Els fitxers d’aquesta carpeta no s’han de tocar mai, a excepció del fitxer config, que conté la informació del repositori i de vegades cal fer alguna modificació (per exemple, canviar el repositori remot).

Un cop inicialitzat el repositori, el contingut del directori proves-git es considera la còpia de treball. Creeu un fitxer dintre d’aquest directori anomenat index.html, amb un editor de text pla amb el següent contingut:

<h1>Proves Git</h1>
<ul>
  <li>Pas 1: Inicialitzar el repositori: git init</li>
</ul>

Escriviu a la línia d’ordres:

git status

Aquesta ordre mostra l’estat actual de la còpia de treball. Així, l’ordre anterior us mostrarà un resultat similar al següent:

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        index.html

nothing added to commit but untracked files present (use "git add" to track)

El nom del fitxer index.html es mostra ressaltat per destacar que aquest fitxer no es troba sota el control de versions. Per afegir un o més fitxers (o directoris) al control de versions es fa servir l’ordre git add, indicant com a paràmetre la ruta (admet comodins) dels elements que cal afegir. Per exemple, per afegir tots els fitxers al sistema de control de versions es fa servir l’ordre:

git add .

Si només voleu afegir els fitxers amb extensió .html, l’ordre ha de ser:

git add *.html

Un cop executada qualsevol de les ordres anteriors, si comproveu l’estat de la còpia de treball el resultat serà similar al següent:

On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   index.html

Fixeu-vos que el fitxer s’ha afegit al sistema de control de canvis, però encara no s’ha pujat al repositori local.

En cas d’afegir un fitxer per error, podeu eliminar-lo amb l’ordre git rm –cache. Per exemple, per eliminar el fitxer anterior del control de versions podeu utilitzar l’ordre:

git rm index.html --cache

Cal tenir en compte que afegir un fitxer al control de versions no el puja al repositori; així, els canvis que es produeixin al fitxer encara no quedaran enregistrats a l’historial de canvis. Per pujar els fitxers al repositori i començar a enregistrar aquests canvis s’ha d’utilitzar l’ordre commit:

git commit -m "Pujada inicial"

El paràmetre -m serveix per afegir un comentari i s’utilitza per afegir informació extra sobre els canvis que inclou la versió (el conjunt de canvis realitzats). El resultat d’executar l’ordre anterior serà similar al següent:

[master (root-commit) 33f2ea7] Pujada inicial
 1 file changed, 4 insertions(+)
 create mode 100644 index.html

Si a continuació comproveu l’estat de la còpia de treball amb l’ordre git status, podeu veure que no es detecta res perquè tots els canvis es troben ja a la còpia de treball:

On branch master
nothing to commit, working tree clean

Per comprovar que es detecten els canvis correctament canvieu el contingut del fitxer index.html pel següent:

<h1>Proves Git</h1>
<ul>
  <li>Pas 1: Inicialitzar el repositori: git init</li>
  <li>Pas 2: Afegir tots els fitxers: git add .</li>
</ul>

Afegiu un nou fitxer buit anomenat llegeix.me al directori proves-git, i comproveu l’estat de la còpia de treball amb git status. El resultat serà similar al següent:

On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        llegeix.me

no changes added to commit (use "git add" and/or "git commit -a")

Com podeu apreciar, el missatge indica que s’han detectat canvis al fitxer index.html i que s’ha trobat un fitxer (llegeix.me) que no es troba sota el control de versions.

Afegiu el nou fitxer al control de versions amb l’ordre git add:

git add llegeix.me

Pugeu els canvis al repositori:

git commit . -m "Afegit pas 2 i nou fitxer"

Fixeu-vos que per pujar els canvis del fitxer index.html s’ha d’afegir un punt (.) a les opcions. Això indica que es volen pujar tots els fitxers modificats sota el control de versions, i no només els fitxers afegits. En cas contrari, la versió pujada només inclou el nou fitxer creat i no pas els canvis al fitxer index.html.

Un cop pujada aquesta versió, podeu veure la llista de versions pujades al repositori amb l’ordre git log. El resultat serà similar al següent:

commit 3f9365181b055c0b956e3bdf97a6e3a37085927f (HEAD -> master)
Author: Xavier Garcia <xaviergaro.dev@gmail.com>
Date:   Fri Aug 18 19:17:53 2017 +0200

    Afegit pas 2 i nou fitxer.

commit 33f2ea78a9657bc6ad8660a6e0edea3b68ae02cf
Author: Xavier Garcia <xaviergaro.dev@gmail.com>
Date:   Fri Aug 18 18:41:18 2017 +0200

    Pujada inicial

Com podeu apreciar, apareixen les dues versions pujades on s’indica l’identificador de la versió (commit), l’indicador de quin és l’últim que s’ha pujat (HEAD> master), l’autor i la data de la pujada, seguit del text introduït com a comentari amb l’opció -m.

Es recomana pujar els canvis al repositori local de manera freqüent, preferiblement incloent canvis relacionats. Per exemple, si es detecta un error al programari i se soluciona el problema seria adient pujar el canvi abans de continuar afegint una altra característica o solucionant altres problemes. D’aquesta manera en el futur és possible tornar a la versió concreta en la qual es va fer el canvi.

Cal recordar que en cas que la informació ocupi més d’una pantalla no es mostra tot de cop, sinó que el programa en mostra només una part i podreu desplaçar-vos per veure la resta amb les fletxes del teclat. Per sortir, premeu la tecla q.

Una altra opció a l’hora de crear repositoris és clonar un repositori existent. Per fer-ho s’utilitza l’ordre git clone, indicant l’adreça del repositori que es vol clonar. Per exemple, per clonar el repositori que es troba a l’URL bit.ly/2kmanlq l’ordre seria la següent:

git clone https://github.com/XavierGaro/client-servidor-xat.git

Aquesta ordre crea el directori client-servidor-xat i descarrega els continguts del repositori mostrant per pantalla els missatges següents:

Cloning into 'client-servidor-xat'...
remote: Counting objects: 45, done.
remote: Total 45 (delta 0), reused 0 (delta 0), pack-reused 45
Unpacking objects: 100% (45/45), done.

En resum, les ordres bàsiques de Git per treballar amb repositoris locals són les següents:

• git init: inicialitza un repositori.
• git add : afegeix elements de la còpia de treball al control de versions.
• git rm –cache: elimina elements del control de versions.
• git status: mostra l’estat de la còpia de treball.
• git commit: puja els canvis de la còpia de treball sota el control de versions al repositori local.
• git log: mostra la llista de versions pujades al repositori local.
• git clone: copia un repositori remot, no cal inicialitzar-lo.

És molt habitual quan es treballa en control de versions haver de crear noves branques, de manera que al tronc es troba la versió actual del programari i a les branques es desenvolupen noves funcionalitats, es fa el manteniment de versions anteriors o se solucionen errors.

En alguns casos, com la implementació de noves funcionalitats i la solució d’errors, aquestes branques es fusionen amb el tronc un cop s’ha finalitzat amb èxit la tasca.

Per crear una nova branca es fa servir l’ordre git branch. Per exemple, dintre del directori proves-git (on s’ha inicialitzat prèviament un repositori) escriviu l’ordre següent i es crearà una nova branca amb el nom nova-branca:

git branch nova-branca

No es visualitza cap canvi, però si entreu l’ordre git branch veureu la llista de branques al repositori:

* master
  nova-branca

Com podeu apreciar, es mostra un asterisc al costat de la branca activa (master).

Per canviar de branca s’utilitza l’ordre git checkout. Així, per canviar a la branca nova-branca heu d’utilitzar la següent ordre:

git checkout nova-branca

Si a continuació proveu d’entrar l’ordre git branch, veureu que l’asterisc es mostra al costat de la branca nova-branca:

  master
* nova-branca

Per comprovar que els canvis són independents, assegureu-vos de situar-vos a la branca nova-branca i editeu el fitxer index.html (o creeu-ne un de nou amb aquest nom) de manera que contingut el codi següent:

<h1>Proves Git</h1>
<ul>
  <li>Pas 1: Inicialitzar el repositori: git init</li>
  <li>Pas 2: Afegir tots els fitxers: git add .</li>
  <li>Pas 4: Crear una branca: git branch nova-branca</li>
</ul>

Seguidament pugeu els canvis al repositori amb l’ordre:

git commit -m . "Afegit pas 4"

Apareix un missatge similar al següent:

[nova-branca b4483e3] Afegit pas 4
 1 file changed, 1 insertion(+)

Si torneu a la branca master amb l’ordre git checkout master i editeu el fitxer index.html, podeu veure que el contingut del fitxer index.html és diferent. En canviar de branca, el fitxer a la còpia de treball correspon al de la branca master i no al que s’ha modificat anteriorment.

Assegureu-vos que us trobeu a la branca master i modifiqueu el fitxer index.html, amb el següent contingut:

<h1>Proves Git</h1>
<ul>
  <li>Pas 1: Inicialitzar el repositori: git init</li>
  <li>Pas 2: Afegir tots els fitxers: git add .</li>
  <li>Pas 3: Pujar els canvis al repositori: git commit . -m "Pujar canvis"</li>
</ul>

Seguidament pugeu els canvis al repositori amb l’ordre:

git commit . -m "Afegit pas 3"

Arribats a aquest punt, els continguts de totes dues branques són diferents i a mesura que es pugin més canvis al repositori en una o altra branca s’afegiran al registre propi de cada branca, com podeu veure a la figura.

}}

En el cas que vulgueu integrar els canvis fets en una branca amb el tronc (per exemple, perquè s’ha finalitzat la implementació de la nova funcionalitat o s’ha corregit l’error pel qual es va crear la branca), heu de fer servir l’ordre git merge. Per exemple, per fusionar els canvis de la branca nova-branca amb la branca master s’ha d’utilitzar la següent ordre (essent master la branca activa):

git merge nova-branca

En cas que els canvis de cada branca afectin diferents fitxers no cal fer res més, però com que en aquest cas s’ha modificat el mateix fitxer i les mateixes línies a totes dues branques es produeix un conflicte que cal solucionar abans de continuar. Per veure on es troba el problema podeu utilitzar l’ordre git diff, que mostra un text similar al següent:

diff --cc index.html
index ae389e4,e2e54dd..0000000
--- a/index.html
+++ b/index.html
@@@ -2,5 -2,5 +2,9 @@@
  <ul>
    <li>Pas 1: Inicialitzar el repositori: git init</li>
    <li>Pas 2: Afegir tots els fitxers: git add .</li>
++<<<<<<< HEAD
 +  <li>Pas 3: Pujar els canvis al repositori: git commit . -m "Pujar canvis"</li>
++=======
+   <li>Pas 4: Crear una branca: git branch nova-branca</li>
++>>>>>>> nova-branca
  </ul>

Per solucionar el conflicte heu d’editar el fitxer index.html, on s’hauran afegit les marques «««< HEAD on comença el conflicte i »»»> nova-branca on acaba, fer els canvis necessaris i desar el fitxer. El contingut del fitxer index.html una vegada resolt el conflicte ha de ser el següent:

<h1>Proves Git</h1>
<ul>
  <li>Pas 1: Inicialitzar el repositori: git init</li>
  <li>Pas 2: Afegir tots els fitxers: git add .</li>
  <li>Pas 3: Pujar els canvis al repositori: git commit . -m "Pujar canvis"</li>
  <li>Pas 4: Crear una branca: git branch nova-branca</li>
</ul>

Una vegada desats els canvis, pugeu-lo al repositori amb l’ordre:

git commit -a -m "Conflicte resolt"

Fixeu-vos que s’ha fet servir el paràmetre -a. Si no es fa així, es considera una pujada parcial i no permet continuar. El missatge d’error que es mostra és el següent:

fatal: cannot do a partial commit during a merge.

Arribats a aquest punt, s’ha fusionat la branca amb el tronc i la representació del repositori és la que es mostra a la figura.

De vegades interessa tornar a una versió anterior del control de canvis. Per fer-ho es pot utilitzar l’ordre checkout, però en lloc d’indicar una branca s’indica l’identificador de la versió. Per exemple, si voleu tornar a la versió on es va afegir el pas 2 i el seu identificador és commit 3f9365181b055c0b956e3bdf97a6e3a37085927f, l’ordre que haureu d’utilitzar és:

git checkout 3f93651

Com podeu apreciar, no cal entrar l’identificador complet, només el nombre suficient de caràcters, perquè no coincideix amb cap altre identificador de versió. Recordeu que es pot trobar l’identificador corresponent a cada versió amb l’ordre git log.

En canviar a una versió anterior es mostra a la terminal un missatge indicant que la còpia de treball es troba en l’estat detached HEAD i indica que es pot crear una nova branca a partir d’aquesta versió amb l’ordre git checkout -b nom-de-la-branca.

No es recomana fer canvis en aquest estat, ja que és molt fàcil que es produeixin errors que requereixen coneixements avançats de Git per poder-se solucionar. Per evitar aquests problemes, si es volen fer canvis, és millor crear una nova branca a partir de la versió i fer els canvis a la branca.

Per tornar a la versió més actual només cal entrar l’ordre git checkout, especificant una branca (per exemple, master):

git checkout master

Git permet afegir etiquetes a les versions de manera que es pot distingir entre les versions habituals i les que representen algun fet especial, com per exemple una versió estable del producte o alguna fita concreta (la inclusió d’alguna funcionalitat important).

Per afegir una etiqueta a l’última versió afegida al repositori s’utilitza l’ordre git tag -a. Per exemple:

git tag -a v1.0 -m "Primera versió"

L’opció -a indica el text de l’etiqueta i l’opció -m permet afegir informació addicional.

Per llistar totes les etiquetes d’un repositori s’utilitza l’ordre git tag sense cap opció. A partir d’aquesta llista, es pot fer servir l’ordre git show per mostrar la informació referent a la revisió corresponent a l’etiqueta. Per exemple, l’ordre git show v1.0 mostra un text similar al següent:

tag v1.0
Tagger: Xavier Garcia <xaviergaro.dev@gmail.com>
Date:   Fri Aug 18 21:06:17 2017 +0200

Primera versió

commit 7a7edead12a3f7f33e1bebc692cc868fa534f18f (HEAD -> master, tag: v1.0)
Merge: 3f2e774 b4483e3
Author: Xavier Garcia <xaviergaro.dev@gmail.com>
Date:   Fri Aug 18 20:39:31 2017 +0200

    Conflicte resolt

diff --cc index.html
index ae389e4,e2e54dd..31d9d62
--- a/index.html
+++ b/index.html
@@@ -2,5 -2,5 +2,6 @@@
  <ul>
    <li>Pas 1: Inicialitzar el repositori: git init</li>
    <li>Pas 2: Afegir tots els fitxers: git add .</li>
 +  <li>Pas 3: Pujar els canvis al repositori: git commit . -m "Pujar canvis"</li>
+   <li>Pas 4: Crear una branca: git branch nova-branca</li>
  </ul>

Cal destacar que l’ordre git show es pot utilitzar directament amb un identificador de versió i mostraria pràcticament la mateixa informació (sense les dades referents a l’etiqueta). Per exemple:

git show 7a7ed

S’ha de tenir en compte que un repositori pot comptar amb centenars de revisions; això fa que trobar una revisió concreta només pel nombre de revisió sigui força complicat. En canvi, si la revisió que cerqueu està etiquetada trobar-la és molt ràpid. De vegades pot interessar descartar tots els canvis realitzats a la còpia de treball i tornar a la revisió actual. En aquest cas es pot fer servir l’ordre:

git reset --hard

Aquesta ordre descarta tots els canvis i tots els fitxers sota el control de canvis són restablerts. Aquesta acció és coneguda com a “revertir els canvis” en alguns entorns.

Quan es treballa amb repositoris remots (per exemple, quan es clona un repositori) es poden descarregar els canvis que s’han portat a terme en el repositori remot amb l’ordre git pull. Aquesta ordre descarrega els canvis i fa una fusió automàtica amb la còpia de treball. Aquesta acció pot provocar conflictes que s’han de resoldre abans de poder pujar els canvis al servidor.

En el cas de voler pujar els canvis del repositori local al repositori remot l’ordre que s’ha d’utilitzar és git push. Per executar aquesta ordre primer heu de fer un pull per fusionar els canvis al servidor remot amb la còpia de treball. En cas contrari, si s’han produït canvis al repositori remot, l’ordre push és rebutjada.

Per afegir un repositori remot heu de fer servir l’ordre git remote add, indicant el nom del repositori remot i l’URL corresponent. Per exemple:

git add remote add xat https://github.com/xaviergaro/client-servidor-xat

Aquesta ordre afegeix com a repositori remot l’URL https://github.com/xaviergaro/client-servidor-xat amb xat com a nom curt. Cal destacar que és possible configurar múltiples repositoris remots, però s’ha de tenir molt de compte a l’hora de sincronitzar-los, ja que si no s’automatitza aquesta tasca és possible oblidar fer la sincronització de tots els repositoris quan es produeixen canvis.

Per fer un push al servidor remot heu d’indicar el repositori d’origen (per al repositori local és origin) i el repositori de destí. Per exemple, per fer un push des del repositori local al repositori remot xat l’ordre seria la següent:

git push origin xat

Per fer un pull només cal indicar el nom curt del repositori remot:

git pull xat

Habitualment cal ignorar determinats fitxers per evitar que s’afegeixin al sistema de control de versions. Per exemple: fitxers del sistema operatiu, fitxers generats per l’entorn de desenvolupament, fitxers de configuració amb contrasenyes, etc.

Per no haver de preocupar-vos quan feu servir l’ordre git add ., podeu afegir aquestes exclusions al fitxer .gitignore. El format d’aquest fitxer es molt senzill: només cal indicar el nom dels fitxers o directoris que es volen ignorar. Per exemple:

# Diaris
logs
*.log

# Dependències
node_modules

Com podeu apreciar, el fitxer .gitignore amb el contingut anterior ignoraria els directoris logs, node_modules i tots els fitxers amb extensió log. El símbol # s’utilitza per afegir comentaris i són ignorats per Git.

En resum, les ordres avançades que s’han vist en aquesta secció són:

• git branch: crea noves branques o llista les branques del repositori.
• git checkout: canvia la còpia de treball a la branca o versió indicada.
• git diff: mostra els canvis que s’han afegit en una versió.
• git log: mostra la llista de versions per la branca activa.
• git merge: fusiona els canvis entre dues branques.
• git tag: afegeix una etiqueta a una versió.
• git show: mostra informació sobre la versió indicada.
• git reset –hard: reverteix els canvis a la còpia de treball.
• git pull: puja els canvis del repositori local a un repositori remot.
• git push: baixa els canvis d’un repositori remot al repositori local.
• git remote: afegeix un repositori remot o llista els repositoris remots enllaçats amb el repositori local.
• fitxer .gitignore: permet afegir una llista de fitxers i directoris per excloure del sistema de control de versions.

SourceTree és un client gràfic gratuït per a Git desenvolupat per Atlassian per a les plataformes Windows i macOS (no es troba disponible per a Linux). Aquest programari és el més popular dels clients de Git actualment al mercat, i per això s’ha escollit per mostrar-ne el funcionament. Tanmateix, podeu trobar característiques molt similars en tots els clients gràfics de Git.

Podeu descarregar-vos l’aplicació de SourceTree al següent enllaç: www.sourcetreeapp.com.

Un cop descarregada i instal·lada, apareix una pantalla dividida en dues columnes: a l’esquerra, la llista de carpetes que tenen com a única finalitat organitzar els repositoris. Per defecte només hi ha la carpeta All Repos, que mostra tots els repositoris locals i el botó Add Folder, que permet crear noves carpetes.

A la barra d’eines podeu veure els següents botons:

• Local: mostra els repositoris locals.
• Remote: mostra els comptes afegits que contenen repositoris remots.
• Clone: clona un repositori remot.
• Add: afegeix un repositori local (creat prèviament al vostre equip) a SourceTree.
• Create: crea un nou repositori de Git.

Per clonar un repositori s’ha d’indicar l’URL on es troba el repositori, la ruta de destí dels fitxers i la carpeta de SourceTree que ha de contenir el repositori (vegeu la figura). Per exemple, a GitHub es pot fer clic sobre el botó Clone or download i es mostra l’URL de l’enllaç necessari per clonar el repositori.

En cas que vulgueu afegir un repositori existent al vostre equip, heu d’indicar la ruta de la còpia de treball i la carpeta de SourceTree on voleu copiar el repositori (vegeu la figura). Cal que tingueu en compte que aquesta opció requereix que el repositori s’hagi inicialitzat prèviament. En canvi, si no s’ha inicialitzat encara, haureu de fer servir l’opció Create.

Per crear un repositori cal indicar la ruta on es vol crear i el nom del repositori. En cas d’haver afegit un compte de GitHub o BitBucket és possible crear-lo automàticament seleccionant el compte, la descripció i indicant si es tracta d’un repositori privat (vegeu la figura). Cal tenir en compte que aquesta opció no sempre està disponible, ja que depèn del tipus de compte.

SourceTree permet gestionar repositoris remots enllaçats a comptes de GitHub i BitBucket, de manera que un cop introduïdes les dades d’autenticació es pugui accedir directament a tots els repositoris (vegeu la figura).

Si feu clic sobre un dels repositoris locals, podreu veure el detall dels canvis produïts al repositori. El detall del repositori inclou la llista de branques, repositoris remots i etiquetes a la banda esquerra. A la dreta, la llista de versions de la branca seleccionada amb els comentaris afegits, la data i l’autor.

Com podeu apreciar a la figura, el graf mostra on es va crear una nova branca i en quina versió es va fusionar. En cas d’haver-hi múltiples branques, també estan representades al graf. Cal recordar que una branca no té per què fusionar-se amb el tronc. Per exemple, per representar versions de manteniment d’una implementació anterior del programari.

En el panell inferior podeu veure el detall de la versió pujada seleccionada. Aquesta informació inclou el resum de la versió, la llista de fitxers modificats i els canvis produïts en el fitxer seleccionat.

A la barra d’eines hi ha els botons per portar a terme les accions més habituals de Git:

• commit: puja els canvis a la còpia de treball com una nova versió.
• push: puja els canvis del repositori local al repositori remot.
• pull: baixa els canvis del repositori remot i els fusiona amb el repositori local.
• branch: crea una nova branca.
• merge: fusiona dues branques.
• tag: afegeix una etiqueta.

Tots els entorns de desenvolupament integrats (i alguns editors de text per a desenvolupadors) inclouen l’opció de gestionar el control de versions dintre del mateix programa. En aquesta secció es descriu com integra NetBeans el control de versions amb Git.

A NetBeans hi ha totes les opcions de Git a l’opció Team> Git del menú principal, com podeu veure en la figura:

Des d’aquest menú podeu inicialitzar un repositori per al projecte actual o clonar un repositori existent. Per clonar un repositori existent no és necessari crear un projecte, aquest es crea a partir del repositori clonat. Per clonar un repositori existent heu de seleccionar Team> Git> Clone al menú principal. Seguidament heu d’indicar la ruta al directori que voleu clonar (pot ser una URL, si es tracta d’un repositori remot), com podeu veure a la figura:

A continuació heu de marcar les caselles corresponents a les branques que voleu clonar (vegeu la figura).

Finalment heu de decidir el directori de destí, el nom del repositori clonat i quina és la branca activa (vegeu la figura).

Cal tenir en compte que, en el cas de NetBeans, si el repositori clonat no conté un projecte de NetBeans, els fitxers del repositori no es visualitzen a la pestanya del projecte sinó a la pestanya de favorits, com podeu veure en la figura. Fins i tot si es crea el projecte un cop finalitzada la clonació, aquests fitxers no es mostren al projecte si l’estructura de directoris no es correspon amb un projecte de NetBeans.

En qualsevol cas, si se selecciona algun dels fitxers del repositori i es fa clic sobre el botó history del panell central es mostra l’historial de versions del fitxer. Fixeu-vos que en la figura es mostra l’historial del fitxer index.html, no a l’historial del repositori.

En la figura podeu veure que el fitxer llegeix.me, que forma part del mateix repositori, té un historial molt més curt, ja que no s’hi ha fet cap canvi un cop es va afegir al repositori.

Un cop clonat o inicialitzat un repositori es poden portar a terme totes les accions relacionades amb Git fent clic sobre un dels fitxers amb el botó esquerre del ratolí (vegeu la figura) o des de l’opció Team del menú principal (vegeu la figura).

Alguns entorns de desenvolupament inclouen icones amb les accions més comunes de Git (per exemple, Eclipse o la família de IDE derivades d’IntelliJ), però en general el funcionament d’aquestes eines és força similar. Totes inclouen accés a Git des d’un menú contextual i des de la barra de menú principal.

Git LFS és un nou sistema que permet seleccionar determinats tipus de fitxers que es desen com a punters de text dintre de Git mentre que el fitxer real es desa en un servidor extern remot. Habitualment els fitxers molt grans no són admesos per Git i poden arribar a produir-se errors silenciosos difícils de detectar. Per altra banda, com que aquests fitxers es troben separats del repositori, és més ràpid fer actualitzacions i clonacions dels repositoris.

Git LFS està inclòs en els instal·ladors de Git més recents. En cas que necessiteu descarregar-lo individualment, el podeu trobar al següent enllaç: git-lfs.github.com. Un cop instal·lat, utilitzeu l’ordre:

git lfs install

Si s’ha instal·lat correctament, es mostra el missatge següent:

Git LFS initialized.

Seguidament podeu afegir quins tipus de fitxers voleu afegir al sistema LFS. Per exemple, per afegir tots els fitxers MP3 s’utilitza la següent ordre:

git lfs track "*.mp3"

Aquesta informació s’afegeix al fitxer .gitattributes. Per assegurar-vos que aquest fitxer es troba inclòs al control de versions heu d’introduir l’ordre:

git add .gitattributes

Per saber com treballar amb fitxers grans i GitHub, visualitzeu el vídeo que mostra el funcionament d’aquest sistema al següent enllaç:

Si es fa servir GitHub com a servidor no cal configurar res més: els fitxers grans es pugen automàticament al servidor per fitxers grans de GitHub.com, i des del mateix lloc web es poden comparar els canvis entre versions de fitxers (per exemple, els canvis entre una imatge i la nova versió).

Addicionalment, Git LFS afegeix el sistema de bloqueig de fitxers, de manera que és possible bloquejar un fitxer per evitar que altres usuaris del repositori el modifiquin.

GitHub (github.com) és un servei d’allotjament de repositoris Git que compta amb més de 10 milions d’usuaris. Ofereix tota la funcionalitat de Git, a més d’oferir serveis propis com són l’edició de fitxer en línia, la gestió d’errors, possibilitat de documentar els projectes mitjançant una wiki inclosa al repositori o la gestió d’usuaris.

Hi ha dos tipus de repositoris a GitHub:

• Públics: tothom pot visualitzar-los i descarregar-los, sense necessitat de crear un compte a GitHub. Aquests repositoris són gratuïts, i qualsevol usuari registrat pot crear-los.
• Privats: només els membres de l’equip i els usuaris amb permisos poden visualitzar, baixar i pujar canvis al repositori. Aquests repositoris estan limitats als comptes de pagament o d’estudiant (requereixen una adreça de correu universitari vàlida).

GitHub inclou característiques de xarxa social com ara notificacions, llistes de seguidors, opció de subscriure’s als repositoris per fer un seguiment dels canvis o marcar repositoris com a favorits. Tot i que la plataforma no proporciona cap sistema de missatgeria entre usuaris, alguns usuaris afegeixen la seva adreça de correu electrònic al seu perfil i és possible comunicar-se amb els administradors d’un repositori mitjançant el sistema de gestió d’errors (issues) o la wiki que es pot incloure al repositori.

Per treballar amb GitHub es pot utilitzar la línia d’ordres de Git, es pot descarregar algun client gràfic com SourceTree o Github Desktop (desktop.github.com) o es pot treballar directament des d’un IDE integrat amb Git.

Per començar a treballar amb els repositoris de GitHub com a repositoris remots cal crear un compte a la plataforma. En cas contrari, es poden clonar els repositoris públics però no es poden pujar els canvis.

Un cop creat un compte, podeu crear nous repositoris des de la pàgina fent clic al botó New repositori (vegeu la figura).

Seguidament heu d’indicar el nom del repositori, la descripció i el tipus (públic o privat), com en la figura. Addicionalment podeu inicialitzar amb un fitxer README, que es mostra a la primera pàgina del repositori.

El fitxer README admet el format Markdown i acostuma a incloure informació detallada sobre el repositori i instruccions d’instal·lació. En cas de crear un repositori a GitHub, per sincronitzar-lo amb un repositori local ja existent no marqueu la casella per afegir el fitxer README, ja que en sincronitzar els repositoris es produeix un conflicte.

Un cop creat el repositori GitHub, apareix una pàgina on s’indica com sincronitzar el repositori de GitHub amb el vostre repositori local. Per una banda, indica com crear un nou repositori si comenceu un projecte de nou i com sincronitzar-lo amb GitHub:

echo "# proves-git" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/nom-usuari/nom-repositori.git
git push -u origin master

En cas que vulgueu pujar un repositori ja existent, indica com afegir el repositori remot i com pujar els canvis:

git remote add origin https://github.com/nom-usuari/nom-repositori.git
git push -u origin master

Fixeu-vos que l’URL del repositori que mostra GitHub és la del repositori que heu creat al vostre compte, així que podeu copiar directament el codi a la línia d’ordres.

Un cop s’ha afegit el repositori remot com a origen, no cal que especifiqueu el nom en les ordres git push o git pull, ja que automàticament fa la sincronització amb aquest repositori.

Cada repositori de GitHub té la seva pròpia configuració individual (botó Settings). Vegeu-ho en la figura:

A la secció d’opcions generals hi ha els següents apartats:

• Quines característiques es volen activar: activar la wiki, restriccions d’editors, gestió d’errors i gestió de projectes.
• Com es volen fusionar els canvis: llista diferents mètodes de fusió de canvis.
• Limitació temporal d’interacció: permet imposar una limitació d’interacció temporal amb el repositori per diferents tipus d’usuaris.
• GitHub Pages: configura un servei que permet crear un lloc web per al repositori o el projecte.
• Zona de perill: permet canviar el tipus de repositori (públic o privat), transferir la propietat o eliminar el repositori.

Respecte a la gestió d’usuaris, GitHub permet afegir col·laboradors a un repositori fent clic a l’opció Collaborators de la barra esquerra de la secció de configuració. En aquesta secció es mostra la llista de col·laboradors actuals i un botó per enviar una invitació a altres usuaris mitjançant el seu nom d’usuari o adreça de correu electrònic. Aquests col·laboradors podran visualitzar el repositori encara que sigui privat i podran pujar canvis al repositori remot. Cal destacar que l’administrador del repositori no té cap control sobre què pugen els col·laboradors, així que cal tenir-ho en compte a l’hora d’afegir col·laboradors a un repositori.

Un altre tipus d’usuari són els contribuïdors. Aquests són usuaris de GitHub que no tenen cap relació amb el repositori, però poden fer peticions de pujada fent servir l’opció Pull requests que es troba a tots els repositoris. Aquesta opció és molt utilitzada en els projectes de programari lliure on qualsevol usuari interessat pot fer una petició de pujada amb algun canvi per millorar el projecte (per exemple, solucionar algun error). Aquests usuaris són considerats contribuïdors del projecte si s’accepta alguna de les seves peticions de pujada.

El sistema de gestió d’errors i petició de característiques de GitHub s’anomena issues i es pot accedir al sistema de qualsevol repositori fent clic al botó Issues del panell central.

Aquest sistema permet crear noves entrades a qualsevol usuari, en el cas dels repositoris públics, i als col·laboradors, en el cas dels repositoris privats, per enregistrar que hi ha algun error. Aquestes entrades permeten mantenir una conversa amb altres usuaris que tenen el mateix problema i els desenvolupadors afegint informació sobre el problema detectat.

Les entrades poden incloure etiquetes, poden ser assignades a diferents col·laboradors (el responsable de solucionar l’error) i poden filtrar-se: per autor, etiquetes, projectes, etc. (vegeu la figura).

Per redactar una entrada, podeu fer servir text enriquit, afegir imatges, mencionar usuaris (això fa que aparegui l’entrada a les seves notificacions) o enllaçar amb altres errors o peticions de pujada (per exemple, si un contribuïdor ha enviat la solució a l’error).

Per afegir un nou error o petició de característiques a un repositori, només cal que feu clic al botó New issue i redacteu l’entrada (vegeu un exemple d’entrades a la figura). Aquesta s’afegeix a la llista d’errors del projecte i és visualitzada per tots els usuaris.

Un dels avantatges d’aquest sistema és que es troba al mateix repositori i no cal fer servir aplicacions externes per enregistrar un nou error o demanar més informació sobre un problema, fet que agilitza la gestió. A més a més, aquest sistema forma part de l’API que proporciona GitHub als desenvolupadors d’aplicacions per connectar amb els seus serveis.

GitHub facilita la integració d’aplicacions de tercers gràcies a la seva API, que permet detectar quan es disparen determinats events als quals les aplicacions poden subscriure’s per ser notificats.

El sistema utilitzat s’anomena Webhooks. Seguint els passos d’aquesta guia és possible crear un servei web que escolti els events disparats per GitHub en produir-se canvis en un repositori, el sistema de gestió d’errors, la wiki del repositori, etc.

Hi ha múltiples eines que utilitzen aquest sistema (o d’altres similars) per notificar als usuaris quan es produeixen canvis als repositoris, i moltes companyies els utilitzen com a part del seu flux de treball i la gestió de projectes.

Aplicacions com Slack (slack.com) estan integrades amb GitHub i permeten notificar automàticament als usuaris d’un canal quan s’han pujat canvis a un repositori, quan se’ls ha assignat la resolució d’un error (o implementació d’una nova característica) o quan han estat anomenats en una entrada del sistema d’errors entre altres.

Altres programaris utilitzen bots per connectar amb GitHub i proporcionar aquesta informació als usuaris. Per exemple, l’aplicació Discord (discordapp.com) no oferia originalment integració amb GitHub, però els seus usuaris van desenvolupar bots per utilitzar la tecnologia de Webhooks de GitHub i afegir aquesta funcionalitat als usuaris.

A banda dels programaris independents, hi ha altres eines de gestió de projectes com Trello (trello.com), una eina col·laborativa per organitzar projectes mitjançant un sistema de taulells i targetes, que també estan integrats amb GitHub. Gràcies a aquesta integració, és possible enllaçar versions de pujada concretes (commits) a una targeta o una nova entrada en el sistema de gestió d’errors.

Per descomptat, els clients de Git com SourceTree acostumen a oferir integració amb GitHub per gestionar els repositoris fàcilment.

Com que GitHub és la plataforma d’allotjament de repositoris més gran del món, es pot trobar integrat directament mitjançant connectors o mitjançant bots en pràcticament tot el programari relacionat amb el desenvolupament d’aplicacions i de gestió de projectes.

Per garantir la seguretat dels comptes de GitHub la plataforma ofereix l’opció de crear claus de desplegament (deployment keys en anglès) que es poden trobar a la secció de configuració de cada repositori. D’aquesta manera, no és necessari introduir les dades d’accés al compte de GitHub en aplicacions de tercers, sinó que s’utilitza una clau que pot ser anul·lada en qualsevol moment sense posar en perill el compte de l’ usuari.