Szofttech labor2 kvíz
A VIK Wikiből
A kvíz a 2024-es laborok beugróinak kérdései alapján lett létrehozva
Mit jelent a kalap (^) operátor Git esetén?
- a segítségével a megadott referencia szülőjére hivatkozhatunk
- a kalap operátor régen volt használva a központosított verziókezeléshez, ma már nincs jelentése
- a git checkout parancsban a commit neve után írva létrehoz egy branch-et, ami commit-ra hivatkozik
- azonnali visszajelzés
Melyik állítás NEM igaza kézponti függőségkezelésre?
- A függőségek egyedileg vannak azonosítva
- Lehetőséget biztosít a tranzitív függőségkezelésre
- Lehetőség van a függőségeket saját szerveren tárolni.
- Az összes fenti állítás IGAZ
Mi igaz a Healthy Branch mintára?
- A branch-en minden egyes commit után automatikus ellenérzéseket futtatunk.
- A fejlesztők a healthy branch-en keresztül integrálják a munkájukat, onnan leszedve és összefésülve a többiek változtatásait, majd —ha működik — akkor a saját változtatásaikat is vissza integrálják.
- Ez a branch egy megosztott ág, ami a termék aktuális állapataként szolgál
- Egy új funkcióval kapcsolatos minden munkát egy külön, saját ágon végezzük„ és csak akkor integráljuk vissza a healthy branch-re, amikor kész az új funkció.
Válaszd ki az igaz állítást a Git-en történő változtatások visszavonásával kapcsolatban:
- A git revert úgy vonja vissza a változtatást, hogy a HEAD- x et (és vele a branch-et) a jelenlegi commit szülőjére (ősére) mozgatja.
- A git reset használandó akkor, ha a visszavonást, mint változtatást meg akarjuk osztani másokkal.
- Amennyiben távoli (remote) branch-en is meg akarjuk osztani a visszavonást, mindegy, hogy git reset-et, vagy git revert-et használunk.
- Az összes fenti állítás HAMIS
Mi a tesztvezérelt fejlesztés (test-driven development, TDD) lépéseinek helyes sorrendje?
- 1) Kód írása; 2) Teszt írása; 3) Refactor
- 1) Teszt írása; 2) Kód írása; 3) Refactor
- 1) Kód írása; 2) Refactor; 3) Teszt írása
- 1) Teszt írása; 2) Refactor; 3) Kód írása
Mi a commit?
- A verziótörténet
- Több branch (ág) változtatásainak "összefésülése"
- Összetartozó változtatások metaadattal
- Egy codeline
Mely állítások igazak a kiadás mintákra?
- A Release Branch minta esetén a kiadandó verzió branch-e új funkciókat nem fogad, csak hibajavításokat
- A Release-Ready Mainline minta esetén a kiadandó verzió branch-e új funkciókat nem fogad, csak hibajavításokat
- A Release-Ready Mainline minta esetén a kiadandó szoftververzió egy külön, release branch-en található
- A Release Branch minta esetén a kiadandó szoftververzió egy külön, release branch-en található
Mi igaz a refaktorálásra?
- A meglévő kód átstrukturálására szolgáló technika
- Tipikus felhasználása a kód olvashatóságának javítása
- A belső struktúrát a kívülről látható viselkedés megváltoztatása nélkül alakítja át
- Tipikus felhasználása a teljesítmény javítása
Mi jellemző a központosított verziókezelő rendszerekre?
- A teljes történet csak a központi szerveren található meg!
- A GitHub egy példa rá
- Az ütközések elkerülése érdekében zárolást lehet alkalmazni
- A fejlesztők helyi gépén tipikusan csak egy adott verzióhoz tartozó fájlok vannak letöltve.
Mi igaz a git pull parancsra?
- Feltölti a lokális változásokat (commit-okat) a távoli repository-ba (tároló, tárhely)
- Hatása megegyezik a git fetch és git merge egymás utáni kiadásával.
- Módosítja a távoli repository (tároló, tárhely) állapotát
- A fenti ÖSSZES állítás igaz
Mely állítások igazak a távoli branch-ekre (remote branch, távoli ág)?
- Kiválasztás (checkout) esetén lecsatolják a HEAD-et
- A távoli branch-ek a lokális repository (tárhely) állapotát tükrözik
- Elnevezési konvenciójuk: <remote neve>/<branch neve> (pl.: origin/main)
