Kirjoittaja Aihe: Git -kysymys (tai pari) [RATKAISTU]  (Luettu 227 kertaa)

Jere Sumell

  • Käyttäjä
  • Viestejä: 282
  • Tietojenkäsittelyn tradenomi vuosimallia 2017.
    • Profiili
    • Tietokone-blogi
Git -kysymys (tai pari) [RATKAISTU]
« : 16.07.21 - klo:15.10 »
Nyt korona - aikana ohjelmistokehitys -etäprojektia pukkaa, jossa lähdekooditiedostot on github-repossa.

Kävin aamulla hakukoneen välityksellä pikapreppauksen Linux terminal git guide -hakusanoilla ja sitten etsisin eroa fork ja clone -avainsanoille.  Onko käytännössä niin, jos otan osaa etänä ohjelmistoprojektiin, jossa on useita devaajia mukana, kannattaa tuon haarukoinnin, forkkauksen sijaan kloonata projekti omalle koneelle työhakemistoon?

Entä riittääkö pelkkä push sitten kun lähetän tiedostoja git-palvelimelle, josta sitten projektin ylläpitäjä varmaankin tarkistaa koodin, vai pitääkö se vielä minun commitoida?

Itselläni on tähän asti vain vähän kokemusta omien projektien luomisesta nollasta, eikä AMK:n www-ohjelmointi -kurssillakaan käsitelty tuota remote working on project, vaan sielläkin luotiin oma ylläpidettävä lähde hajautettuun versionhallinta-järjestelmään.
« Viimeksi muokattu: 16.07.21 - klo:17.32 kirjoittanut Jere Sumell »
Free Internet and  people for humans all over the globe!

(Profiilikuvassa oma valokuvani GIMPissä editoituna Disney Classic-väripaletin väreihin ja muunnettuna bittikartta-tiedostosta vektorigrafiikaksi.)

nm

  • Käyttäjä
  • Viestejä: 14382
    • Profiili
Vs: Git -kysymys (tai pari)
« Vastaus #1 : 16.07.21 - klo:16.56 »
Kävin aamulla hakukoneen välityksellä pikapreppauksen Linux terminal git guide -hakusanoilla ja sitten etsisin eroa fork ja clone -avainsanoille.  Onko käytännössä niin, jos otan osaa etänä ohjelmistoprojektiin, jossa on useita devaajia mukana, kannattaa tuon haarukoinnin, forkkauksen sijaan kloonata projekti omalle koneelle työhakemistoon?

Forkkaus ei oikeastaan ole gitin komento tai ominaisuus, vaan tarkoittaa sitä, että teet alkuperäisestä repositoriosta oman kopion, johon voit commitoida muutoksia ilman että vaikutat mitenkään alkuperäiseen repositorioon. Tällöin et siis myöskään tarvitse kirjoitusoikeuksia alkuperäiseen repoon. GitHubissa tämä on erityisen kätevää, koska forkkaus onnistuu suoraan GitHubin käyttöliittymän kautta, ja myöhemmin voit synkata koodia repositorioiden välillä pull requestien avulla.

Jos sinulla kuitenkin on kirjoitusoikeus ja lupa kehittää asioita suoraan alkuperäisessä repositoriossa, forkkauksen sijaan voi olla yksinkertaisempaa kehittää asioita omassa haarassa (branch) ja pyytää sitten katselmointia ja liittämistä master-haaraan pull requestilla.

Jokaisella projektilla on tällaisissa asioissa omat käytäntönsä, jotka sinun on selvitettävä projektin vetäjältä tai muilta kehittäjiltä.


Varsinaista kehitystyötä varten koodi joka tapauksessa kloonataan git clone -komennolla omalle koneelle.

Entä riittääkö pelkkä push sitten kun lähetän tiedostoja git-palvelimelle, josta sitten projektin ylläpitäjä varmaankin tarkistaa koodin, vai pitääkö se vielä minun commitoida?

1. Koodaa, eli korjaa bugi tai toteuta uusi ominaisuus. Luo tarvittaessa uusi haara git branch ja git checkout -komennoilla.

2. Testaa muutokset.

3. Valitse tiedostot committiin: git add muutettutiedosto1.xyz muutettutiedosto2.xyz ...
    Voit myös lisätä tiedostoja yksitellen erillisillä git add -komennoilla. Tässä vaiheessa hyödyllisiä komentoja ovat myös git status, git diff ja git diff --cached

4. Luo commit: git commit
     Tämä avaa editorin, johon kirjoitat projektin käytäntöjen mukaisen muutosviestin. Tarkista myös, että nimesi ja sähköpostiosoitteesi on oikein tässä lokiviestissä ja korjaa ne gitin asetuksissa, jos eivät ole oikein. Commit-viestiä voi vielä editoida tallennuksen jälkeen ennen pushausta tai muita committeja komennolla git commit --amend
    Commit ei vielä lähetä muutoksia varsinaiseen etärepositorioon (origin), vaan ne tallentuvat vain paikalliseen työkopioosi.
    Voit antaa lyhyen commit-viestin myös suoraan komentorivin kautta: git commit -m "Change login button color to green"

5. Riippuen muutosten laajuudesta ja koodin määrästä, voit jakaa muutokset useaan eri committiin pienempinä loogisina kokonaisuuksina. Tällöin siis toistetaan kohdat 1–4 tai 3–4 useita kertoja.

6. Lähetä muutokset etärepositorioon: git push
    git push lähettää kaikki paikalliset commitit origin-repositorioon. Jos sinne on kuitenkin tehty muutoksia ennen omia committejasi, joudut ensin hakemaan muutokset (git pull) ja mahdollisesti mergeämään niitä manuaalisesti, jos automatiikka ei pysty selvittämään mahdollisia konflikteja. Tässä tilanteessa on kuitenkin sinun vastuullasi varmistaa, että omat muutoksesi ovat yhteensopivia muiden committien kanssa.

7. Kun koodaamasi uusi ominaisuus on valmis tai bugi korjattu, pyydä katselmointia ja muutosten liittämistä päähaaraan GitHubin Pull Request -toiminnolla.
« Viimeksi muokattu: 16.07.21 - klo:17.04 kirjoittanut nm »

Jere Sumell

  • Käyttäjä
  • Viestejä: 282
  • Tietojenkäsittelyn tradenomi vuosimallia 2017.
    • Profiili
    • Tietokone-blogi
Vs: Git -kysymys (tai pari)
« Vastaus #2 : 16.07.21 - klo:17.31 »
Kiitos muuten laajasta ja avartavasta vastauksesta!
Free Internet and  people for humans all over the globe!

(Profiilikuvassa oma valokuvani GIMPissä editoituna Disney Classic-väripaletin väreihin ja muunnettuna bittikartta-tiedostosta vektorigrafiikaksi.)