ugrás a tartalomhoz

git - béta/testing élesítés

mind1 valami név · 2020. Aug. 25. (K), 21.51
Ha valaki kóbor lélek használ gitet és erre jár: hogyan illik git alatt az eddigi éles verziót deprecated státuszba tenni és élesíteni az eddig béta/teszt verziót?
Mielőtt félreértené valaki: nem az a kérdés, hogy hogyan kell váltani a branch-ek közt, az megvan.
Van mondjuk egy 0.1 verzióm, ami jelenleg az éles, van 0.2, amit fejlesztek.
Ha jól rémlik, a master felel meg kb az élesnek. De lehet egy branch-nek két neve? (master ÉS v0.1?)

Update: közben találtam valamit a git-scm.com oldalon...
 
1

Tag

Pepita · 2020. Aug. 26. (Sze), 10.26
A verziószámot mi tag-ekkel szoktuk egy - egy branch-hez hozzáadni, és amikor az adott branch-et merge-eled a masterbe, "viszi magával" a verziószámot (tag-et).
A masteren git tag --list paranccsal lehet kilistázni az összes tag-et, ebből ugye a "v" kezdetű legnagyobb az aktuális verzió (persze csak akkor, ha eredetileg jól tag-elted a branch-eket).
2

Nem tudok róla, hogy a git

inf · 2020. Aug. 26. (Sze), 11.10
Nem tudok róla, hogy a git tudna ilyesmit. link Nézd meg a package managert, ahova publikálod. Általában azok tudják. Az npm legalábbis tudja emlékeim szerint.
3

A master az éles, és elvileg

Endyl · 2020. Aug. 26. (Sze), 12.12
A master az éles, és elvileg ott csak olyan commitoknak kellene lenniük, amikben működőképes állapotban van a projekt. Így az új verziót egy tetszőleges másik branchen készíted el. Amikor kész, merge masterba (--no-ff), tageled a merge commitot a megfelelő verzióval (mert ugyebár egy adott verzió a kódnak egy adott állapotát jelöli. ha változik a kód, változik a verzió is) és így tovább. Így branchektől függetlenül elő tudsz venni konkrét korábbi verziókat, ha szükség lenne rá.
4

Bocs, közben olvasgattam (meg

mind1 valami név · 2020. Aug. 26. (Sze), 13.51
Bocs, közben olvasgattam (meg újra elolvastam amit itt írtam... Ismét megállapítást nyert, hogy félálomban nem jó kérdést írni :D), szóval a kérdés mindössze annyi lett volna, hogy hogyan kell a master branch-ből mondjuk oldot, a dev-ből meg mastert csinálni.

De ezt inkább úgy finomítanám, hogy "hivatalosan" illik-e ilyet tenni, mondjuk egy "git branch -m master old" stb. segítségével?
A merge itt nem igazán opció, akkora eltérés van a két ág közt, csak történelmileg úgy alakult, hogy közös repoban vannak.
5

Ha jól van kommunikálva a

Endyl · 2020. Aug. 26. (Sze), 14.25
Ha jól van kommunikálva a csapat felé, akkor nem tűnik túl macerásnak.

Bár gondolom megtaláltad, de itt egész jól le van írva, hogy miket kell csinálni egy átnevezéshez: https://www.hanselman.com/blog/EasilyRenameYourGitDefaultBranchFromMasterToMain.aspx

Én mindenesetre kipróbálnám egy "próba origin" repón, hogy mi történik.
6

Ezeket a találatokat úgy

mind1 valami név · 2020. Aug. 26. (Sze), 14.38
Ezeket a találatokat úgy szórtam ki, hogy rá se kattintottam.
(Bocs, de van az a szint, ami már nálam is kiveri a biztosítékot és ez a "nevezzük át a master/slave-et" már ez a kategória ;) )

Egyébként csapat nincs, csak ha már csinálok valamit, legalább felszínen igyekszem igazodni a trendekhez. Hogy minek, azt bem tudom :)
7

Nekem a motivációval sincs

Endyl · 2020. Aug. 26. (Sze), 15.00
Nekem a motivációval sincs feltétlenül bajom (még ha itt nincs is szó master-slave kettősről).

Ha meg technikailag hasznos infó van benne, akkor messze nem az a kategória, hogy bottal se nyúlnék hozzá, még ha nem is értenék egyet vele.
8

Ja, félreértesz: ha tudom,

mind1 valami név · 2020. Aug. 26. (Sze), 15.11
Ja, félreértesz: ha tudom, hogy érdemi infó van benne, akkor megnézem. Csak egy szimpla google találat ehhez kevés.

Az meg ami e téren megy egy ideje... A magam részéről terrornak tartom. Legyen szó master/slave-ről vagy épp a Julius Meinl logójáról. Csak a South Park azon részét tudom emlegetni, amiben minden karacsonyi dolgot kiszórnak, mert sérthet valakit.
9

A történelem változhat... :)

Pepita · 2020. Aug. 27. (Cs), 16.36
A merge itt nem igazán opció, akkora eltérés van a két ág közt, csak történelmileg úgy alakult, hogy közös repoban vannak.
És megakadályoz bármi is abban, hogy ami jelenleg nincs a masterben, annak a (feltehetően 1) branch-nek a kódját kiemeld egy másik repóba?
Ha akkora az eltérés, hogy a merge sem opció, akkor inkább két külön projektnek hívnám, ami (nekem) külön repót jelent.
Amikor az új repóban jó és műxik, akkor a régiből törölhető a "felesleges" branch.

Esetleg felmerülhet még a fork is, de akkor a meglévő repóból (azt hiszem) nem illik törölni a forrás branch-et.
10

Meg nem akadályoz semmi, csak

mind1 valami név · 2020. Aug. 28. (P), 09.49
Meg nem akadályoz semmi, csak valahogy úgy éreztem, a közös eredet közös repot kíván. Különösen, hogy csak az élesített verzió él belőle, a többi csak jövő vagy történelem. :)

Egyébként... "Semmi sem változik olyan gyorsan, mint a történelem". (nem tudom, kitől származik)
12

jövő vagy történelem

Pepita · 2020. Aug. 31. (H), 08.12
A jövőt a történelemmel szépen keresztbe lehet linkelni mindkét repó readme.md elején. :)

Ez viszont tényleg csak vélemény, ha Te "valahogy úgy érezted", hogy egy repó, akkor csináld úgy, erre elég sokféle elfogadható megoldás van.
11

Még egy

vbence · 2020. Aug. 29. (Szo), 00.45
Egy lehetséges módszer az Apache Sparkban láttam, hogy verziókért felelős branchek vannak, így egy feature viszonylag könynen visszaportolható több verzióra is.

https://github.com/apache/spark/branches