d2s
commented
8 years ago Tässä vielä ohjeet siihen miten tagit pystyy tekemään komentoriviltä:
Parempi lähestymistapa olisi todennäköisesti develop branchin käyttäminen keskeneräisen version työstämiseen master -branchin sijasta. Sen jälkeen kun tekstin kehitysversio olisi viimeistelty, se voitaisiin mergettää julkaistuun master branchiin. Tuo olisi jo itsessään nykyhetkeä parempi toimintatapa.
Vielä parempi olisi käyttää feature branches -kehitystapaa, jossa uudet muutokset (uudet ominaisuudet/korjaukset tms.) tehdään omaan Git branchiin ja sen jälkeen ne liitetään takaisin develop -branchiin kun muutokset on hyväksytty.
Esimerkkejä perinteisen softakehityksen puolelta:
- Git best practices: Commands to create and merge main and supporting branches (tämä esimerkki tosin voi olla turhan monimutkainen osalle kirjoittajista)
GitHub mahdollistaa myös asioiden tekemisen suoraan selaimessa, joten pääosin samat asiat on mahdollista tehdä myös pelkällä web-selaimella. Understanding the GitHub Flow · GitHub Guides kertoo branchien ja Pull Requestien käytön lyhyesti ja selkeästi.
"Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There's only one rule: anything in the master branch is always deployable."
Githubissa kannattaa käyttää release ominaisuutta ja jatkaa saman tiedoston päivittämistä vanhan päälle, jolloin on mahdollista verrata saman tiedoston eri versioita (nyt ei kai toimi, kun 1.0 ja 1.1. ovat erillisissa tiedostoissa).
Loin nyt v1.0.0 tagin siihen committiin, jossa oli viimeisimpänä muokattu ykkösversion .md tiedostoa.
Takautuvasti vanhempiin kommitteihin release -tageja voi liittää tämän ohjeen mukaisesti.
Eli ehdotan, että 1.1. tekstin muutokset laitetaan vanhan päälle ja luodaan sitten 1.1. release ja vastaavasti jatkossa kohti 1.2. jatketaan päivitysten tekemistä samaan.
Pitää huolehtia, miten julkaisupuoli toimii avoinrajapinta.fi domainissa (laitetaan sinne linkit eri versioihin, joiden sisältö haetaan realease-tagien mukaisesti)