Pontosan mi is az a Git és Github és mire használjuk őket?

[link]

[link] Hub

git: protokol adatátvitelre.

github: nyílt tároló, amire a git protokolon lehet fel - le tölteni.

Egyedül, kezdő programozóként bár kísérletezni tudsz vele, de igazán jól majd a munkahelyeden fogod megismerni, amikor másokkal együtt kell dolgoznod. Ez nem véletlen, mivel egy olyan eszközről van szó, ami a csapatmunkát teszi könnyebbé.

Az, hogy mi a git, arról rengeteg leírást találhatsz a neten. Én inkább arra mennék rá, hogy mi a cégnél hogyan használjuk és mi a szerepe a fejlesztési folyamat során. Az egész az úgynevezett branch-eken alapul. Egy branch a szoftvernek egy adott változatát tartalmazza. Amikor elkezdődik a szoftver fejlesztése, létrejön a develop főág, ami a legfrissebb fejlesztés alatt álló verziót tartalmazza. Egy új fejlesztési igény két fő kategóriába sorolható, mégpedig vagy egy új funkció fejlesztéséről van szó (feature), vagy egy hiba kijavításáról (bugfix). Jó kérdés, hogy hova soroljuk az olyan munkákat, amik csak szebbé teszik az új kódot de a működésén nem változtat (refaktor). Mi ezt is feature-nek hívjuk - fuck logic.

Kis kitérő: a fejlesztési feladatokhoz általában tartozik egy leírás, hogy mit kell csinálni. Ezeket egy jegykezelő rendszer tárolja, amit issue trackernek vagy ticket management rendszernek neveznek - ilyen például a Jira. Egy ilyen jegy leírja, hogy

- a fejlesztés végén mi az elvárt működés,

- a fejlesztési feladat fontosságát ("jó lenne, de tudunk élni nélküle", "mindenképp meg kell csinálni", "sürgős", "kritikus", "ég a ház, mindenki ezen dolgozzon")

- hogyan áll a fejlesztés folyamata,

- ki vette fel a jegyet,

- ki dolgozik éppen rajta,

- van kommentszekció, ahol meg lehet beszélni a felmerült kérdéseket,

- esetleg tartalmaz technikai részleteket is.

Ezeknek a jegyeknek van egy azonosítószáma is. Tegyük fel, hogy fejlesztünk egy tök fancy kis YouTube letöltőt. Egy hozzá kapcsolódó jegy így nézhet ki:

YTD-1345: Downloaded files are not deleted when the client does not finish downloading it from the server in 5 minutes

Reporter: Istvan Humbak

Assignee: Unassigned

Status: Ready for development

Type: Bug

Severity: High

Affected components: YouTube downloader backend service

Reproducable: yes

Description: Currently, the backend service waits 5 minutes to delete the downloaded file after the file is downloaded to the server. If the file transfer to the end user does not complete in 5 minutes, the file remains open so that the backend service fails to delete it.

Known workarounds: Manually delete the files that are not required anymore.

Steps to reproduce:

.. 1) Start downloading a video from YouTube.

.. 2) When the server finished downloading the file and the user is prompted to save the file to his/her computer, slow down your internet connection so that the download takes more than 5 minutes to complete.

.. 3) After 5 minutes elapsed, complete the download. Obtain the file name on the server from logs and check if the file exists.

Expected result: The file does not exist on the server.

Actual result: The file exists on the server and never deleted.

Először is magunkra vesszük a feladatot, így a jegy módosul:

Assignee: Tamas Humbak

Majd beállítjuk a jegyen, hogy dolgozunk rajta:

Status: In dev

Most, hogy ezt a feladatot magunkra vettük, láthatjuk, hogy "Type: Bug", vagyis egy hibát kell kijavítanunk. A develop branch-ből csinálunk egy saját ágat és elnevezzük mondjuk "bugfix/develop/YTD-1345"-re. Ezt azért, mert ez a következő információkat tartalmazza számunkra, ha a jövőben megnéznénk, milyen változásokat csinált a csapat:

- milyen feladatot végeztünk (feature vagy bugfix)

- melyik ágba kell beleolvasztani, ha a fejlesztés elkészült (a develop-ba)

- mi a jegy száma, ami alapján megkereshetjük a (YTD-1345).

Mivel tesztvezérelt fejlesztési módszertannal dolgozunk, ezért először kell egy teszteset, ami a kód jelenlegi állapotára elbukik. Ha a fejlesztési feladattal elkészülünk, ez a teszt zöld színnel fogja jelezni, hogy a hibajavításunkat tartalmazó kód helyesen működik. Majd megcsináljuk a tényleges fejlesztést. A GIT-ben láthatjuk, hogy változtattunk fájlokat:

Added: YoutubeDownloader/Backend/HostedServices/FileDeletionHostedService.cs

Modified: YoutubeDownloader/Backend/HostedServices/DownloaderHostedService.cs

Added: YoutubeDownloaderTests/Backend/HostedServices/FileDeletionHostedServiceTests.cs

Commit-oljuk a változtatásainkat, push-oljuk a GIT remote tárolóba, majd előkészülünk arra, hogy a kollégáinkkal átnézzük az alkotásunkat. Ennek az eszköze lesz az ún. pull request.

Egy pull request létrehozásakor:

0) beállítjuk a jegyet, így az új státusza "In code review" lesz

1) megmondjuk, hogy melyik branch tartalmazza a mi változásainkat (bugfix/develop/YTD-1345)

2) megmondjuk, hogy ezeknek a változásoknak melyik branchbe kell bekerülnie (develop)

3) képernyőképet csatolunk bizonyítékként, hogy a tesztjeink lefutottak (a cégnél nincs konfigurálva értelmes rendszer, ami a teszteket automatikusan lefuttatná)

4) megjelöljük azokat a kollégákat, akiknek át kell nézniük és véleményezniük kell a kódot.

Ha tegyük fel, a kollégák a megoldásunkkal mindent rendben találtak, és a változtatásunk nem ütközik más kollégák munkájával (mondjuk mert ők egy másik feladat keretében a kódnak ugyanabba a részébe nyúltak bele, mint mi; ezt merge conflict-nak nevezzük), akkor a bugfix/develop/YTD-1345 branch-ünk mergelve lesz a developba. Ez azt jelenti, hogy a develop-ban lévő kódban most már benne van a mi szép új munkánk is. Nem felejtjük el átállítani a jegyet az új státuszába, miszerint "Ready for testing" - azaz a jegy a tesztelőkhöz kerül és elkezdődhet annak a vizsgálata, hogy

- a javításunk valóban azt csinálja, amit kell neki,

- és hogy már meglévő funkciókban nem rontottunk-e el semmit (ez utóbbit hívják regressziós tesztelésnek).

Aztán új feladatot nézünk. Ha időközben kiderül, hogy a megoldásunkkal gond van, akkor visszatérünk a jegyhez készített branch-re és tovább dolgozunk rajta.

A dolognak a nehéz része az, hogy mi van, ha a mi munkánk ütközik más munkájával. Ez az a rész, amit nem tudsz úgy igazán átélni otthon. Nyilván ki lehet ezt is próbálni, de na... nincs meg az a szépsége, hogy meg kell érteni egy más által írt kódot.

Az addig érthető, hogy mondjuk több százan dolgoznak, a világ különböző részein egy projekten és mindenkinek van egy kis feladata, amit hozzátesz a nagy közöshöz, de ezzel ki is fújt.

De végül is pont erre találták ki!