Szofttech labor2 kvíz

A VIK Wikiből
A lap korábbi változatát látod, amilyen Győry Ádám (vitalap | szerkesztései) 2024. október 2., 01:15-kor történt szerkesztése után volt. (→‎Melyik állítás NEM igaza kézponti függőségkezelésre?)

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


Szoftvertechnológia labor1 beugró
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)