Sistema de control de versions o VCS iniciat per l'equip de desenvolupament del Kernel de Linux el 2007. Actualment és el sistema més utilitzat esdevenint un estàndard hegemònic.
Referències:
Videotutorial per iniciar-se amb Git i Apache:
Les comandes imprescindibles per treballar amb Git son:
git clone
: descarrega un repositori d'una URL.git commit
: guarda modificacions en el sistema de versions.git push
: puja els canvis realitzats al repositori original des d'on s'ha creat (clonat) el repositori local.git pull
: actualitza (descarrega) els canvis que hi hagi als remotes configurats.git add
: afegeix nous arxius al repositori. Si creem arxius a la nostra carpeta no n'hi ha prou perquè s'afegeixin al sistema de versions. Cal fer el git add
explícitament. La versió més habitual és afegir tots els arxius que hi ha a la carpeta:$ git add .
I tingueu en compte que hi ha alguns arxius importants:
.git/config
: arxiu amb les configuracions de correspondència dels repositoris remots i branques..gitignore
: arxiu que indica quins arxius o carpetes NO s'han de pujar al fer git add .
Molt útil per arxius de producció amb contrasenyes i similars.
La situació més habitual és la de clonar un repositori existent, contribuir-hi afegint arxius o modificacions, i tornant a pujar els canvis.
Clonarem el projecte Welcome del grup de DAW del Esteve Terradas, on surten les fotos dels alumnes de desenvolupament que passen per l'institut, visualitzarem la web i afegirem la nostra foto i el nostre profile (arxiu HTML que es mostrarà quan cliquem sobre la foto).
Si ets alumne de l'Esteve Terradas pots seguir el tutorial tal qual, demanant al professor que t'inclogui a l'equip de treball del cicle, donant-li el teu nickname del Github.
Si no ets alumne del Terradas, pots clonar el projecte Welcome al teu compte de Github fent un FORK (busca el botó «Fork» a dalt a la dreta de la pàgina del projecte). Llavors canvia el git clone
de l'inici i canvia l'adreça per la de la teva còpia que has fet (hauria de ser algo com https://github.com/elmeusuari/welcome
).
git
i php
amb $ sudo apt install git php
$ git clone https://github.com/aws2/welcome
$ git clone https://github.com/elmeuusuari/welcome
$ cd welcome
$ php -S 0:8080
http://localhost:8080
i comprova que funciona. Veuràs que al clicar la foto d'un alumne apareix el seu «profile».img/
i el teu HTML a la carpeta profile/
.$ git add .
$ git status
$ git commit -am "afegida imatge i perfil en html"
Github -> Settings -> Developer settings -> Personal access tokens
(en Windows potser no cal)
$ git push
Per mes info i xuleta pràctica pots consultar: https://cacauet.org/wiki/index.php/Git:_comandes
Per ho haver de posar tota l'estona el token que hem creat com a credencial activem la cache:
$ git config --global credential.helper cache
Cal distingir clarament entre el repositori local i el repositori remot.
Per crear un repositori local ho farem mitjançant git init
, però primer cal crear la carpeta de projecte. Després podrem afegir arxius amb git add
i pujar-los a un repositori remot amb git push
.
Per crear un repositori remot dependrà del proveïdor que l'hostatgi. Entre d'altres, les opcions que tenim son:
Cada proveïdor té les seves eines, entre elles es pot fer via web. Però sempre ens serà molt útil disposar d'eines CLI (Command Line Interface). Github és la web més popular per hostatjar repositoris gratuïtament i té la eina gh https://cli.github.com/
En Debian/Ubuntu la podem instal·lar amb:
$ sudo apt install gitsome
I després ja ens podem logar. Caldrà que creem un personal access token a la web de Github.com.
$ gh configure
A partir d'aquí podrem crear un repositori remot a Github. Tenim un parell d'opcions:
$ gh repo create <elmeurepo>
Amb això ens crearà un repositori remot, però ens falta lligar el repositori remot amb un de local, i omplir els continguts. Si visiteu la URL del nou repo de Github, allà mateix us apareixerà una «xuleta» de com fer-ho:
https://github.com/elmeuusuari/elmeurepo
En concret, fixeu-vos en la més important:
$ mkdir elmeurepo $ cd elmeurepo $ git init $ git add README.md # suposant que hem creat un fitxer README.md $ git commit -m "primer commit" $ git branch -M main $ git remote add origin https://github.com/elmeuusuari/elmeurepo $ git push -u origin main
Fixeu-vos en git remote add origin …
que és la que enllaça el repo local i el remot.
Cal tenir en compte i distingir les branques locals i les branques remotes, perquè no son les mateixes.
La comanda bàsica per veure les branques locals és:
$ git branch
Per veure totes les branques, locals i remotes fem:
$ git branch -a
Per crear una nova branca local ho fem amb: (ULL! Això només la crea, però no l'estem utilitzant encara)
$ git branch newbranch
Per canviar-nos a la nova branca:
$ git checkout newbranch
Ara podem pujar la nova branca amb:
$ git push -u origin newbranch
Configuració de branques locals i remotes
Molt important tenir en compte que una branca local no té perquè coincidir amb el nom de la branca remota.
Quan fem el procediment anterior (crear una branca remota des d'una local), automàticament ens ha creat una branca remota amb el mateix nom, i les enllaça perquè la local segueixi la remota. Aquesta situació, però, és configurable.
Per veure com estan enllaçades les branques i el repositori podem inspeccionar l'arxiu .git/config
Una bona referència: documentació Atlassian sobre Git Merge.
Sempre que fem un git pull
es fa un merge automàticament. Per tant, aneu al tanto amb aquestes operacions. Potser és més convenient utilitzar git fetch
, mirar els canvis que s'han introduït, i si s'entén que estan bé, procedir al git merge
.
Abans de fer un merge convé repassar com està l'arbre de versions, per exemple amb un:
$ git log --graph --all --oneline
El merge és una operació que comporta riscos potencialment. El developer que faci un merge es pot trobar amb diversos tipus d'errors:
<<<<<<< HEAD Versió que teniem a la branca. ======= Versió que estem fusionant. >>>>>>> manolo
Per procedir a un merge podem seguir les següents passes:
Descarregar els canvis dels altres desenvolupadors (farem git fetch i no git pull per evitar merges automàtics abans de comprovar els canvis):
$ git fetch
Comprovar els canvis mirant l'arbre de versions:
$ git log --graph --all
Anar a la branca destí:
$ git checkout <desti>
Unir la branca <origen> amb la branca <desti>:
$ git merge <origen>
Si surten conflictes, resoldre'ls amb les eines adequades (IDE, compiladors, etc.).
Caldrà fer de nou totes les proves (tests) pertinents (automatitzades o no).
Per finalitzar el merge, fer un commit i un push
:
$ git commit -am "merge branca origen"
I pujar els canvis:
$ git push
Sovint necessitem tenir submòduls, és a dir, dependències del projecte principal, per exemple, llibreries, que cal incloure perquè el projecte principal funcioni.
Referències:
Prenent el cas que tinguem un projecte Desktop
i una llibreria Lib
, amb els seus repos independents cadascun ja creats, podem incloure Lib
dins de Desktop
fàcilment.
Entrem a la carpeta de Desktop i fem:
$ git submodule add https://github.com/.../Lib $ git commit -am "add lib submodule" $ git push
Ens apareixerà la carpeta Lib
amb el contingut del repo ja clonat.
A partir d'ara, quan clonem el projecte principal en una nova ubicació, ens apareixerà la carpeta Lib
, però estarà buida. Caldrà que inicialitzem els submòduls des de l'arrel amb:
$ git submodule init
I després podem entrar a cadascuna de les llibreries i descarregar el codi pertinent:
$ cd Lib $ git submodule update
Aquest article explica com evitar que git ens vagi demanant les credencials repetidament quan treballem per línia de comandes.
Resumint, es pot fer així:
git config --global credential.helper store git config --global credential.helper cache
No és molt recomanable deixar la cache permanentment.
Si volem limitar la cache durant 10 minuts (600 segons) es pot fer amb un timeout:
git config --global credential.helper 'cache --timeout=600'
Aquest article ens ensenya alguns trucs imprescindibles de Git:
git amend
.
Com eliminar dades sensibles emmagatzemades en un repositori. És fàcil que succeeixi: un arxiu .env
amb dades de desplegament reals, un arxiu de BD o de test amb contrasenyes reals (encara que estiguin hashejades no convé que algú li pugui fer un atac de diccionari), etc.