Új hozzászólás Aktív témák

• Lortech addikt

  #8942

  #8938 floatr

  2016-12-12 13:38:32

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Lortech

  addikt

  #8938 floatr

  #8938 floatr

  Első körben tisztázzuk, hogy céges környezetben, céges fejlesztési policy-val nézem ezt az egészet. Nálam a GIT rögtön ott bukik meg, hogy localhost-on van (lehet) olyan munkád a céges projekten, aminek nincsen nyoma a céges/központi repóban. A branch létrehozása egy mozdulat, ha a céges projekteken bíbelődsz valamit, az nem saját kis mitymuty, tessék létrehozni egy branchet akár kísérleti jelleggel a központi repóban, egy hosting/rendszergazda/devops kollégának meg legyen az a dolga, hogy ennek a feltételeit megteremti.

  Minden branch minőségbiztosítási okok miatt meg kell hogy legyen központilag, lefedve egy task management rendszerrel úgy, hogy bármikor bárki tudja folytatni, review-olni, vagy épp merge-ölni DEV/UAT/PROD környezetbe.

  #8933) WonderCSabo a másolás egy logikai művelet. Ellentétben néhány más rendszerrel, SVN alatt nincsen olyan speciális művelet, hogy branch, mivel nincsen erős kötöttség arra vonatkozóan, hogy a repoban mit hova teszel. Branch-et úgy csinál, hogy egy másik branch (URL) adott állapotáról egy referenciát készít az új URL-en. Meg kell határoznod a saját workflow-dat, hogy milyen elnevezéseket és kötöttségeket használsz. Ez nyilván lehet az eredeti ajánlás szerinti is, bár az csak egy viszonylag egyszerű munkafolyamatra jó.

  (#8937) Aethelstone rebase

  SVN-nel ugyanúgy lehet olyan munkád, aminek nincs nyoma a központi repóban (egyszerűen nem tolod fel, ha nem akarod), a GIT viszont segít abban, hogy ha ezt akarod, kényelmesen meg tudd oldani, akár központi repóhoz fordulás nélkül, de úgy, hogy commitok (vagy stashben a változások) meglegyenek.
  Nálam van, hogy 5+ feature branch között váltogatok napon belül, ha segítek vagy reviewzok kollégáknak. Eközben a saját munkám 1-2..n branchen van, amiket vagy feltoltam a remote-ba vagy nem, nincs jelentőségük, lényeg, hogy az infó megvan, és könnyen tudok váltani köztük. Van egy csomó olyan köztes állapota az elvégzendő munkának, aminek vcs historyban nincs különösebb keresnivalója, mert a végeredmény szempontjából nem hordoz értéket, mégis a köztes állapotnak is meg kell lennie, hogy később vissza tudjak rá váltani, ha folytatom a munkát rajta. Ugyanakkor más számára nem mindig hordoz értéket és így teljesen felesleges a feltöltésével időt vesztenem. A kész feature / javítás / akármi pedig úgy fog visszakerülni a masterbe / egyéb protected branchbe, hogy az csak azokat a commitokat és olyan üzenetekkel tartalmazza, ami a módosítás egésze szempontjából lényeges, és a historyban megőrzendő információ.
  Ez nem azt jelenti, hogy nálunk a kollégák 2 hétig a saját kis játszóterükben szórakozhatnak, és ha elüti őket az autó, akkor annyi a munkának. Már csak a CI miatt is sokkal rövidebb életciklusú (vagy folyamatos integráció) branchek szükségesek. Erről git-nél és SVN-nél is le lehet szoktatni őket, ebből a szempontból én nem látok nagy különbséget. Pl. ha látom, hogy kolléga egyik remote branchre sem commitolt egy hete (van róla stat), akkor azért megkérdem, hogy mi a hasfájása.

Új hozzászólás Aktív témák