Szoftvertechnolgia s Grafikus Felhasznli Fellet Tervezse GIT actually

Szoftvertechnológia és Grafikus Felhasználói Felület Tervezése GIT (actually) http: //users. nik. uni-obuda. hu/prog 4/ 1

GIT – eddigi ismereteink • • Local Repository, Remote repository (origin) Master branch, Commit, Push, Pull Prog 3: single-user, single-branch, prog_tools. pdf Prog 4: multi-user, multi-branch (create repo clone repo kódágak használata NEM réteg/modul/fejlesztő szerint, hanem funkcionalitás szerint) http: //nvie. com/posts/a-successful-git-branching-model/ 2

Git commandline • MINDEN git gui = Process. Start() + a kimenetet szép megjelenítése – Néhány kliens (pl. Source. Tree) képes embedded git-et használni – Ez az alapvető logikán nem változtat: a GUI csak egy frontend! – A parancssori műveleteknek csak egy része érhető el • Sokszor kénytelenek lehetünk minden kliensben parancssort használni – Tipikusan Reset/Rebase/Stash/Cherry-pick műveletek lehetnek bonyolultak, főleg Google search után – Sourcetree: Actions/Open in terminal, kicsit bugos (Hozzáadott repository nélkül nem működik; néha amúgy sem… Tools/Options/git, Use embedded git + DONT use git bash as default terminal) – VS: Team Explorer / Actions / Open Command Prompt VAGY Git menü / Open Repository in / Command Prompt 3

Fork, Merge • Fork/Branch: leágazás – A kód aktuális állapota alapján új ág (branch) létrehozása – Minden commit csak egy branch-et módosít – Akár teljesen más repository-ba is lehet forkolni • Merge: egyesítés – Több ág egyesítése – FF vs NO-FF • Pull request: merge kérése (akár forkolt repository-ból is) 4

Merge? ? ? • “Incorporates changes from the named commits (since the time their histories diverged from the current branch) into the current branch“ • Mindegy, hogy a “topic” az ténylegesen egy másik branch (ld. később) VAGY az aktuális branch egy letöltött, nem-egyesített állapota a remote repository-ból • Conflict esetén azonos lépéseket kell tenni MINDKÉT esetben – A problémát helyileg kell megoldani – A „conflict resolution” új commitként elmenthető – Ez az új commit ezután PUSH-olható a remote repository-ba 5

Conflicts • Egymásnak ellentmondó commitok – Alap probléma: több commit azonos file-t módosít (sokszor az nem feltétlenül conflict, ha egyértelműen beazonosíthatóan elkülönülő részt érint a módosítás a file-on belül) – Nem csak többfelhasználós/több branch esetén fordul elő, egy user/branch is elég, több módosítási forrással (pl. több számítógép, vagy weboldalról és git-ről történő módosítás esetén) – Teljesen mindegy, hogy több helyi branch esetén történik a conflict, vagy a local/remote branch ütközik – Local repository-ban feloldandó, módosítások+commit+push segítségével (remote merge NINCS) 6

Conflicts • Tipikusan nem minden local commit után push -olunk (“X ahead”) • Push előtt inkább Pull, hogy tudjunk a conflictról • Ha nincs pull, akkor a push száll el hibával 7

Conflicts • FETCH = remote letöltése; egyesítés (merge) nélkül • PULL = remote letöltése és merge conflict lehetséges („merge rejected” hibaüzenet) helyi konfliktus-kezelés 8

Mergetool • A conflict-olt file kiválasztása Jobb katt Resolve Conflicts – Take „mine” (aktuális branch, local commit) – Take „theirs” (másik branch, remote commit) – (ezek a módosítások kézzel visszaszerkesztésével javíthatóak) – Launch external mergetool (többnyire félautomata folyamat) 9

Mergetool • „Source. Tree does not have a built-in merge tool” – Diff = 2 verzió közötti különbségek hatékony kiszámítása – Three-way-diff / Three-way-merge: base, mine (local), theirs (remote) – Five-way-merge: base 1, base 2, commit 1, commit 2, final „Cherry picking”, Jelenleg csak manuálisan lehetséges – Source. Tree: Tools/Options/Diff – Source. Gear Diff. Merge, Meld, P 4 Merge, VS (2015 óta), Intelli. J IDEA (és leszármazottak), kdiff 3 10

KDiff 3 • Az A/B/C gombok segítségével lehet verziót választani • Visual studio: ugyanez az elv, csak conflictonként checkboxokkal, hogy melyik oldalt akarom használni 11

KDiff 3 • A megfelelő összeállítás (esetleg kézzel szerkesztés) után save, quit • A conflict feloldás új commitként felpusholható 12

Resolve conflicts • A Source. Tree érzékeli a változást, mehet a commit & push • . gitignore. orig törölhető 13

Source. Tree-ben: Branch/Fork • Commitra jobb katt / Branch ( local repository branch) – Egyből ezután Branches/develop –ra jobb katt, és Push to / Origin, hogy a remote repository-ban is ott legyen a branch – Minden commit automatikusan az aktív local branch-be megy, és abba a remote branch-be push-olódik föl, ami ehhez a local branch-hez hozzá van rendelve (tracked branch) • A Branches listában dupla kattintással állítható, hogy melyik branch az aktív / helyi working copy (checkout, félkövérrel jelzett) – Ekkor az összes helyi file átíródik a kiválasztott branch-beli változatra – Független szövegszerkesztő egyszerű külső változtatásként 14

Merge • A CÉL branch-et kell checkout-olni – „Merge” gomb, majd a befésülendő commitot jelöljük ki, --no-ff – A merge-commit ezután pusholandó (conflict-kezelés után) – Az eredeti branch céges policy-től függően esetleg törölhető (a develop NEM, a feature talán) 15

VS + GIT • 2015 előtt kb. alkalmatlan normális GIT használatra • VS 2019 16. 8: Git Experience (Default) • A Source. Tree használata nem kötelező, a VS integrált GIT-je is használható, ld. prog_tools. pdf linkjei a GIT szekció alján • „Stage hunk” ? ? ? https: //developercommunity. visualstu dio. com/content/idea/443834/gitstage-selected-portion-of-file. html Dec 11, 2020 >> concepts!!! 16

Minimum elvárás: Master/Develop • Legegyszerűbb megközelítés • A master branch-re ne menjen kódváltoztató commit, csak a develop-ra • A masterre minden milestone -nál merge (--no-ff) • A Nik. Git. Stats csak a master branch állapotát vizsgálja, ezen NE legyen nem-merge commit • A develop branchen próbáljuk meg tartani a „simple commits” stratégiát 17

NVIE Branching Model / Git. Flow 18

Github Branching Model 19

Git. Flow vs Trunk-based • Git. Flow – Ismeretlen / junior fejlesztőkkel jobb (szabályozottabb review) – Open-Source világban tökéletes – Már bejáratott terméknél előnyösebb – Sok csapatot kell kezelni • Trunk-based – Minden commit a Master-re megy – Egy termék, kevés csapat (Termékenként külön kódfa) – Prototípus készítéshez jobb – Senior fejlesztőkhöz jobban illik – Gyorsabb iterációhoz jobb – Feature branch-ek ugyanúgy lehetségesek – Tipikusan: Facebook, Google https: //paulhammant. com/2014/01/08/googles-vs-facebooks-trunk-based-development/ 20

Linux kernel fejlesztése • Linus Torvalds (- main) = Kernel Dictator , „I'm not a nice person” • Andrew Morton (-mm), Greg KH (-stable, LTS 6 (? ) évre) • NEM Linux dev: – Richard Stallman (GNU, filozófia, 2019 -ben visszavonult) – Alan Cox (2. 2, 2. 4 -ac, 2009 -ig, 2019 -ben visszavonult) • 2. 1/2. 2, 2. 3/2. 4, 2. 5/2. 6, DEC/ 2003 = 2. 6. 0, JUN/2011: 2. 6. 39 • Azóta Major. Minor. Release. Bugfix • 2011: 3. 0, 2015: 4. 0, 2019: 5. 0, verzióugrás oka: „mert csak” • Current mainline: 5. 11 (LTS: 5. 10 (? ), 5. 4, 4. 19, 4. 4) • Rengeteg LOC/patch/platform, rengeteg fejlesztő/cég … • „As of 26 September 2018, using then-current 20, 088, 609 LOC for the 4. 14 […] it would cost approximately $ 14 725 449 000” • 4, 316 developers, 519 companies, 8. 5 changes/hour (4. 8 -4. 13) 21

Workflows: a Kernel esetén nem megfelelő… Centralized: Git. Flow / NVIE Trunk-based Integration-manager: Git. Hub / Git. Lab flow 22

Workflow: „Dictatorand Lieutenants” https: //martinfowler. com/articles/branching-patterns. html https: //git-scm. com/book/en/v 2/Distributed-Git-Distributed-Workflows 23

Development Model: Upstreaming Linus dönti el, hogy a -next fából mi kerül át a mainline Kernelbe 24

Linux kernel release cycle • Upstreaming – Fizikailag független kódfák egyesítése a fő kódfa irányában – Független a részfák fejlesztési metodológiájától • A fő kódfa („mainline”) minden release után két hétig nyitott merge/pull requestek számára ( a „kernel dictator” dönt) – Az al-kódfák kezelői a maintainer-ek (v 4. 4 1087 maintainer) – Ekkor csak merge patch-eket látnak szívesen • Ezt követi 6 -8 hét tesztelés és bugfixelés – A pontos hossz a patch-ektől függ (méret+komplexitás) 25

Greg KH: „I don’t want your code” ? ? ? • https: //github. com/gregkh/presentation-linux-maintainer/blob/master/maintainer. pdf • I don't want your code - Linux Kernel Maintainers , why are they so grumpy? – Patches I received in a 2 week period: 487 – Subject: [PATCH 48/48] – 15 patch series, no order given – Patches 1, 3 -10 – Signature saying email was confidential – Patch created in /usr/src/linux-2. 6. 32 – Wrong coding style, and acknowledged it – Broke the build on patch 3/6 and fixed it on 6/6 – 1 patch, 450 kb big (4500 lines added) • This was a calm two weeks 26

Android = Linux? • Részben igaz: So. C kernel (System-on-a-Chip) – Általában egy régi LTS az alap, ehhez jön SOK google-specific és So. C-specific és device-specific kód, nincs publikus tesztelés, az eszközökben MINIMUM 2 éves, eszközfüggő kernel van – „ 6171 files changed 2837180 insertions(+), 42568 deletions(-)” „ 88% of your kernel has never been reviewed by anyone in the community” https: //www. slideshare. net/ennael/kernel-recipes-2017 -linux-kernel-release-model-greg-kh – A Google szerint a google-specific kód kevés és folyamatosan csökken, ~40 K LOC (FEB/2018) • Nov/2019 Linux Plumbers Conference – Cél: Android futtatása „stock” ARM 64 kernellel – “We have miles to go, and we know that, but we've come along from where we started […] Last year, I talked it into existence. This time, we actually have problems to discuss. “ – Zárt forrású driverek + nincs állandó belső kernel API = ? ? ? … 27

Köszönöm a figyelmet! GIT (actually) http: //users. nik. uni-obuda. hu/prog 4/ 28