Szofttech labor2 kvíz

A kvíz a 2024-es laborok beugróinak kérdései alapján lett létrehozva

Szoftvertechnológia labor2 beugró

Kvízek használata, importálása, fejlesztése.
Statisztika
Átlagteljesítmény	-
Eddigi kérdések	0
Kapott pontok	0
Alapbeállított pontozás	(+)
-
Beállítások
Minden kérdés látszik	-
Véletlenszerű sorrend	-
-

Mit jelent a kalap (^) operátor Git esetén?

Típus: egy. Válasz: 1. Pontozás: -.

1. a segítségével a megadott referencia szülőjére hivatkozhatunk
2. a kalap operátor régen volt használva a központosított verziókezeléshez, ma már nincs jelentése
3. a git checkout parancsban a commit neve után írva létrehoz egy branch-et, ami commit-ra hivatkozik
4. azonnali visszajelzés

Melyik állítás NEM igaz a központi függőségkezelésre?

Típus: egy. Válasz: 4. Pontozás: -.

1. A függőségek egyedileg vannak azonosítva
2. Lehetőséget biztosít a tranzitív függőségkezelésre
3. Lehetőség van a függőségeket saját szerveren tárolni.
4. Az összes fenti állítás IGAZ

Mi igaz a Healthy Branch mintára?

Típus: egy. Válasz: 1. Pontozás: -.

1. A branch-en minden egyes commit után automatikus ellenérzéseket futtatunk.
2. 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.
3. Ez a branch egy megosztott ág, ami a termék aktuális állapataként szolgál
4. 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:

Típus: egy. Válasz: 4. Pontozás: -.

1. 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.
2. A git reset használandó akkor, ha a visszavonást, mint változtatást meg akarjuk osztani másokkal.
3. Amennyiben távoli (remote) branch-en is meg akarjuk osztani a visszavonást, mindegy, hogy git reset-et, vagy git revert-et használunk.
4. Az összes fenti állítás HAMIS

Mi a tesztvezérelt fejlesztés (test-driven development, TDD) lépéseinek helyes sorrendje?

Típus: egy. Válasz: 2. Pontozás: -.

1. 1) Kód írása; 2) Teszt írása; 3) Refactor
2. 1) Teszt írása; 2) Kód írása; 3) Refactor
3. 1) Kód írása; 2) Refactor; 3) Teszt írása
4. 1) Teszt írása; 2) Refactor; 3) Kód írása

Mi a commit?

Típus: egy. Válasz: 3. Pontozás: -.

1. A verziótörténet
2. Több branch (ág) változtatásainak "összefésülése"
3. Összetartozó változtatások metaadattal
4. Egy codeline

Mely állítások igazak a kiadás mintákra?

Típus: több. Válasz: 1, 4. Pontozás: -.

1. A Release Branch minta esetén a kiadandó verzió branch-e új funkciókat nem fogad, csak hibajavításokat
2. A Release-Ready Mainline minta esetén a kiadandó verzió branch-e új funkciókat nem fogad, csak hibajavításokat
3. A Release-Ready Mainline minta esetén a kiadandó szoftververzió egy külön, release branch-en található
4. A Release Branch minta esetén a kiadandó szoftververzió egy külön, release branch-en található

Mi igaz a refaktorálásra?

Típus: több. Válasz: 1, 2, 3, 4. Pontozás: -.

1. A meglévő kód átstrukturálására szolgáló technika
2. Tipikus felhasználása a kód olvashatóságának javítása
3. A belső struktúrát a kívülről látható viselkedés megváltoztatása nélkül alakítja át
4. Tipikus felhasználása a teljesítmény javítása

Mi jellemző a központosított verziókezelő rendszerekre?

Típus: több. Válasz: 1, 3, 4. Pontozás: -.

1. A teljes történet csak a központi szerveren található meg!
2. A GitHub egy példa rá
3. Az ütközések elkerülése érdekében zárolást lehet alkalmazni
4. 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?

Típus: egy. Válasz: 2. Pontozás: -.

1. Feltölti a lokális változásokat (commit-okat) a távoli repository-ba (tároló, tárhely)
2. Hatása megegyezik a git fetch és git merge egymás utáni kiadásával.
3. Módosítja a távoli repository (tároló, tárhely) állapotát
4. A fenti ÖSSZES állítás igaz

Mely állítások igazak a távoli branch-ekre (remote branch, távoli ág)?

Típus: több. Válasz: 1, 3. Pontozás: -.

1. Kiválasztás (checkout) esetén lecsatolják a HEAD-et
2. A távoli branch-ek a lokális repository (tárhely) állapotát tükrözik
3. Elnevezési konvenciójuk: <remote neve>/<branch neve> (pl.: origin/main)

Mely állítások igazak a kiadásokra (release)?

Típus: több. Válasz: 2, 3. Pontozás: -.

1. Kizárólag belső használatra, tesztelésre szolgál, az ügyfélnek nem adható oda
2. Egyedi verzióval vannak ellátva
3. A kiadásban nem csak a forrásfájlok vannak benne, hanem a kapcsolódó dokumentáció is
4. A megadott programozási nyelvnek támogatnia kell a kiadás készítését.

Mit jelent a hullám (~) operátor Git esetén?

Típus: egy. Válasz: 4. Pontozás: -.

1. Segítségével az adott branch első commit-ját lehet kiválasztani.
2. Két branch neve közé írva automatikusan összefésüli azokat
3. A main branch neve mögé írva a Git azt main-ként oldja fel ha létezik a main branch, master-ként ha nem a régi repository-k támogatása érdekében
4. A segítségével egy megadott számú commit-tal lehet feljebb lépni a commit fában

Mi jellemző az integrációs mintákra?

Típus: több. Válasz: 2, 3, 4. Pontozás: -.

1. A Mainline Integration minta gyakori, a Feature Branch minta ritka integrációt ír elő
2. A Feature Branch minta esetén egy hibajavítással kapcsolatos minden munkát egy külön, saját ágon végezzük, és csak akkor integráljuk vissza, amikor kész az új funkció
3. A Feature Branch minta esetén egy új funkcióval kapcsolatos minden munkát egy külön, saját ágon végezzük, és csak akkor integráljuk vissza, amikor kész az új funkció
4. A Mainline Integration mintában, a fejlesztők a mainline-on 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