Keskustelu: Yleinen keskustelu: Versionhallintajärjestelmä

Tietääkö joku jotain hyvää versionhallintajärjestelmää vai pitääkö itse tehdä sekin?

Gittiä tässä käytellyt pari vuotta mutta meinaa välillä nousta verenpaine vaaralliselle tasolle kun ton kanssa säätää, mercurialiakin testasin mutta se ei gitistä ainakaan äkkiseltään katsottuna ihan hirveästi eroa.

Mikä niissä on sinusta vikana? Minulla git toimii ihan hyvin, vaikka onhan siinä oppimista, jos tarvitsee tehdä monimutkaisempia rakennelmia kuin vain tiedostoja jonoon.

Esim branchin mergettäminen menee aina jollain tavalla pieleen.

Ehkä pitää etsiä joku kunnon käyttöliittymä tuohon gittiin eikä niinkään uutta järjestelmää.

Olet oikeassa että git saa toisinaan hermot aika kireälle, mutta kun tuota tuota oppii käyttämään niin mikäs siinä.

Hyppäsin vuodenvaihteessa uuteen projektiin jossa käytössä SVN ja pakko myöntää että onhan tämä todella suoraviivaista verrattuna gitin käyttöön.

Toki svn oli ennestään tuttu jossain määrin, mutta kun gittiä vuosia käyttäneenä siihen taas siirryin niin olihan mukavan "helppoa".

Yleinen konsensus on kuitenkin se, että Git on ainoa järkevä versionhallinta ja että loppuja käytetään vain, koska vanhojen projektien siirtäminen Gitiin olisi liian työlästä.

Jos merge menee "jotenkin pieleen", niin vika on käyttäjässä. Git ei sotke mergejä ikinä. Mikäli viittaat merge conflicteihin, niin niiden ilmeneminen ei ole pieleen menemistä. Konflikti syntyy silloin, kun yrität mergeä kahta branchia, joissa molemmissa on muokattu samoja koodirivejä branchin luomisen jälkeen.

Ei mikään skripti voi tietää itsestään, miksi rivejä on muokattu sillä tavoin ja että kumpi versio pitäisi säilyttää ja kumpi heittää menemään. Joskus voi olla niinkin, ettei kumpikaan koodirivi käy vaan koodia pitää muokata kolmannenkin kerran, jotta mergen jälkeinen koodi olisi kokonaisuudessaan toimiva.

muuskanuikku kirjoitti:

käytetään vain, koska vanhojen projektien siirtäminen Gitiin olisi liian työlästä.

Käsittääkseni SVN->Git -muunnos sinänsä käy lähes sormia napsauttamalla. Todellinen syy siirtymättömyyteen lienee enemmänkin ihan looginen "älä riko jotain joka toimii". Eli jos kaikki tiimin jäsenet on tottuneet käyttämään SVN:ää eikä kukaan kaipaa mitään Gitin ominaisuuksia, niin miksi vaihtaa? Ja vaihdonhan voi aina tehdä myöhemminkin jos tarvetta tulee.

Grez kirjoitti:

Käsittääkseni SVN->Git -muunnos sinänsä käy lähes sormia napsauttamalla.

Tyypillisesti joo, mutta esimerkiksi gcc:n repon muunnos oli useamman vuoden prosessi. Eric Raymond kirjoitti kohtaamistaan hankaluuksista pitkiä tarinoita gcc:n sähköpostilistalle 2017-2020. Pitkäikäisissä projekteissa svn-repo voi olla peräisin vuosikausia sitten muunnetusta cvs-reposta ja historiassa voi olla erilaisia korruptioita.

Olen toteuttanut yhdessä isohkossa projektissa muunnoksen svn:stä gitiin ja siinä ei ollut mitään teknisiä haasteita. Ainoa ongelma oli vastahakoisten tiimiläisten avustaminen. Pääsin selittämään "svn commitin" ja "git commitin" merkityksen vähän turhan monta kertaa ja valitukset olivat tyypillisesti tasoa "mergettäminen menee aina pieleen :(((" ilman tarkempia tietoja. Jos gitin opettelu ei kiinnosta ja toivoo salaa, että riittävällä itkemisellä pääsee takaisin svn:n käyttöön, voisi olla kaikkien verenpaineen kannalta parempi pysyä svn:ssä.

Minusta git on erinomainen työkalu ja on hyvä, että se on muodostunut de facto -standardiksi.

Itse Windows alustalla käyttelen vieläkin vanhaa Code Co-op versionhallinta ohjelmaa. On ollut omaan käyttööni riittävä, toimiva ja on helppokäyttöinen. Nykyään lähdekoodit vapaasti saatavilla, mutta en ole kokeillut kääntyykö suoraan toimivaksi kokonaisuudeksi.

jlaire kirjoitti:

Minusta git on erinomainen työkalu ja on hyvä, että se on muodostunut de facto -standardiksi.

Sinäänsä erikoista että gitistä on tullut tuollainen standardi mitä jokainen käyttää. Muissa asioissa ohjelmistoalla ei sitten olekkaan mitään standardeja esim ohjelmointikieliä on varmaan 5000 erillaista...

No en mä nyt silleen tiedä onko se mitenkään erikoista, mutta toki harvinaista.

Ohjelmointikielet on taas sitten esimerkki sellaisesta joka ei ole niin de-facto-standardoitunut.

Onhan niitä kaikenlaisia juttuja jotka on >90% osuudella

Kännyköiden prosessorit: ARMia
Paperinkorvikedokumentit: PDF:ää
Taulukonlaskenta: Exceliä (jos nyt ei ole yli 90% niin olis varmaan, jos tämäkin olisi ilmainen)

Minulla ei ainkaan branch:in merget mene pieleen uusimmalla TortoiseGIT-ohjelmalla.

a karppinen kirjoitti:

Ehkä pitää etsiä joku kunnon käyttöliittymä tuohon gittiin eikä niinkään uutta järjestelmää.

Näin saat varmasti hermosi entistä kireämmälle.

Olet tilanteessa, jossa et täysin ymmärrä työkalua. Ratkaisuksi ajattelet lisätä kerroksia itsesi ja epäselvyyksien välille - en suosittele. Suosittelen mieluummin ottamaan härkää sarvista ja opettelemaan työkalun käyttö. Tässä on oikein hyvä opas: Git - Book.

vesikuusi kirjoitti:

Suosittelen mieluummin ottamaan härkää sarvista ja opettelemaan työkalun käyttö.

Periaatteessa olen samaa mieltä, mutta konfliktien korjailu komentorivillä on kyllä ankeaa ja jokin käyttöliittymä voi juuri sitä askelta helpottaa. Tietysti silti pitää ymmärtää, miksi konflikti tulee ja miten se pitää korjata.

a karppinen kirjoitti:

Tietääkö joku jotain hyvää versionhallintajärjestelmää vai pitääkö itse tehdä sekin?

Sikäli erityisen hauska kysymys, että kritisoitu Git sai alkunsa suunnilleen samasta kysymyksestä.

Metabolix kirjoitti:

Sikäli erityisen hauska kysymys, että kritisoitu Git sai alkunsa suunnilleen samasta kysymyksestä.

Sinänsähän tietenkin myös monet ennen gitiä olleet, siinä yhteydessä kritisoidut järjestelmät, ovat saaneet alkunsa suunnilleen samasta kysymyksestä.

Onko SVN, eli Subversion sitten hyvä verraten GIT:n, koska siinä ei ole local-branch:iä vaan pelkästään remote-branch ja aina kun switch:aa trunkin ja jonkin branch:in välillä niin se lataa tiedostot ja kansiot internet-yhteyden yli?

GIT toimii mielestäni paljon nopeammin kuin SVN ja niillä koflikteilla on syynsä.

Metabolix kirjoitti:

vesikuusi kirjoitti:

Suosittelen mieluummin ottamaan härkää sarvista ja opettelemaan työkalun käyttö.

Periaatteessa olen samaa mieltä, mutta konfliktien korjailu komentorivillä on kyllä ankeaa ja jokin käyttöliittymä voi juuri sitä askelta helpottaa

Olen samaa mieltä, että jokin käyttöliittymä voi helpottaa juuri konfliktien ratkaisemista joissain tilanteissa. En toisaalta usko tuolla olevan vaikutusta, jos on tottunut korjaamaan nuo komentorivillä ja koodieditorilla kuten itselle on käynyt. Ehkä jos konflikteja tulee ihan törkeä määrä.

Ja jos konfliktejä tulee jatkuvasti paljon, niin ongelmat voivat olla muualla kuin versiohallinnassa.

Lebe80 kirjoitti:

Ja jos konfliktejä tulee jatkuvasti paljon, niin ongelmat voivat olla muualla kuin versiohallinnassa.

Todennäköisesti koodi on paskaa. Konflikti tulee siitä, kun kahdessa eri branchissa on muokattu samoja koodirivejä. Ilmeisesti koodi on niin puhdasta sotkua, että minkä tahansa ominaisuuden lisääminen tai parantelu vaatii aina samojen koodirivien purkkaamista.

muuskanuikku kirjoitti:

(08.04.2023 07:20:02): ”– –” Toden­nä­köi­sesti koodi on paskaa. Konflikti...

Eikös konfliktien tarkoitus ole se, että estetään sitä kun useampi koodari sörkki samaa koodia niin ettei koodit mene sitten keturalleen?

Voisiko joku neljäskin sanoa saman asian vielä neljännen kerran.

Ei ole siitä kyse että tulee konflikteja, vaan ennemminkin siitä että niitä ei tule.
Olisi hyvä että pysytyisi valitsemaan mitkä tiedostot siirretään toiseen branchiin.
Jos teen mergen branchista a branchiin b ja branchissa b on joitain tiedostoja joita branchissa a ei ole, menee git kaikesssa viisaudesssaan poistamaan nämä tiedostot kyselemättä.

Ja onkohan gitissä jokin syy miksi esim committejen viestejä ei voi muuttaa jälkikäteen, en oikeen keksi miten se rikkoisi repon eheyttä..

Miksi gitissä ei voi tehdä tyhjää branchia?

Git reposta pitää olla varmuuskopioituna useita versioita koska jos jonkun muutoksen menee tekemään sen peruminen on mahdotonta, versionhallintajärjestelmää varten tarvii siis toisen versionhallintajärjestelmän.

a karppinen kirjoitti:

Jos teen mergen branchista a branchiin b ja branchissa b on joitain tiedostoja joita branchissa a ei ole, menee git kaikesssa viisaudesssaan poistamaan nämä tiedostot kyselemättä.
[..]
miksi esim committejen viestejä ei voi muuttaa jälkikäteen
[..]
Miksi gitissä ei voi tehdä tyhjää branchia?
[..]
jos jonkun muutoksen menee tekemään sen peruminen on mahdotonta

Aivan loistava esimerkki opitusta avuttomuudesta. Ainakaan kaikki tekemäsi väitteet gitin puutteista eivät pidä paikkaansa. Osaatko selvittää minuutin googlauksella tai ChatGPT:ltä kysymällä, missä olet väärässä? Jos et, kerropa millä hakusanoilla etsit tietoa ja mitä ihmettä päädyit lukemaan.

No ok ehkä viestejä voi muuttaa jälkikäteen jos haluaa kirjoittaa historian uudelleen ja muutoksia voi perua jos asian kanssa haluaa 5 tuntia säätää, pointti oli miksi nämä ovat niin hankalia toimenpiteitä, mutta ilmeisesti teidän mielestä gittiä ei saa kritisoida koska se on niin hyvä järjestelmä kun vaan tuollainen järjestelmä voi olla.

Kritiikki ja asialliset kysymykset ovat tietysti tervetulleita. En tiedä millaista vastausta toivoit tuollaiseen trollaukselta haiskahtavaan höpö höpö -viestiin.

Minusta "git rebase -i" ja "reword" on riittävän helppokäyttöinen ja on hyvä, että monenlaisiin historian muutoksiin on yhtenäinen rajapinta. Jos vanhan commit-viestin muuttamiseen olisi oma komento, pitäisi sen lisäksi kuitenkin opetella "rebase -i".

Onko muissa versionhallintajärjestelmissä yleiskäyttöistä undo-toimintoa? Kiinnostaisi tutkia miten sellainen on toteutettu tehokkaasti.

a karppinen kirjoitti:

Jos teen mergen branchista a branchiin b ja branchissa b on joitain tiedostoja joita branchissa a ei ole, menee git kaikesssa viisaudesssaan poistamaan nämä tiedostot kyselemättä.

Aloita selittämällä ensin, miksi toisessa haarassa on tiedostot ja toisessa ei. Ongelman syy luultavasti löytyy samalla. Jos olet itse poistanut tiedostot yhdestä haarasta, niin sehän on muutos, joka mergellä kuuluukin siirtää myös toiseen haaraan.

Vai minkälainen tilanne sinulla oli mielessä?

a karppinen kirjoitti:

Ja onkohan gitissä jokin syy miksi esim committejen viestejä ei voi muuttaa jälkikäteen,

Gitissä kaikesta lasketaan tarkiste (hash), jonka avulla estetään väärennöksiä ja virheitä, ja tästä seuraa samalla, että vanhaa dataa ei voi muuttaa ilman historian uudelleenkirjoitusta.

Muutenkin versionhallinnan idea on säilyttää versiot ja niiden perustelut, ja minusta on hyvä, että mikään vanha tieto ei katoa historiasta toisen käyttäjän toimesta. Tässä kontekstissa "historian uudelleenkirjoitus" on minusta erittäin kuvaava ja ihan oikea tapa historiassa olevien viestien muuttamiseen jälkikäteen.

Onko sinulla jokin ajatus, miksi pitäisi pystyä muuttamaan tekstejä jälkikäteen jollain muulla tavalla, mitä hyötyä siitä olisi ja miten vältettäisiin edellä mainitut haitat?

a karppinen kirjoitti:

Miksi gitissä ei voi tehdä tyhjää branchia?

Kyllä sinänsä voi, jos välttämättä haluaa, mutta ei siinä ole yleensä paljon järkeä. Mitä tekisit tyhjällä haaralla?

git checkout --orphan tyhjeliini

a karppinen kirjoitti:

Git reposta pitää olla varmuuskopioituna useita versioita koska jos jonkun muutoksen menee tekemään sen peruminen on mahdotonta, versionhallintajärjestelmää varten tarvii siis toisen versionhallintajärjestelmän.

Mitä ihmettä? Uudet commitit (myös merge) eivät muuta historiaa, eli siinä suhteessa aina pääsee takaisin. Jos olet epävarma historiaan vaikuttavasta muutoksesta (kuten rebase), kirjoita vain git branch tilanne-ennen-muutosta, niin saat vanhan tilanteen talteen erilliseen haaraan. Mitään tietoa ei silloin katoa edes rebasessa.

Voisi sanoa, että rebasen tyyppinen historian muokkaus on väistämättä vaarallinen muutos. Jos haluat kehittää "turvallisesti", tee vain uusia muutoksia (commit, tarvittaessa revert), ja rebasen ja historian muokkaamisen sijaan tee uusi haara, johon poimit tekemiäsi muutoksia vaikka cherry-pickillä ja korjailet siinä sivussa.

Versiohallinan idea juuri on se, että voit aina palata mihin tahansa aikaisempaan committiin, eli "undota myöhemmät teot". Voit myös tästä lähteä tekemään uusia haaroja, mikäli siihen on jokin syy.

Merget eivät poista "puuttuvia" tiedostoja vaan ne poistavat poistettuja tiedostoja.

a karppinen kirjoitti:

gittiä ei saa kritisoida koska se on niin hyvä järjestelmä kun vaan tuollainen järjestelmä voi olla.

Tottakai gitiä saa kritisoida, mutta jos kritiikki perustuu väärinymmärrykseen git ominaisuuksista, niin kai sitä kritiikkiäkin voi kritisoida.

Monet asiat gitissä voisi varmasti vallan helposti tehdä toisellakin tavalla, mutta gitin kehittäjät ovat päätyneet tekemään ne yhdellä tavalla. Saattaa olla että joillekin devaajille toinen tapa toimia sopisi paremmin.

Esim. commit viestin muuttaminen olisi varmasti triviaali toteuttaa (vaikkapa aiempaa viestiä myöhemmin muokkaava commit), mutta saatu hyöty ei välttämättä olisi suurempi kuin haitat. Nyt viestejä kirjoittaessa täytyy olla vähän huolellisempi eikä voi tuudittautua siihen että "kirjoitan sitten myöhemmin paremman kommentin" ja todellisuudessa niitä korjauksia ei koskaan tule.

Tällainenkaan ratkaisu ei toki ratkaisisi ongelmaa jos joku laittaa committiin salaista tietoa, jonka haluaisi pois. Tosin aidosti monen käyttäjän repossa lienee muutenkin järkevää olettaa että salaisuus on jo vuotanut. Ja yhden käyttäjän repossa tuollaiset mokat pystyy korjaamaan historiaa muuttamalla.