[mk321]

#git #naukaprogramowania

tl;dr: wersje trzymać w tags czy branches?

Mam repozytorium GIT.
Robię commity i chcę zachować poszczególne wersje. Oznaczam je za pomogą tagów (tags):

6 commit
5 commit [tag: v.2.0]
4 commit
3 commit [tag: v.1.0]
2 commit
1 commit

I jak mam teraz zrobić wersję v.1.1? Nie mogę wrzucić commita pomiędzy 3 a 4. Mieszać tam za pomocą rebase?

Może jednak powinienem trzymać wersje w branchach?

[controll]

@mk321: o #!$%@?.. co ty kombinujesz? wiesz jak działa git?

[mk321]

@controll: dopiero się uczę GIT-a. Wytłumaczysz jak to powinienem zrobić?

[G.....n]

@mk321: Why not both?
Wersje major podzielić na branche (2.x), minor jako tagi.

[controll]

@mk321: normalnie, branczuj krytyczne i tyle.

[controll]

@mk321: bawisz sie z tym a to narzędzie ma ułatwiać prace a nie komplikować, zastanów sie jakie ruchy możesz wykonać z brancza a jakie z tagu.

[mk321]

@Ginden: dzięki! Tak zrobię.

@controll: ok, czyli tak jak @Ginden pisze.

Bo już z tych tutoriali wywnioskowałem, że używa się:
- tagi: do oznaczania wersji (jak np. tutaj, minor i major jako tagi - ale to jest niepraktyczne, bo nie można rozwijać starych wersji major).
- branche: każdy dla osobnych funkcjonalności lub dla programisty (żeby potem mergować do głównej wersji). Nie czytałem o trzymaniu wersji w branchach, ale tak

[hydrocyfolumpus]

@mk321: Jak już ogarniesz mniej więcej gita, poczytaj o git-flow. Oczywiście wszystko zależy od specyfiki projektu, ale jak jesteś "agile" ;), to gałęzie masz dwie: "aktualną" (master) i "rozwojową" (devel), chyba, że już super koszerny jesteś i na każdą funkcjonalność masz oddzielnego brancza.
W skrócie:
Aktualną masz po to, aby w każdy momencie móc poprawiać błędy od użytkowników, "rozwojową" do wydawania nowych wersji. Jak już stwierdzisz, że "rozwojowa" osiągnęła wszystkie założone