Ezen a ponton feltételezzük, hogy ott tartunk, hogy módosítottunk valamit a LibreOffice forrásfájljaiban, ami egy hibát javít, vagy esetleg valamilyen új funkciót valósít meg, és ezt a módosítást be szeretnénk küldeni, hogy a senior fejlesztők ellenőrízzék és mergeljék (beolvasszák) a LibreOffice kódjába.

1. Az általunk módosított, és újonnan létrehozott fájlok (pl. unit tesztek tesztfájlja) hozzáadása a kommithoz
git add elérési_út/fájlnév
konkrét példa:
git add /home/felhasznalonev/libreoffice/core/oox/source/export/drawingml.cxx

(unit tesztekről lásd egy másik útmutatót)

1.a
git status parancs futtatásával lekérdezhetjük, hogy mik az általunk módosított fájlok
attól még, hogy itt nem lesznek felsorolva az újonnan létrehozott fájlok, azokat is git addolni kell

1.b
git checkout elérésiút/fájlnév parancs futtatásával lehet egy fájlt a legutóbbi kommit szerinti állapotba visszamódosítani
vagyis ezen parancs futtatása jellemzően az adott fájlban az általunk végzett módosítások eldobását jelenti

2. tényleges kommitolás
ha git addoltuk azokat a fájlokat, amikben módosításokat végeztünk, illetve az újonnan létrehozott fájlokat, akkor a git status elvileg nem szabadna, hogy fájlokat felsoroljon
ha mégis mutat olyan fájlokat, amik a módosításunk szempontjából lényegtelenek, akkor azokkal nem kell törődnünk

futtassuk a következő parancsot:
git commit
ezt követően egy szövegszerkesztő nyílik meg, ahol meg kell adnunk a kommit szöveget, melyet majd a többi fejlesztő elolvashat
---
ennek formátuma:

rövid leírás (65 karakter), majd azt követően egy üres sor

az üres sor után jöhet a bővebb kifejtés

példa:

tdf#108064 OOXML export: keep preset dashes with linewidth < 1pt

Before this patch prstDash xml tags were preserved only with linewidth 1/4 pt, 1/2 pt or 3/4 pt below 1 pt. Now it is working for example with 0.33 pt.

Change-Id: I36372edfaea560d8913cd4aa8ee551ee059ec682

miután megadtuk a commit szöveget
zárjuk be a szövegszerkesztőt a változtatások mentésével
nanónál pl ctrl+x, majd a kérdésnél, hogy szeretnénk-e menteni, y, vagy magyar esetén i
vi-nál :wq
előfordulhat, hogy vi-nál egy esc gombot is meg kell nyomni, mielőtt beírnánk a kettőspontot

9.a
a change-id-t jó esetben a git commit parancs futtatása automatikusan hozzáilleszti a kommit messagehez, nem nekünk kell ezzel bajlódni, ha mégsem, akkor a ./logerrit submit master parancs nyafogni fog, és felajánlja, hogy a következő parancs futtatásával megoldhatjuk a problémát:
gitdir=$(git rev-parse --git-dir); scp -p -P 29418 TeljesNev@gerrit.libreoffice.org:hooks/commit-msg ${gitdir}/hooks/

9.b
ha mergelés előtt eszünkbe jut valami, amit még szeretnénk módosítani a commiton (akár a fájlokban, akár a commit message-en), akkor használjuk a következő parancsot
git commit --amend
de legyünk óvatosak, ez mindig a legutóbbi kommitot modosítja, tehát nem jó, ha egy új modósítás beküldésénél nem futtatunk git commit parancsot, hanem rögtön a git commit --amend parancsot futtatjuk

a kommitolás nem jelenti a módosításunk feljesztőknek való elküldését, hanem csak lokális adminisztráció
ez pont azért van így, mert lehet, hogy a kommitunkon még módosítani akarunk
a pusholás jelenti a módosításunk továbbítását a távoli adatbázisba

10. pusholás
./logerrit submit master

általában ezen parancs futtatása eredményezi a legtöbb hibaüzenetet (nem pedig az előző lépések), de a hibaüzenetek szerencsére informatívak

ha sikeres volt a pusholás, a gerrit webes felületén a changes menüpontban nyomon követhetjük a módosításunk állapotát, például:
sikeresek voltak-e a jenkins nevű rendszer által futtatott automatizált unit tesztek (ezek egyszerre több oprendszeren is futnak)
(ezzek kapcsolatban előfordulhatnak olyan hibák, amik nem a mi hibánkból adódnak, pl. betelt a szerver memóriája, vagy egyéb ismeretlen ui hiba, ilyenkor egy újabb push, vagy egy rebaselés utáni push segíthet)
volt-e olyan senior feljesztő, aki rábólintott a módosításunk mergelésére
mindkettő +1 pontot ér, ha a fejlesztésünk +2 pontot kapott, akkor mergelhető, kivéve persze merge conflict esetén, vagyis amikor valaki pont abba a fájlba írt bele, amibe mi is (ez például unit tesztek fájljai esetén könnyen előfordulhat)

Ez még nem a végleges változat! csak azért lett közzétéve, mert hátha valakinek szüksége lehet rá :)