Git
Gitin käyttö ryhmässä (GitHub Flow)

Kehitystiimeissä on melko yleistä, että tiimi välttää (tai jopa estää) puskemisen suoraan päähaaraan. Ajatuksena on, että ennen kuin yksi kehittäjä voi lisätä koodinsa päähaaraan, tiimi tarkistaa koodin ja joko hyväksyy tai kieltää sen yhdistämisen päähaaraan. Tarkoituksena on pitää päähaara puhtaana bugeista.

Projektin käynnistäminen

Yksi tiimin jäsen alustaa projektin ja kaikki jäsenet kloonaavat repon. Ja sitten jokainen luo oman branchin.

Työn eteneminen

Kun alat tehdä sovellukseen uutta "ominaisuutta", luo uusi branch.

  1. Kommitoit usein ja pusket branchin silloin tällöin
  2. Jos saat uuden ominaisuuden toteutettua toimivasti, pusket branchin GitHubiin ja luot Pull Requestin
  3. Ryhmä tarkistaa koodisi
  4. Jos ryhmä hyväksyy koodin, se yhdistetään mainiin. Muuten sinun on korjattava jotain ja luotava sen jälkeen uusi PullRequest
  5. Jos ryhmä teki mergen, sinun tulee siirtyä mainiin ja suorittaa komento git pull origin main saadaksesi uusimman main version.
  6. Jos aiot tehdä toisen ominaisuuden, luot jälleen uuden branchin
  7. jne ....
Voit katsoa aiheeseen liittyvät ohjevideot sivulta
https://www.youtube.com/playlist?list=PLWl0bS7jZq9-a6ST5XMSPgfUeU7tXdunP

Alla olevassa kaavioissa on esitetty työskentelyn vaiheet

Interaktiivinen GitHub Flow -demo

💻 Paikallinen Repository

main
init

🌐 GitHub (Remote)

main
init
📬 Pull Request: feature-branch → main
Odottaa tarkistusta ja hyväksyntää...
Aloita klikkaamalla "Luo branch" luodaksesi uuden feature-haaran.
Pull request

Kun kehittäjät alkavat lisämään uusia ominaisuuksia, he luovat uuden haaran (branch). Sitten he puskevat GitHubiin kyseisen haaran melko usein (esimerkiksi kerran päivässä). Ja kun ominaisuus on valmis, se halutaan yhdistää päähaaraan(main). Mutta sen sijaan, että he yhdistäisivät sen itse, he luovat Pull requestin GitHubissa. Sitten tiimi tarkistaa koodin ja päättää, hyväksyykö se pyynnön vai ei. Jos he hyväksyvät, joku heistä yhdistää haaran päähaaraan. Tämän jälkeen jokaisen jäsenen tulee vetää uusin main-versio paikalliseen repoonsa ja sitten yhdistää main-versio haaraan, jonka kanssa he työskentelevät tällä hetkellä.

Kehittäjä voi myös päättää, että hylkää koko branchin. Tällöin hän ei tee Pull requestia.

Jos haluat tehdä Pull requestin GitHubissa, sinun tulee valita valikosta Pull request, jolloin saat seuraavan näkymän

Kun klikkaat painiketta New pull request, saat seuraavan näkymän

Ja nyt kannattaa tarkistaa, että nuoli osoittaa oikeaan suuntaan

Pull requestin käsittely

Kun joku muu ryhmässäsi kirjautuu sisään GitHubiin, hän näkee Pull requestin. Ja sitten heidän pitäisi tehdä tämä

  1. Avaa Pull request
  2. Klikkaa "Add your review"
  3. Approve or Request changes
  4. Jos hän ei hyväksy koodia, hänen tulee kirjoittaa kommentti.
  5. Jos hän hyväksyy pyynnön, hän klikkaa "Merge pull request".
  6. Ja sitten hän klikkaa "Confirm merge""
Nyt hänen tulee ilmoittaa kaikille tiimin jäsenille, että heidän tulee vetää uusin päähaara.

Mergen jälkeen

Oletetaan, että työskentelet beaver-nimisen haaran kanssa ja kuulet, että main on päivitetty. Silloin sinun pitäisi tehdä näin:

  1. git add .
  2. git commit -m "commit in beaver"
  3. git pull origin main
Tärkeää: Komento git pull origin main vetää uusimman main-version ja yhdistää sen siihen haaraan jossa olet (tässä tapauksessa beaver-haaraan). Varmista siis että olet beaver-haarassa ennen komentoa! Voit tarkistaa komennolla git branch (aktiivinen haara näkyy tähdellä *).

Sitten voit jatkaa työtäsi beaver branchissä. Mutta jos tässä vaiheessa syntyy konflikti, se on ratkaistava.

Vaihtoehtoinen tapa (eksplisiittisempi):

  1. git add .
  2. git commit -m "commit in beaver"
  3. git fetch origin main
  4. git merge origin/main
Tässä git fetch hakee uusimman main-version ilman yhdistämistä, ja git merge origin/main yhdistää sen beaver-haaraasi.

⚠️ Tärkeä huomio molemmista tavoista: Nämä eivät päivitä paikallista main-haaraasi! Ne vetävät remote main:n suoraan beaver-haaraan. Jos luot myöhemmin uuden haaran, tee se joko:

  • Beaver-haarasta (jossa on jo uusin main): git checkout -b new-feature
  • Tai päivitä ensin paikallinen main: git checkout main → git pull origin main → git checkout -b new-feature
  • Tai luo haara suoraan remotesta: git checkout -b new-feature origin/main
💡 Muista: Kun luot uuden haaran komennolla git checkout -b something, tuo uusi haara on identtinen sen haaran kanssa josta komento annettiin. Siksi on tärkeää tietää mistä haarasta luot uuden haaran!

Jos haluat päivittää myös paikallisen main:n (pidempi tapa):

  1. git add .
  2. git commit -m "commit in beaver"
  3. git checkout main
  4. git pull origin main
  5. git checkout beaver
  6. git merge main
Tämä tapa päivittää paikallisen main-haaran, joten voit turvallisesti luoda uusia haaroja siitä.

🎯 Interaktiivinen demo: git pull ja git fetch

Kokeile eri komentoja ja näe miten ne vaikuttavat paikallisiin haaroihin!

📍 Olet haarassa: beaver
🌐 Remote (GitHub)
main
📄 app.js v3 (uusin)
function init() {
loadConfig();
startApp();
}
💻 Local
main
📄 app.js v1 (vanha)
function init() {
console.log('start');
}
💻 Local
beaver
📄 app.js v2 (beaver)
function init() {
console.log('start');
loadUser();
}

Olet beaver-haarassa


Klikkaa jotain nappia nähdäksesi mitä tapahtuu!
Conflict

Mikä on konflikti?
Konflikti syntyy, kun kaksi haaraa ovat erkaantuneet (diverged) - eli molemmissa on tehty omia committeja - ja samaa tiedostoa on muokattu molemmissa haaroissa. Kun Git yrittää yhdistää (merge) näitä haaroja, se ei pysty automaattisesti päättämään, kumpi muutos pitäisi säilyttää, jos samat koodirivit on muutettu eri tavalla. Tällöin Git keskeyttää yhdistämisen ja pyytää kehittäjää ratkaisemaan konfliktin manuaalisesti eli valitsemaan, mikä versio koodista on oikea tai yhdistämään molemmat muutokset.

Miksi konflikti syntyy?
Kun työskentelet omassa branchissäsi ja teet committeja, commit history kasvaa. Samaan aikaan joku muu saattaa tehdä committeja main-haaraan. Nyt molemmissa haaroissa on eri commit history. Jos molemmat haarat ovat muokanneet samaa tiedostoa samoilla riveillä, Git ei tiedä kumpi versio on oikea, ja konflikti syntyy.

📊 Käytännön esimerkit konfliktin syntymisestä

Skenaario: Olet työskennellyt beaver-haarassa. Main on päivitetty remotessa (C4, C5). Pullaat remoten mainin ja yrität mergettää sen beaveriin → molempien haarojen commitit ovat muokanneet saman tiedoston samaa riviä → KONFLIKTI

🌐 Remote (GitHub)
main-haara
C1: Initial
C4: Update DB
📝 Muokkaa: app.js
C5: Add API
📝 Muokkaa: app.js
💻 Local
main-haara
C1: Initial
C4: Update DB
📝 Muokkaa: app.js
C5: Add API
📝 Muokkaa: app.js
🌿 Local
beaver-haara
C1: Initial
C2: Add login
📝 Muokkaa: app.js
C3: Fix bug
📝 Muokkaa: app.js

Git konflikti voi syntyä kahdessa tilanteessa:

  1. PAIKALLISESTI: main-haara on päivitetty GitHubissa. Sinä olet tehnyt committeja omassa haarassasi samaan aikaan kun joku muu on tehnyt committeja mainiin. Miksi konflikti syntyy? Kun teet git pull origin main ja sitten git merge main (beaver-haarassa), konflikti syntyy vain jos samat rivit samassa tiedostossa on muokattu molemmissa haaroissa. Git ei pysty automaattisesti päättämään kumpi versio pitää säilyttää.
  2. GITHUBISSA: main-haara on päivitetty jonkun toisen pull requestin yhdistämisen jälkeen. Haara perustuu vanhaan main-versioon ja sen jälkeen mainiin on yhdistetty toisen kehittäjän muutokset. Miksi konflikti syntyy? Kun yrität yhdistää haarasi mainiin (pull requestin kautta), konflikti syntyy vain jos samat rivit samassa tiedostossa on muokattu molemmissa haaroissa. GitHub ei pysty automaattisesti mergettämään PR:ää.
Konfliktin ratkaiseminen

Kun beaver-haaran ja main-haaran commit historiat poikkeavat toisistaan ja tiedoston test.php sisältö on alla kuvatun kaltainen ja koetetaan mergetä haarat yhteen syntyy konflikti.

🌿 beaver-haara

Sinä työskentelet beaver-haarassa ja muokkaat test.php-tiedostoa:

1: <?php
2:
3: echo 'Tervetuloa Jim';
4: ?>

🏠 main-haara

Samaan aikaan joku toinen on päivittänyt main-haaran:

1: <?php
2:
3: echo 'Tervetuloa Ann';
4: ?>

⚠️ Kun yrität yhdistää (merge) main-haaran beaver-haaraan, syntyy konflikti!

Konfliktin tunnistaminen

Kun suoritat komennon git merge main, saat virheilmoituksen: 

Auto-merging test.php
CONFLICT (content): Merge conflict in test.php
Automatic merge failed; fix conflicts and then commit the result.

Konfliktimerkkien selitys

Kun avaat tiedoston test.php, näet konfliktimerkit (conflict markers), jotka Git on lisännyt:

  • <<<<<<< HEAD - Aloittaa SINUN muutoksesi (nykyisen haaran sisältö)
  • ======= - Erottaa kaksi eri versiota toisistaan
  • >>>>>>> main - Päättää TULEVAN haaran sisällön (main-haaran sisältö)
<<<<<<< HEAD
echo 'Tervetuloa Jim';
=======
echo 'Tervetuloa Ann';
>>>>>>> main

Interaktiivinen Konfliktin Ratkaisu

Klikkaa "Yhdistä main beaver-haaraan" nähdäksesi konfliktin
<?php
echo 'Tervetuloa Jim';
?>

Konfliktin ratkaiseminen - vaiheet:

  1. Avaa konfliktitiedosto (esim. test.php) tekstieditorissa
  2. Etsi konfliktimerkit (<<<<<<<, =======, >>>>>>>)
  3. Päätä mitä koodia säilytät:
    • Säilytä HEAD-versio (oma muutoksesi)
    • Säilytä incoming-versio (main-haaran muutos)
    • Yhdistä molemmat (kuten esimerkissä: "Ann ja Jim")
    • Kirjoita kokonaan uusi ratkaisu
  4. Poista KAIKKI konfliktimerkit tiedostosta
  5. Tallenna tiedosto
  6. Tarkista että kaikki konfliktit on ratkaistu: 
    git status
    Jos näet "Unmerged paths", sinulla on vielä ratkaisemattomia konflikteja!
  7. Lisää ratkaistu tiedosto: 
    git add .
  8. Committoi ratkaisu: 
    git commit -m "conflict fixed"
⚠️ Tärkeää:
  • Varmista että kaikki konfliktimerkit (<<<, ===, >>>) on poistettu
  • Testaa että koodi toimii konfliktin ratkaisun jälkeen
  • Käytä git status -komentoa tarkistaaksesi jäljellä olevat konfliktit
  • Jos konflikteja on useissa tiedostoissa, ne kaikki pitää ratkaista ennen committia

Ja sitten voit jatkaa työskentelyä branchissä beaver.



Toggle Menu

Pekka Alaluukas 2025