Sobes.tech
Intervjuu abi
Vahendid
Intervjuu ettevalmistamine
Vahendid
Tööotsing
Vahendid
Juriidiline
Tagasi küsimuste juurde
Middle

Kuidas teie ettevõttes toimub harude ühendamine (merge) või ajaloo ümberkirjutamine (rebase) versioonikontrollis?

sobes.tech AI

Vastus AI-lt

Meie meeskonnas järgime workflows, mis põhinevad Gitil. Põhjalike muudatuste integreerimiseks kasutame kahte peamist lähenemisviisi: merge ja rebase, valides need vastavalt olukorrale ja haru tüübile.

Merge:

  • Tavaliselt kasutatakse pikaajaliste harude ühendamiseks, näiteks dev maini või funktsiooniharude integreerimiseks dev-i.
  • Loob ühendamise commit'i, mis selgelt näitab, millal toimus muudatuste ühendamine teistest harudest.
  • Säilitab kogu commit'i ajaloo, kaasa arvatud kõik harud.
git checkout dev  // Liigume sihtharule
git merge feature/new-feature  // Funktsiooniharude ühendamine

Rebase:

  • Kasutatakse puhta ja sirge ajaloo säilitamiseks funktsiooniharudes enne nende integreerimist (tavaliselt dev-i).
  • Viib praeguse haru commit'id üle sihtharu (dev) tippu, mis efektiivselt "kirjutab" ajaloo ümber.
  • Lihtsustab ajalugu, vältides merge commit'ide loomist iga väikese funktsiooni või paranduse jaoks.
  • Oluline: Ära kunagi tee rebase'i avalikel harudel, millel töötavad teised arendajad, kuna see võib põhjustada konflikte.
git checkout feature/new-feature  // Liigume funktsiooniharule
git rebase dev  // Viime funktsiooniharude commit'id dev-i tippu
// Kui tekivad konfliktid, lahendame need
git push --force-with-lease  // Kasutame --force-with-lease turvaliseks push'iks pärast rebase'i

Meie standardne workflow:

  1. Uus funktsioon või parandused arendatakse eraldi harul (feature/..., fix/...).
  2. Aeg-ajalt (enne pull request'i või sünkroniseerimiseks dev-iga) rebase'itakse funktsiooniharust aktuaalse dev-i peale. See aitab varakult konflikte lahendada.
  3. Pärast arenduse lõpetamist ja koodikontrolli, funktsiooniharust tehakse merge dev-ga no-ff (non-fast-forward) režiimis, et säilitada ühendamise teave. Või harvem, sulatatakse see ühe commit'i sisse enne merge'i dev-sse väikeste funktsioonide või paranduste jaoks.
  4. Aeg-ajalt tehakse dev-st väljaandeid main-i (tootmis) harusse, alati merge'i teel.

Seega, saavutame tasakaalu commit'ide ajaloo säilitamise (merge) ja puhta arendusharu säilitamise (rebase) vahel.

EelmineEdasi