TIE-20200 Ohjelmistojen suunnittelu

Transcription

TIE-20200 Ohjelmistojen
suunnittelu
Luento 3: Git & Gitlab
Samuel Lahtinen
1
TIE-20200 Samuel Lahtinen
Ajankohtaista…
•Harkkatyöhön ilmoittautumisdedis tänään
•Git ja ryhmäkutsut
• Versiohallinnan kutsut lähdössä matkaan huomenna
Ohjelmassa tänään
•Git ja jotain komennoista jne.
•Haarat ja niiden käyttö
•Gitlab
•Erilaisia tapoja käyttää versiohallintaa (haarat
jne.)
Versiohallinnan käytöstä
Versiohallinta vs. Dropbox jne.
• Monet työkalut sisältävät sisäisesti versiohallinan
kaltaista toimintaa (esim Word)
• Esim Dropbox toimii osin versiohallinnan tapaan,
tekee uusia versioita, mahdollisuus palata
vanhaankin
• Samanaikaisen tiedoston muokkailun sallivat
työkalut (Google Docs, Overleaf, jne.)
Paikallinen versiohallinta
•Versiohallintatietokanta samalla koneella,
muokattavana uusin versio tiedostosta,
mahdollisuus palata vanhempiin jne.
tietokone
checkout
versiohallintatietokanta
tiedosto
Versio 3
Versio 2
Versio 1
http://git-scm.com/book/en/v2/Getting-Started-About-Version-Control
Keskitetty versiohallinta
•Kuten SVN, versiohallintapalvelin, josta käyttäjät noutavat koneelleen
(uusimman) version
•Commitin jälkeen palvelimella uusin versio, jos palvelin katoaa, jäljelle jää
käyttäjiltä löytyvät versio, ei versiohistoriaa tms.
palvelin
Tietokone, käyttäjä 2
commit
Versio 3
Tiedostot
Versio 2
checkout
Versio 1
Tietokone, käyttäjä 1
checkout
Tiedostot
Hajautettu versiohallinta
•Distributed Version Control System, esim. Bazaar, Git, Mercurial
•Koko versiohallintatietokannan peilaaminen, ei pelkästään tietyn version
hakeminen, tiedon palautus
•Mahdollisuus käyttää yhdistää eri palvelimia
palvelin
Tietokone A
Versio 3
tiedosto
Versio 2
Versio 3
Versio 1
Versio 2
Versio 1
Tietokone B
tiedosto
Versio 3
Versio 2
Versio 1
http://git-scm.com/book/en/v2/Getting-Started-About-Version-Control
Harkkatyön kanssa: Gitlab ja repot
https://gitlab.rd.tut.fi/repolainen/docs/student_manual/intro.html
Git yleisesti
• Ei tallenna tiedostojen eroja, vaan aina “snapshotin”
tiedostotoista, uudet versiot tai muuttumattomissa linkki
edelliseen
• Lähes kaikki toiminnot ovat lokaaleja, historia jne. löytyy
paikallisesti ilman verkkoyhteyttä
• Yleisin versiohallintaohjelmisto
Git ja peruskomennot
•Add, lisätään tiedosto
•Log, revisiohistoria
•Rm, poistetaan tiedosto
•Commit, muutosten vieminen eteenpäin
•Revert, undo muutoksille
•Checkout, tietyn haaran ottaminen työhaaraksi tai tietyn version hakeminen
historiasta (git checkout revision_id)
•Branch, haaran luominen (työhaarasta)
•branch –d, poistaa haaran
•Merge, yhdistetään nykyiseen haaraan annettu haara
Git ja peruskomennot
•Clone, kopioi olemassa olevan repon, tämän tekeminen kurssilla aivan alkuun
 saatte kopioitua itsellenne ryhmänne repositoryn (osoite Gitlabista)
•Push, työnnetään nykyisen työhaaran (commitoitu) tilanne palvelimelle
(kurssilla gitlab.rd.tut.fi…)
•Fetch, haetaan toisesta repositoriosta tavaraa
•Pull, fetch + merge nykyiselle työhaaralle, clonen jälkeen tekee
automaattisesti clone-osoitteesta
•pull –rebase, hae uusimmat palvelimelta, tee rebase (lokaalisti)
•Remote, yhteistyön määrittelyä ja kyselyä
•origin, paikka mistä kloonattu
•remote –v, lista osoitteista ja lyhenteistä
•remote –a shortname url, lisätään uusi osoite (esim. git –a test a.test.fi)
• git fetch shortname, saadaan haettua kyseinen repo (esim. tietyn
käyttäjän)
Git ja haarat
• Haarat, päähaara master, muut haarat, branches
• Mihin voidaan käyttää?
• Bugikorjaukset
• Uusien ominaisuuksien toteuttaminen, yleinen tapa, uusi ominaisuus,
uusi feature branch.
• Kun homma on toteutettu loppuun ja testattu, merge masterin
kanssa (tai jonkun versiohaaran kanssa)
• Tietty versio ulos, tämän jälkeen tarvittavat päivitykset tämän haaran
alle tai siitä lisähaarauttamalla
Esimerkki versiohallinan käytöstä teollisuudessa
(feature-haara, jossa refaktorointeja)
2015-03-16
2015-03-17
2015-03-18
2015-03-19
“Created branch
'feature/LPK174_cookie-sessionstore‘”
“Use encrypted
cookie as the
cookie store”
“Refactored
hashbang to
use pure ring
session”
“Move session
key from JSON
to response
level”
“Handle nil
response
correctly”
“Refactored
hashbang to use
pure ring
session”
“Merge with
develop”
“Load current
user data from
db”
“Read session id
from session
data”
“Pass session to
actions”
“Renamed
logging context
key”
“Moved user from
noir session to
pure ring
session”
“company info is
needed in
session”
“fixed
impersonation”
“Load current
user attachment
list from db”
“architect flag
is needed in
a pre-check”
“Merge with
develop”
“impersonator is
also a virtual
user”
“Drop person id
from public data”
“No default key”
“Check user data
expiration at
authorization
middleware”
“Merge with
develop”
“Set user data ttl
to 5 minutes”
“exclude virtual
users”
“Separated start
function, added
stop function”
“Read session
encryption key
from file”
“Added endpoint
for restarting
Jetty”
“Set graceful
shutdown timeout
to 10 seconds”
“Allow access
only from
localhost”
“Merge with
develop”
“reload api”
“Reconnect to
MongoDB”
“flow: Closed
<feature> 'LPK174_cookie-sessionstore'”
Refactoring within
feature dev
Feture branch
Creation / closing
Merge with dev.
branch
“Added script for
deploying keys”
“flow: Merged <feature>
'LPK-174_cookie-sessionstore' to <develop>
('develop')”
Legend:
Major
refactoring
“Moved session
handling logic to
sade.session”
Review
request flag
“Session ID must
be generated
manually”
“web/sessionId
was only logged
redundantly”
“special case for
oir-authority user”
Esimerkki haarasta
• Alkutilanne:
• Issue tracker, issue 53 työn alle 
$ git checkout -b iss53
Switched to a new branch "iss53"
Tai kahden komennon kera:
$ git branch iss53
$ git checkout iss53
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
Jatkokehitystä
• Alkutilanne:
• Issue tracker, issue 53 työn alle 
git commit -a -m 'lisättiin puolustuskyky
uudelle hahmotyypille'
Kriittinen bugikorjauspyyntö
• Alkutilanne:
• Palataan takaisin master-haaran tilanteeseen, luodaan sen pohjalta uusi
haara hotfix, muokkaillaan ja commit
$ git checkout master
Switched to branch 'master'
$ git checkout -b hotfix
Switched to a new branch 'hotfix'
$ git commit -a -m 'fixed the broken email
address'
[hotfix 1fb7853] fixed the broken email address
1 file changed, 2 insertions(+)
Bugikorjaus mukaan
masteriin
• Alkutilanne:
• Hotfix toimii testien perusteella, hyvä homma, korjaus masteriin
$ git merge hotfix
Hotfix-haara tehnyt tehtävänsä, voidaan poistaa
$ git branch -d hotfix
Palataan kehittämään issue
53:a
$ git checkout iss53
Switched to branch "iss53"
$ vim index.html $ git commit -a -m 'uusi taistelija valmis [issue 53]'
Liitetään työn tulos
päähaaraan
Switched to branch 'master'
$ git merge iss53
Merge made by the 'recursive' strategy.
Konflikteja?
$ git merge iss53
Auto-merging kokopelisamassatiedostossa.cc
CONFLICT (content): Merge conflict in kokopelisamassatiedostossa.cc
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified:
kokopelisamassatiedostossa.cc
no changes added to commit (use "git add" and/or "git commit -a")
$ git mergetool
Rebase ja haarat
Mergen avulla
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
$ git merge experiment
https://git-scm.com/book/en/v2/Git-Branching-Rebasing
Rebase ja update
“haluan, että omat muutokseni pistetään muiden tekemien muutosten päälle”
git pull --rebase origin master
Origin/master
Local master
Local master
(after rebase)
https://git-scm.com/book/en/v2/Git-Branching-Rebasing
https://www.atlassian.com/git/tutorials/comparing-workflows/centralized-workflow
Gitlab?
•
•
•
•
•
Git version control, versiohallinta
Issue tracker, tikettien hallintaa
Code snippets, jako versiohallinnan ulkopuolelle
Yksinkertainen wiki
Merge Requests, pyyntöjä, joilla voidaan pyytää henkilöä tekemään kahden
haarojen yhditäminen (esim. Feature-haara päädevaushaaraan)
Pull & merge requests
• Pull request, yleinen tapa kommunikoida ja varmentaa ohjelman uusia osia,
ominaisuuksia jne.
• Koodari saa homman valmiiksi, pull/merge request,
työkaverit/intergraatiovastaava käy kurkaamassa koodin
• Tämän jälkeen masteriin merge
• Pull request, onko kunnossa
• Oon jämähtänyt, voiko joku jeesata
• Fork ja siellä puuhastelu
• Ei tarvi välttämättä Gitlabin työkalua, kevytversiona esim. Slack tai IRC ja
siellä huutelu
• https://help.github.com/articles/using-pull-requests/
Työkaluja
•Perussetti: https://git-scm.com/downloads
•Git asiakasohjelmia, http://git-scm.com/downloads/guis
•Graafista tiedostojen hallintaan integroitua Windowsille:
https://code.google.com/p/tortoisegit/
•Linux, Windows, Mac ja graafinen: http://www.syntevo.com/smartgit/download
•Komentorivi (Linux, Lintulan git), Windowsille vastaava: https://git-forwindows.github.io/
•SSH-avaimet ja niiden tuottaminen: https://gitlab.rd.tut.fi/help/ssh/README
Erilaisia työskentelytapoja
•Kaikki masteriin
•Sopimukset, remoteen puskettava kama ei saa rikkoa mitään
•Vain testattua, toimivaa koodia
•Esim. Uudet commit masteriin, liittyy joko ominaisuuteen (feature) tai
bugipäivitykseen
•Commitit ja tyypittäminen, bugikorjaus, feature, refaktorointi, jne.
•Pieniä inkrementtejä, työ ei voi olla auki pitkään (yhteistyö haastavaa)
•Masterin koodi usein rikki
•Feature branch workflow, ominaisuuspohjainen
•Kaikki tiettyyn ominaisuuteen liittyvä työ samassa haarassa, yhteistyö,
samaan ominaisuuteen liittyvän työn jakaminen
•Master aina ehjänä
•Pull requestien käyttö kommunikaatiossa, oon saanut valmiiksi,
tarkastakaa, oon jämähtänyt, jne. (pull request, review, merge to main)
Feature branch workflow
•Uusien ominaisuuksien/asioiden kehittämiseen liittyvä
•Kaikki tiettyyn ominaisuuteen liittyvä työ samassa
haarassa, yhteistyö, samaan ominaisuuteen liittyvän työn
jakaminen
•Master aina ehjänä
•Pull/merge requestien käyttö kommunikaatiossa, oon
saanut valmiiksi, tarkastakaa, oon jämähtänyt, jne. (pull
request, review, merge to main)
Gitflow
• Projektien julkaisut tärkeässä roolissa, isompiin projekteihin toimiva
• Featuret liittyvät devaushaaraan, masterissa vain julkaisuversiot
• Erilliset release-haarat (dedis tai tarpeeksi ominaisuuksia),
valmistuessaan masteriin uutena version & dev-haaraan merge
mahdollista tehdä samaan aikaan jatkokehitystä ja julkaisun valmistelua
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
GitLab Flow / Github flow
• Yksinkertaistusta GitFlowsta
• Masteriin menevät featuret valmiita tuotantoon, eli feature branch
merge  suoraan käyttöön
• Continuous deliveryt sun muut käytössä
• Oikealla, useita eri ympäristöjä, pre-productionin kautta productioniin
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
Forking workflow
• Yhden serveripuolen repon sijaan jokaisella oma serveripuolen repo
• Erillinen projektin hallinnoija hyväksyy ja tekee yhdistämiset viralliseen
repositoryyn, joka sitten on muiden saatavilla (kloonattavissa ja
synkronoitavissa)
• Erityisen toimiva nopeasti muuttuvien ryhmien kanssa, open source
projektit ja enemmän tai vähemmän luotettavat devaajat
• Kaikki voivat työntää tuotoksiaan muiden saataville, pull request,
tarkistaminen, hallinnoija vastaa hyväksynnästä
https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
Dictator and Lieutenants workflow
• Iiisoihin projekteihin, joissa hierarkiaa & paljon tekijöitä
• Yksi virallinen repo, josta uusin virallinen versio (blessed)
• Devaajat tekevät töitä tietyn alueen parissa, näillä oma luutnantti joka
vastaa tästä vastuualueesta, tekevät omaan masteriinsa yhditelyn,
integraatiomanagerina näille luutnanteille diktaattori, joka vastaa
blessed reposta, tekee merget siihen suuntaan
• Blessed referenssinä kehittäjille, (kehittäjät rebase blessedistä aina kun
päivittyy)
• Kevyempi yleinen versio, integration manager workflow
https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows
Suosituksia
•Sopikaa yhtenäinen tapa käyttää gittiä, jonkinlainen workflow, jotain
periaatteita jne.
•Rebase ennen pushia
•Pull requests ja niiden hyödyntäminen, kommunikointi ja varmistus
Aloittaminen
•Gitlabiin sisään, siellä repositoryn URL selville
•SSH-avaimen luominen ohjeiden avulla
•Sen jälkeen komentorivillä kloonaus
•Kokeile kaikenlaista paikallisesti, (add, commit, branch, merge…)
•Kokeile tunkea oma testihaara muiden saataville jne.
Asetuksia
• Editorin vaihtaminen toiseksi (Windows, jos on
vim-allergia), esimerkkinä Notepad++
• Notepad++ avautumaan gitbashissä, lisätään
asennushakemisto pathiin
• Git ja editorin asettaminen (vaihda notepad++:n
tilalle oma suosikkisi)
git config --global core.editor \ "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin”
• Linux jne. Asenna mieliohjelma ja käytä, git
configilla editorin vaihtaminen onnistuu
Yhteenveto
•Opittiin gitin peruskomentoja ja ideaa haarojen käytöstä jne.
•Opittiin hieman erilaisista versiohallinnan käyttötavoista (workflowt)
•Myöhemin kurssilla vähän lisää asiaa koodistaajoon tyyppisestä asiasta
•Osoiteita:
•https://gitlab.rd.tut.fi/
•https://gitlab.rd.tut.fi/repolainen/
•Materiaalia & ohjeistusta:
•http://git-scm.com/book/en/v2
•https://gitlab.rd.tut.fi/repolainen/docs/student_manual
•https://www.atlassian.com/git/tutorials
36

TIE-20200 Ohjelmistojen suunnittelu

Transcription

Similar documents

Tee se itse Näin teet laitteen, jolla voit mitata veresi

Palvelukuvaus

iy Hi. 1 - City Of Beverly Hills

Liite 3 Checkout – rajapintakuvaus sivu 1/9 Checkout

salainen kitarakokoelma - Guitars

Quick help in Finnish (UPDATED) - Linkki

– pieni, SUURI sankari! OHJAAJAN OPAS

vaaliluettelo18092015

SÄHKÖINEN KAUPANKÄYNTI