Laborator 04 - Dezvoltarea aplicațiilor

Introducere

Toate dispozitivele electronice pe care le folosim în viața de zi cu zi, de la latopuri sau calculatoare personale, până la telefoane mobile sau smart watch-uri, au în comun un lucru: rulează software. Având în vedere cât de variate sunt sistemele pe care rulează aplicațiile, trebuie să avem mereu în minte sistemul pentru care creăm o aplicație. De exemplu, dacă aplicația noastră este gândită pentru un ceas inteligent, atunci trebuie să ținem în minte că resursele vor fi limitate; apare astfel o constrângere din punctul de vedere al memoriei disponibile.

Astfel, trebuie să ținem cont de următoarele:

  • ce limbaj de programare folosim
  • cum scriem și compilăm codul sursă
  • cum depanăm codul sursă
  • cum versionăm codul sursă

Vom vorbi despre toate aceste aspecte în acest capitol.

Alegerea limbajului de programare

Există trei categorii de limbaje de programare, grupate în funcție de modul în care codul sursă scris de noi (de limbaj înalt) ajunge să fie rulat pe procesor: compilate, interpretate și hibride. Alegem limbajul de programare potrivit pentru dezvoltarea programului nostru în funcție de ce avem nevoie: să avem un program portabil sau să avem un program rapid sau să avem acces mai ușor la memorie.

În această carte vom folosi limbajul C ca să scriem codul sursă și compilatorul gcc pentru a compila codul sursă, însă mai jos descriem particularitățile fiecărui tip de limbaj de programare.

Limbaje de programare compilate

Programele scrise într-un limbaj compilat sunt analizate de către un program numit compilator înainte ca ele să poată fi rulate pe sistem. În general, limbajele compilate sunt mai rapide în execuție decât cele interpretate sau hibride, deoarece problemele de sintaxă (de scriere) sunt eliminate din faza compilării, înainte să rulăm programul. Neajunsul programelor compilate este faptul că programele NU sunt portabile, adică nu putem lua un program compilat pe calculator să îl rulăm pe un smartwatch; trebuie să recompilăm codul sursă.

Exemple de limbaje compilate sunt C, C++, Fortran, Rust, Go, D.

Limbaje de programare interpretate

Atunci când scriem un program într-un limbaj interpretat, programul este trecut printr-un alt program, numit interpretor care analizează și rulează fiecare linie de cod scrisă, pe rând. Dacă alegem să scriem un program într-un limbaj de programare interpretat, atunci programul nostru este portabil, adică putem să îl rulăm pe orice sistem pe care avem interpretorul instalat. Din cauza faptului că programele sunt analizate și rulate linie cu linie, execuția lor poate fi mai lentă.

Exemple de limbaje interpretate sunt PHP și Perl.

Limbaje de programare hibride

Programele scrise într-un limbaj hibrid trec print-un proces care îmbină etapa de compilare și etapa de interpretare, scopul fiind de a avea în final un program portabil al cărui timp de execuție este mai redus decât în cazul programelor interpretate.

Exemple de limbare hibride sunt Python, Java și C#.

Scrierea codului sursă

Atunci când spunem că dezvoltăm o aplicație, spunem, de fapt, că scriem codul sursă, îl compilăm, îl verificăm de erori. Pentru scrierea codului sursă putem să alegem editoare de text sau medii de dezvoltare integrate (Integrated Development Environment, IDE).

Editoarele de text sunt programe mai simple în care putem edita fișiere text, deci putem dezvolta programe. Ele pot permite instalarea de extensii care aduc funcționalități în plus, specifice pentru un anumit limbaj. Printre cele mai cunoscute editoare de text se numără GNU Nano, Vim, Sublime, Atom, Visual Studio Code.

IDE-urile au anumite funcționalități avansate, multe dintre ele fiind adaptate unui singur limbaj de programare. În plus, ele au integrat un compilator/interpretor pentru limbajul suportat. Astfel, la o simplă apăsare de buton programul este rulat. Printre IDE-uri se număra: Microsoft Visual Studio, Eclipse, IntelliJ, XCode.

În această carte vom folosi GNU Nano ca editor de text principal. Este un editor CLI și se pornește folosind comanda nano, așa cum a fost prezentat în capitolul Lucrul cu fișiere.

Compilarea unui fișier cod sursă C

În această secțiune urmărim să învățăm pașii pentru a compila un program, adică a-l aduce de la cod sursă la executabil. Pentru aceasta vom crea un program care verifică dacă un număr citit de la tastatură este prim sau nu. Vom scrie într-un nou fișier programul care implementează algoritmul, vom compila codul sursă folosind compilatorul GCC și vom testa că programul funcționează.

Crearea unui fișier cod sursă

Creăm un fișier nou cu numele is-prime.c cu implementarea algoritmului de verificare. Copiem codul sursă de mai jos și îl lipim în nano ca în imaginea de mai jos:

#include <stdio.h>
 
int check_if_prime(int n)
{
    int i;
 
    for (i = 2; i <= n / 2; i++) {
        if (n % i == 0) {
            return 0;
        }
    }
 
    return 1;
}
 
int main(void)
{
    int n;
 
    printf("Please gimme a number: ");
    scanf("%d", &n);
 
    if (check_if_prime(n)) {
        printf("%d is prime\n", n);
    } else {
        printf("%d is not prime\n", n);
    }
 
    return 0;
}

Mai multe detalii despre folosirea editorului de text nano găsim în capitolul Lucrul cu fișiere.

Compilarea codului sursă în executabilul a.out

Avem fișierul cod sursă is-prime.c și vrem să obținem un program pe care să-l rulăm pe sistemul nostru. Pentru aceasta, trebuie să compilăm fișierul is-prime.c. Acest program este de fapt un executabil (binar). Executabilele sunt fișiere care conțin instrucțiuni pe care sistemul de calcul le poate interpreta și rula.

Creăm un executabil din fișierul is-prime.c folosind comanda gcc:

student@uso:~$ gcc is-prime.c 
student@uso:~$ ls -l
total 16
-rwxr-xr-x 1 student student 8448 Oct 26 06:34 a.out
-rw-r--r-- 1 student student  406 Oct 26 06:17 is-prime.c

Așa cum vedem în rezultatul rulări comenzii ls -l de mai sus, executabilul se numește a.out. Acesta este numele implicit dat de GCC. Adică a.out va fi numele tuturor fișierelor executabile generate cu GCC, indiferent de fișierul cod sursă. Verificăm că fișierul a.out este într-adevăr un fișier executabil:

student@uso:~$ file a.out 
a.out: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=14553360a84b6dbe4dba5f287a665047572bde7f, not stripped

Acronimele ELF (Executable and Linkable Format) șiLSB* (Linux Standard Base) nu sunt relevante în această carte, dar reținem că atunci când vedem un fișier ELF, acesta este un fișier executabil.

Rulăm executabilul a.out în felul următor și introducem de la tastatură un număr:

student@uso:~$ ./a.out
Please gimme a number: 13
13 is prime

Programul funcționează: citește un număr de la tastatură și afișează dacă acesta este prim sau nu.

Compilarea codului sursă într-un executabil cu nume diferit

Numele a.out este implicit, deci toate programele compilate cu GCC se vor numi a.out. Putem configura un nume diferit pentru executabilul obținut.

Spre exemplu, pentru programul care verifică dacă un număr este prim sau nu, numim executabilul is-prime. Creăm un executabil cu numele is-prime din fișierul is-prime.c folosind opțiunea -o a comenzii gcc:

student@uso:~$ gcc -o is-prime is-prime.c 
student@uso:~$ ls -l
total 28
-rwxr-xr-x 1 student student 8448 Oct 26 06:34 a.out
-rwxr-xr-x 1 student student 8448 Oct 26 06:57 is-prime
-rw-r--r-- 1 student student  406 Oct 26 06:17 is-prime.c
student@uso:~$ file is-prime
is-prime: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=14553360a84b6dbe4dba5f287a665047572bde7f, not stripped

Opțiunea -o urmată de numele ales pentru program (is-prime) transmite compilatorului ca programul să se numească is-prime, și nu a.out. Rulăm executabilul is-prime în felul următor și introducem de la tastatură un număr:

student@uso:~$ ./is-prime
Please gimme a number: 13
13 is prime

Vedem că, deși au nume diferit, programele a.out și is-prime au același comportament. Acest lucru este normal deoarece ele sunt 2 fișiere executabile obținute din același fișier cod sursă obținute folosind același compilator: GCC.

Exerciții

  1. Creați un fișier cu numele is-palindrome.c care să conțină următorul conținut:
#include <stdio.h>
 
int check_if_palindrome(int n)
{
    int new_n = 0;
    int old_n = n;
 
    while (n > 0) {
        int r = n % 10;
        n /= 10;
        new_n = new_n * 10 + r;
    }
 
    return (new_n == old_n) ? 1 : 0;
}
 
int main(void)
{
    int n;
 
    printf("Please gimme a number: ");
    scanf("%d", &n);
 
    if (check_if_palindrome(n)) {
        printf("%d is a palindome\n", n);
    } else {
        printf("%d is not a palindrome\n", n);
    }
 
    return 0;
}
  1. Compilați fișierul is-palindrome.c într-un executabil cu numele a.out folosind gcc. Verificați funcționalitatea programului.
  2. Compilați fișierul is-palindrome.c într-un executabil cu numele is-palindrome folosind gcc. Verificați funcționalitatea programului.

Introducere în Git și GitHub

Vor fi cazuri când vom strica o versiune a codului și vom avea nevoie să revenim la o versiune corectă, caz în care un istoric de versiuni ne-ar fi de folos. Vom putea să lucrăm la un proiect de pe un alt sistem, în afară de al nostru, sau vom vrea să cerem feedback pe codul scris de noi.

Când vorbim despre un proiect software vrem să avem dezvoltatori, oameni care să lucreze împreună cu noi la proiect. Dezvoltatorii au nevoie de acces la codul sursă al proiectului software la care lucrăm. După ce le dăm acces, vrem ca fiecare dezvoltator să știe la ce a lucrat și la ce lucrează ceilalți; ca să nu se suprapună, ca să ajute și ca să ofere feedback.

Pentru a putea rezolva problemele de sincronizare între doi sau mai mulți colegi de echipă care lucrează la același proiect, ne ajută să avem un sistem de versionare a codului, adică să avem un istoric de modificări. Fiecare modificare înseamnă o nouă versiune a proiectului; avem astfel o listă de versiuni gestionată de sistemul de versionare a codului. Pe lângă rezolvarea problemelor de sincronizare, versionarea codului aduce și alte avantaje cum ar fi revenirea la o versiune mai veche a proiectului, găsirea rapidă a autorului unei secvențe de cod sau, pur și simplu, organizarea unui proiect.

Git este un sistem de management și versionare a codului sursă care permite lucrul eficient la un proiect software.

GitHub este o platformă online, bazată pe Git, pe care dezvoltatorii o pot folosi pentru a stoca și versiona codul lor sursă. Git este utilitarul folosit, iar GitHub este serverul și aplicația web pe care rulează acesta, locul în care păstrăm repository-ul remote.

Similar cu GitHub există și alte platforme precum Bitbucket sau GitLab. Comenzile pe care le vom studia se aplică pentru toate platformele care folosesc Git, doar interfața grafică diferă.

În această carte vom folosi GitHub ca suport. În mare parte, acesta nu diferă foarte mult de alte platforme.

Crearea unui cont pe GitHub (dacă nu aveți deja)

Înainte de toate, ne asigurăm că avem cont pe GitHub. Dacă aveți deja un cont pe GitHub, puteți trece la subsecțiunea următoare: Pregătirea inițială a mediului Git.

Dacă nu aveți cont, intrați pe GitHub. Pagina de pornire va arăta similar cu cea din imaginea de mai jos.

Introduceți un nume de utilizator (username), adresa voastră de e-mail și o parolă sigură pentru cont. Pentru validarea contului, accesați-vă căsuța de e-mail. Acolo veți găsi un e-mail în care vi se explică cum se poate valida noul cont creat. Verificați și căsuța spam în caz că nu ați primit nimic în inbox.

GitHub Student Pack

GitHub oferă studenților numeroase beneficii care în mod normal sunt contra cost (plătite). Găsiți mai multe detalii pe site-ul oficial.

Pregătirea inițială a mediului Git

Ca să utilizăm Git, facem în primă fază niște pași de configurare. Adică vom configura numele și e-mail-ul nostru, ca mai jos:

student@uso:~$ git config --global user.name "Prenume Nume"
student@uso:~$ git config --global user.email "adresa_de_email@example.com"

În listingul de mai sus “Prenume Nume” și ”adresa_de_email@example.com” sunt placeholdere. Le înlocuiți cu datele voastre. De exemplu, pentru autorul acestei secțiuni, comenzile rulate sunt:

student@uso:~$ git config --global user.name "Liza Babu"
student@uso:~$ git config --global user.email "lizababu@example.com"

Crearea primului repository

Pentru a lucra la un proiect software, creăm un repository software. Vom crea unul pe GitHub, unul local, după care le vom interconecta.

Repository software

Proiectul este stocat într-un repository software. Repository-ul conține fișierele proiectului: codul sursă, fișiere de configurare. De obicei acesta vine însoțit și de un fișier README.md în care se găsesc informații despre proiect: care este scopul proiectului, cum se compilează, pe ce platforme rulează.

Repository-urile sunt de două tipuri: locale și remote. Acestea pot fi interconectate și să refere de fapt același proiect. Repository-ul local este cel pe care îl avem la noi pe calculator, pe când cel remote este unul stocat pe un server (în cazul nostru GitHub). Este doar o diferență de perspectivă între cele două, ele nu diferă din punct de vedere tehnic. De obicei, într-un proiect Git / GitHub există un repository central (remote) și mai multe repository-uri secundare (locale), câte unul pentru fiecare dezvoltator din echipa proiectului.

Printre cele mai importante operații cu un repository sunt: init, fork, clone. Vom detalia aceste operații când le vom folosi în acest capitol.

Crearea unui repository gol pe GitHub

Ne autentificăm pe GitHub. Urmărim pașii prezentați în imaginea de mai jos și explicați imediat după.

  1. Apăsăm pe săgeată din meniul din dreapta sus și vedem ceva similar cu imaginea de mai sus.
  2. Apăsăm pe Your profile pentru a merge pe profilul nostru. Aici este locul în care vom putea vedea contribuțiile noastre pe GitHub. În partea de sus a ecranului vom vedea un meniu orizonatal care conține 4 opțiuni: Overview, Repositories, Projects și Packages.
  3. Apăsăm pe Repositories. Acum vom vedea întreaga listă de repository-uri pe care le avem. Pentru a crea unul nou, apăsăm pe butonul verde din dreapta sus pe care scrie New.
  4. Acum este momentul în care vom da un nume proiectului nostru, o descriere succintă a acestuia și vom putea decide dacă să fie public (vizibil tuturor utilizatorilor) sau privat (vizibil doar pentru noi și eventualii colaboratori ai proiectului). Ne va apărea un formular similar cu cel din imaginea de mai sus. Pentru acest tutorial vom crea un repository public. Este indicat ca numele repository-ului să descrie bine proiectul, în cazul nostru array-sorting-algorithms. Descrierea proiectului este opțională, dar e recomandat să o adăugăm pentru a fi ușor de înțeles pentru cei care vor ajunge la proiectul nostru.
  5. Apăsăm pe Create repository. Vor apărea câteva instrucțiuni pentru crearea unui repository local nou și conectarea celui nou cu cel remote. Acest lucru este acoperit în secțiunile următoare.

Acum avem un repository creat remote, pe GitHub, numit array-sorting-algorithms.

Crearea unui repository gol local

Creăm un director din ierarhia de fișiere în care vom inițializa repository-ul Git.

În acest tutorial creăm directorul array-sorting-algorithms în directorul home (adică /home/student sau ~), folosind comenzile de mai jos:

student@uso:~$ pwd
/home/student
student@uso:~$ mkdir array-sorting-algorithms
student@uso:~$ cd array-sorting-algorithms
student@uso:~/array-sorting-algorithms$ git init
Initialized empty Git repository in /home/student/array-sorting-algorithms/.git/
student@uso:~/array-sorting-algorithms$ ls -a
./    ../   .git/

Mai sus am inițializat repository-ul local prin comanda git init, dată în directorul ales (array-sorting-algorithms) din directorul home al utilizatorului student (/home/student).

Acum avem un repository creat local, numit array-sorting-algorithms.

Init

Operația init este una locală și are rolul de a inițializa un repository gol, local. Inițializarea repository-ului local înseamnă crearea, în directorul ales, a mediului pentru a putea lucra la un proiect software versionat Git. Această operare duce la crearea unui director numit .git în care se vor ține ulterior date suplimentare despre repository, numite metadatele repository-ului.

Am folosit opțiunea -a (ls -a) pentru a afișa și fișierele și directoarele ascunse. Directorul .git este un director ascuns.

Conectarea celor două repository-uri

Am creat până în acest moment un repository local și unul remote. Trebuie să le interconectăm pentru a lucra cu ele.

În cazul în care suntem mai mulți membri în echipă, fiecare membru va conecta repository-ul său local, la repository-ul remote. Pentru conectarea celor două repository-uri folosim comanda de mai jos, dată în directorul unde este repository-ul local Git (în cazul nostru /home/student/array-sorting-algorithms):

student@uso:~/array-sorting-algorithms$ git remote add origin https://github.com/{username}/array-sorting-algorithms.git

În comanda de mai sus {username} este numele utilizatorului nostru de pe GitHub. De exemplu, pentru autorul acestui capitol, {username} se înlocuiește cu lizababu.

Conectarea celor două repository-uri înseamnă setarea repository-ului origin, adică repository-ului remote la care se conectează cel local.

Imaginea de mai jos arată cum arată cum se contectează repository-urile remote și local. Sincronizarea lor se face prin intermediul operațiilor push și pull care sunt prezentate pe parcursul secțiunii app_dev_first_commits.

Primele commituri

Odată creat repository-ul, putem să începem să lucrăm la proiect.

Lucrul la proiect înseamnă să adăugăm și să ștergem fișiere sau să modificăm fișiere existente. De obicei este vorba de fișiere text (human-readable), cel mai des fișiere cod sursă1). Vrem să salvăm aceste adăugări și modificări; apoi să salvăm din nou alte modificări; și tot așa.

Salvarea acestor modificări înseamnă crearea unui commit în repository.

Același lucru îl fac și ceilalți colegi care lucrează la același proiect. Fiecare commit împachetează un set de adăugări și modificări realizate de un dezvoltator al proiectului. Având commiturile în repository putem să gestionăm mai ușor proiectul, adică:

  • să revenim la un commit anterior (adesea chiar ultimul) dacă modificările cele mai recente “strică” proiectul
  • să vedem cine este autorul anumitor modificări
  • să creăm o ramură de dezvoltare separată pornind de la un commit anterior, pe care să încercăm o funcționalitate nouă, fără a afecta restul proiectului

Git se ocupă de păstrarea și gestiunea istoricului repository-ului nostru prin păstrarea listei de commituri făcute. Adică Git păstrează un istoric de versiuni al proiectului.

Când facem un commit, acesta va fi reținut în repository-ul Git local, nu și în repository-ul Git remote.

Fără a actualiza și repository-ul remote, ceilalți colegi nu vor putea vedea schimbările făcute de noi. Vrem, așadar, ca modificările făcute local să se găsească și remote. Adică să publicăm commiturile din repository-ul local în repository-ul remote. Realizăm publicarea prin operația push.

Vom vedea în următoarele secțiuni care sunt pașii pentru a crea un commit și pentru a-l publica.

În următoarele secțiuni vom lucra în repository-ul array-sorting-algorithms creat în secțiunea Introducere în Git și GitHub. Vom crea, pas cu pas, un proiect software scris în limbajul de programare C, care conține mai mulți algoritmi de sortare a unui vector de elemente întregi.

Punctual, în această secțiune, vom crea fișierul README al proiectului și scheletul de cod pentru algoritmii de sortare Bubble Sort, Merge Sort și Radix Sort. Vom crea commituri în repository-ul local pentru fiecare schimbare, după care vom publica commiturile astfel încât schimbările să fie vizibile și pe GitHub, în repository-ul remote.

Adăugarea unui fișier README

Reamintire

O bună practică, prezentă în majoritatea proiectelor software, este să adăugăm un fișier README în care se află informații despre un proiect. Spre exemplu, în README se află informații despre ce funcționalități are proiectul nostru, cum se compilează un proiect, cum se rulează, pe ce tip de platforme poate fi rulat etc.

Un fișier README este un fișier text. Îl putem crea și îi putem adăuga titlul Sorting Algorithms for Beginners folosind un editor sau, mai simplu și mai direct, folosind comanda de mai jos:

student@uso:~/array-sorting-algorithms$ echo "# Sorting Algorithms for Beginners" > README.md
student@uso:~/array-sorting-algorithms$ ls -a
./         ../        .git/      README.md

Caracterul # din fața textului Sorting Algorithms for Beginners are rol de a formata textul sub formă de titlu. Nu intrăm în mai multe detalii aici pentru că nu face obiectul cărții.

Folosim extensia .md care semnalează un fișier de tip Markdown. Facem acest lucru deoarece pe GitHub fișierele README sunt afișate în format Markdown. Acest format este simplu de înțeles, însă nu face obiectul acestei cărți, deci nu vom insista pe înțelegerea lui.

Crearea primului commit

Acum avem în repository un nou fișier: README.md. Vrem să reținem acest lucru în repository prin crearea unui commit, primul.

Pașii creării unui commit sunt următorii:

  1. Verificăm repository-ului. Cu alte cuvinte, verificăm ce modificări au fost făcute în repository de la ultimul commit.
  2. Adăugăm fișierele pe care vrem să le împachetăm într-un commit în staging area, adică în lista de fișiere pe care Git le organizează.
  3. Alegem un mesaj de commit. Creăm commitul.
  4. Publicăm commitul și pe repository-ul remote.

Detaliem acești pași în continuare.

Verificarea stării repository-ului local

Prin starea repository-ului înțelegem forma la care am adus proiectul prin modificările noastre. Aceasta include ce fișiere am creat, modificat sau șters de la ultimul commit. Ne interesează întotdeauna starea repository-ului pe care lucrăm.

Pentru a verifica starea repository-ului folosim comanda git status:

student@uso:~/array-sorting-algorithms$ git status
On branch master
 
No commits yet
 
Untracked files:
(use "git add <file>..." to include in what will be committed)
 
    README.md

Prima linie afișată On branch master se referă la branch-ul master local. Vom discuta în secțiunea Lucrul pe branch-uri despre branch-uri.

A doua linie afișată No commits yet ne spune că nu am făcut până acum niciun commit, adică am pornit de la un repository gol.

În ultima parte a outputului se află o listă de fișiere untracked, adică lista fișierelor pe care Git le vede ca nou adăugate în repository-ul curent, dar pe care nu le monitorizează încă. Acest lucru înseamnă că, deocamdată, orice modificare vom face asupra acestor fișiere nu va fi urmărită (tracked) de Git. În cazul nostru, fișierul aflat în starea untracked este README.md.

Adăugarea unui fișier (în staging area)

Un commit va conține o listă de modificări: fișiere adăugate, fișiere șterse, conținut modificat. Un pas intermediar în crearea unui commit este pregătirea modificărilor ce vor fi parte din commit. Acest pas de pregătire înseamnă să adăugăm (add) aceste modificări într-o zonă de lucru pentru Git, numită staging area.

În cazul nostru, vrem să adăugăm fișierul README.md în staging area. Facem acest lucru folosind comanda git add:

student@uso:~/array-sorting-algorithms$ git add README.md

Verificăm ce s-a schimbat în urma adăugării fișierului README.md în staging folosind comanda git status:

student@uso:~/array-sorting-algorithms$ git status
On branch master
 
No commits yet
 
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
 
    new file:   README.md

Primele 2 mesaje afișate au rămas neschimbate. Partea interesantă apare la ultima parte a outputului. Vedem că mesajul a devenit Changes to be commited. Acest lucru înseamnă că acum Git urmărește noile modificări și așteaptă ca modificările să fie adunate într-un commit.

Crearea commitului local

Acum vrem ca modificările de mai sus să ajungă în repository. Pentru aceasta creăm un commit folosind comanda git commit:

student@uso:~/array-sorting-algorithms$ git commit -m "Add README file"
[master (root-commit) b2a590a] Add README.md
1 file changed, 1 insertion(+)
create mode 100644 README.md  
student@uso:~/array-sorting-algorithms$ git status
On branch master
nothing to commit, working tree clean  

Am folosit descrierea Add README file la comanda git commit drept mesaj de commit2). Aceasta este o descriere succintă a modificărilor făcute prin acest commit.

Crearea unui nou commit

În continuare vom adăuga scheletul de cod pentru algoritmul Bubble Sort în repository. Vom crea un nou fișier cod sursă C bubble-sort.c și vom scrie în el scheletul de cod pentru algoritm. Vom crea un nou commit care va conține fișierul bubble-sort.c. Pentru aceasta vom folosi un editor, precum nano, ca în imaginea de mai jos:

Mai sus am creat un commit cu fișierul bubble-sort.c urmând pași similari cu cei din secțiunea Crearea commitului local:

student@uso:~/array-sorting-algorithms$ git status
(...)
student@uso:~/array-sorting-algorithms$ git add bubble-sort.c
student@uso:~/array-sorting-algorithms$ git status
(...)
student@uso:~/array-sorting-algorithms$ git commit -m "Add Bubble Sort skeleton"
(...)

Conținutul fișierului bubble-sort.c este:

#include <stdio.h>
 
static void sort(void)
{
    // TODO: add bubble sort algorithm here
}
 
int main()
{
    return 0;
}
Exerciții
  1. Creați un nou fișier numit radix-sort.c cu următorul conținut:
#include <stdio.h>
 
static void sort(void)
{
    // TODO: add radix sort algorithm here
}
 
int main()
{
    return 0;
}
  1. Creați un commit care să conțină fișierul radix-sort.c. Folosiți următorul mesaj de commit: Add Radix Sort algorithm skeleton.
  2. Dați comanda de verificare git log. Detaliem outputul comenzii git log în subsecțiunea Verificarea istoricului de commituri.
  3. Creați un nou fișier numit merge-sort.c cu următorul conținut:
#include <stdio.h>
 
static void sort(void)
{
    // TODO: add merge sort algorithm here
}
 
int main()
{
    return 0;
}
  1. Creați un commit care să conțină fișierul merge-sort.c. Folosiți următorul mesaj de commit: Add Merge Sort algorithm skeleton.
  2. Dați comanda de verificare git log.

Crearea unui commit cu modificări în fișiere existente

Până acum am creat commituri care conțineau un fișier nou creat. În această secțiune vom modifica conțintului fișierului README.md și vom crea un nou commit, așa cum apare în comenzile de mai jos:

student@uso:~/array-sorting-algorithms$ echo "We implement 3 sorting algorithms for integer arrays." >> README.md
student@uso:~/array-sorting-algorithms$ git status
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:   README.md

no changes added to commit (use "git add" and/or "git commit -a")
student@uso:~/array-sorting-algorithms$ git add README.md
student@uso:~/array-sorting-algorithms$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

    modified:   README.md

student@uso:~/array-sorting-algorithms$ git commit -m "Update README with project explanation"
t explanation"
[master 247b87f] Update README with project explanation
1 file changed, 1 insertion(+)

Spre deosebire de secțiunea Crearea unui nou commit, unde comanda git status arăta că fișierul modificat (în acel caz, bubble-sort.c) este nou (new file), acum comanda git status arată că fișierul modificat (în acest caz, README.md) a fost modificat (modified). Deși apare această diferență în outputul comenzii git status, pașii pentru crearea unui commit care conține un fișier nou sau unul deja existent (dar modificat) sunt aceiași.

Exerciții
  1. Modificați continutul fișierului README.md în # Sorting Algorithm for Integer Arrays.
  2. Creați un commit care să conțină modificările la fișierul README.md. Folosiți următorul mesaj de commit: Update README title.

Verificarea istoricului de commituri

La orice pas al dezvoltării proiectului vrem să știm în ce stadiu ne aflăm ca să ne dăm seama ce am făcut deja și ce trebuie să mai facem în continuare. De aceea folosim un sistem de versionare a codului, în cazul nostru Git. Verificăm istoricul commiturilor folosind comanda git log:

student@uso:~/array-sorting-algorithms$ git log
commit 66b7c5fabb93b521326e6cd9ff219a06a3aec064 (HEAD -> master)
Author: Liza Babu <lizababu@example.com>
Date:   Thu Sep 24 10:40:06 2020 -0700

    Update README title

commit 247b87f3f317816a204c4512f6fd9914527a03ad
Author: Liza Babu <lizababu@example.com>
Date:   Thu Sep 24 09:50:30 2020 -0700

    Update README with project explanation

commit 3c835b0d8e7fc88ef45dfd3681867c21b75ed588
Author: Liza Babu <lizababu@example.com>
Date:   Thu Sep 24 09:45:13 2020 -0700

    Add Merge Sort algotihm skeleton

commit b92a52c0fc5d66dce4b2562114cc84ea326b2763
Author: Liza Babu <lizababu@example.com>
Date:   Thu Sep 24 09:44:36 2020 -0700

    Add Radix Sort algotihm skeleton

commit f65a7fbe8bbe1b36ba5c8e16607456a879bfb6fa
Author: Liza Babu <lizababu@example.com>
Date:   Thu Sep 24 09:21:49 2020 -0700

    Add Bubble Sort algorithm skeleton

commit b2a590a8637f1eab96e557334dbd4be14bf95833
Author: Liza Babu <lizababu@example.com>
Date:   Thu Sep 24 09:09:51 2020 -0700

    Add README file

Navigați prin outputul comenzii git log prin intermediul săgeților sus/jos. Apăsați tasta q când ați terminat de inspectat.

În cazul autorului acestui capitol, numele, prenumele și emailul sunt Liza Babu <lizababu@example.com>, așa cum apare în exemplul de mai sus: Author: Liza Babu <lizababu@example.com>.

Fiecare commit este identificat unic printr-un cod, numit cod hash3). Discutăm în continuare despre ultimul commit din listă. Acesta are codul hash 66b7c5fabb93b521326e6cd9ff219a06a3aec064 și mesajul de commit Update README title.

Acum vedem că repository-ul indică spre acest nou commit. Ne dăm seama de acest lucru pentru că HEAD se află în dreptul commitului tocmai făcut. HEAD ne indică starea repository-ului, adică ne arată care este ultimul commit pe care l-am făcut în repository.

Publicarea commiturilor în repository-ul remote

Vrem să publicăm pe GitHub toate schimbările făcute, pentru a fi vizibile și altor colaboratori ai proiectului. Publicăm commitul folosind comanda git push:

student@uso:~/array-sorting-algorithms$ git push origin master
Counting objects: 18, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (18/18), 1.95 KiB | 222.00 KiB/s, done.
Total 18 (delta 3), reused 0 (delta 0)
remote: Resolving deltas: 100% (3/3), done.
To https://github.com/lizababu/array-sorting-algorithms.git
* [new branch]      master -> master

În felul acesta commiturile locale au fost publicate (“împinse”, push) din repository-ul local în repository-ul remote identificat de origin. Commiturile locale se aflau pe branch-ul master din repository-ul local și au fost publicate tot în branch-ul master al repository-ului origin. Vorbim despre branch-uri în secțiunea Lucrul cu branch-uri.

Ca să verificăm publicarea commiturilor, folosim interfața GitHub:

Obținerea commiturilor din repository-ul remote

În lucrul cu Git / GitHub, există bune practici pe care recomandăm să le urmăm.

Atunci când ne apucăm de lucru vrem să sincronizăm repository-ul local cu cel remote. Pot apărea diferențe în momentul în care altcineva a publicat schimbări remote după ce am făcut noi ultima sincronizare. În momentul în care cineva a publicat modificări asupra unei secvențe de cod pe care și noi o modificăm, apar conflicte. Conflictele trebuie rezolvate.

Facem acest lucru prin operația pull, care aduce local toate modificările și încearcă să rezolve conflicetele în mod automat4). Dacă rezolvarea conflictelor nu se poate face automat, trebuie să ne ocupăm de acest pas.

Note de subsol

Cuprins

2) Mesajele de commit trebuie să fie punctuale și ușor de înțeles. Alte persoane care lucrează la același proiect software vor vrea să înțeleagă rapid ce am modificat printr-un anumit commit. Recomandări punctuale legate de crearea unor bune mesaje de commit găsiți aici: https://chris.beams.io/posts/git-commit/
3) Codul hash este calculat ca o sumă de control SHA-1 a conținutului commitului.
4) Noi am pornit de la un repository gol, așadar operația pull nu a fost necesară.
uso/laboratoare/ac/laborator-04.txt · Last modified: 2020/11/10 09:09 by ioana_maria.culic
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0