Git irányelvek

Konfigurálja a git-jét

Az ősi tapasztalatok és szóbeli hagyományok alapján a következő dolgok nagyban hozzájárulnak ahhoz, hogy a commitjaid hasznosabbak legyenek:

  • Győződjön meg róla, hogy mind a user.email, mind a user.name definiálva van a helyi git konfigurációjában

    git config --global <var> <value>
    
  • Győződjön meg róla, hogy itt hozzáadta teljes nevét a Github profiljához. Kérjük, érezze magát elegánsnak, és adja hozzá csapatát, avatarját, kedvenc idézetét és egyebeket ;-)

Commit üzenet szerkezete

A commit üzenet négy részből áll: címke, modul, rövid leírás és teljes leírás. Próbálja követni az előnyben részesített szerkezetet a commit üzeneteihez

[TAG] module: describe your change in a short sentence (ideally < 50 chars)

Long version of the change description, including the rationale for the change,
or a summary of the feature being introduced.

Please spend a lot more time describing WHY the change is being done rather
than WHAT is being changed. This is usually easy to grasp by actually reading
the diff. WHAT should be explained only if there are technical choices
or decision involved. In that case explain WHY this decision was taken.

End the message with references, such as task or bug numbers, PR numbers, and
OPW tickets, following the suggested format:
task-123 (related to task)
Fixes #123  (close related issue on Github)
Closes #123  (close related PR on Github)
opw-123 (related to ticket)

Címke és modul neve

A címkék a commit előtagjaként szolgálnak. Az alábbiak egyike kell, hogy legyenek

  • [FIX] hibajavításokhoz: főként stabil verzióban használatos, de érvényes, ha egy újabb hibát javít a fejlesztési verzióban;

  • [REF] refaktoráláshoz: amikor egy funkciót jelentősen átírnak;

  • [ADD] új modulok hozzáadásához;

  • [REM] erőforrások eltávolításához: halott kód eltávolítása, nézetek eltávolítása, modulok eltávolítása, …;

  • [REV] commitok visszavonásához: ha egy commit problémákat okoz vagy nem kívánatos, a visszavonás ezzel a címkével történik;

  • [MOV] fájlok áthelyezéséhez: használja a git move parancsot, és ne változtassa meg az áthelyezett fájl tartalmát, különben a Git elveszítheti a fájl nyomkövetését és előzményeit; akkor is használatos, amikor kódot helyez át egyik fájlból a másikba;

  • [REL] kiadási commitokhoz: új fő- vagy kisebb stabil verziók;

  • [IMP] fejlesztésekhez: a fejlesztési verzióban végzett változtatások többsége inkrementális fejlesztés, amely nem kapcsolódik más címkéhez;

  • [MERGE] egyesítési commitokhoz: hibajavítások előre portolásához használatos, de fő commitként is szolgálhat több különálló commitot magában foglaló funkciók esetén;

  • [CLA] az Odoo Egyéni Hozzájárulói Licenc aláírásához;

  • [I18N] a fordítási fájlok módosításaihoz;

  • [PERF] for performance patches;

  • [CLN] for code cleanup;

  • [LINT] for linting passes;

A címke után a módosított modul neve következik. Használja a technikai nevet, mivel a funkcionális név idővel változhat. Ha több modult módosítanak, sorolja fel őket, vagy használja a «various» kifejezést, hogy jelezze, hogy több modult érint. Hacsak nem feltétlenül szükséges vagy könnyebb, kerülje a kód módosítását több modulon keresztül ugyanabban a commitban. A modul történetének megértése nehézzé válhat.

Commit üzenet fejléc

After tag and module name comes a meaningful commit message header. It should be self explanatory and include the reason behind the change. Do not use single words like „bugfix” or „improvements”. Try to limit the header length to about 50 characters for readability.

A commit üzenet fejlécének érvényes mondatot kell alkotnia, ha összefűzzük azzal, hogy ha alkalmazzák, ez a commit <header>. Például a [IMP] base: megakadályozza a felhasználók archiválását aktív partnerekhez kapcsolódva helyes, mivel érvényes mondatot alkot: ha alkalmazzák, ez a commit megakadályozza a felhasználók archiválását....

Commit üzenet teljes leírása

Az üzenet leírásában adja meg a módosítások által érintett kódrészletet (modul neve, könyvtár, transzverzális objektum, …) és a módosítások leírását.

Először magyarázza el, MIÉRT módosítja a kódot. Ami fontos, ha valaki visszatér a commitjához körülbelül 4 évtized (vagy 3 nap) múlva, az az, hogy miért tette. Ez a változtatás célja.

What you did can be found in the commit itself. If there was some technical choices involved it is a good idea to explain it also in the commit message after the why. For Odoo R&D developers „PO team asked me to do it” is not a valid why, by the way.

Kérjük, kerülje azokat a commitokat, amelyek egyszerre több modult érintenek. Próbálja meg külön commitokra bontani, ahol az érintett modulok különbözőek. Ez hasznos lesz, ha egy adott modulban külön kell visszavonni a változtatásokat.

Ne habozzon egy kicsit bőbeszédű lenni. A legtöbb ember csak a commit üzenetét fogja látni, és az alapján ítéli meg mindazt, amit életében tett. Semmi nyomás.

Több órát, napot vagy hetet tölt el jelentős funkciók kidolgozásával. Szánjon időt arra, hogy megnyugodjon, és írjon világos és érthető commit üzeneteket.

Ha Ön egy Odoo K+F fejlesztő, a MIÉRT-nek a feladat célját kell tükröznie, amin dolgozik. A teljes specifikációk alkotják a commit üzenet magját. Ha olyan feladaton dolgozik, amelynek nincs célja és specifikációja, kérjük, fontolja meg, hogy tisztázza ezeket, mielőtt folytatná.

Végül itt van néhány példa a helyes commit üzenetekre:

[REF] models: use `parent_path` to implement parent_store

 This replaces the former modified preorder tree traversal (MPTT) with the
 fields `parent_left`/`parent_right`[...]

[FIX] account: remove frenglish

 [...]

 Closes #22793
 Fixes #22769

[FIX] website: remove unused alert div, fixes look of input-group-btn

 Bootstrap's CSS depends on the input-group-btn
 element being the first/last child of its parent.
 This was not the case because of the invisible
 and useless alert.

Megjegyzés

Használja a hosszú leírást a miért magyarázatára, ne a mi-re, a mi látható a diff-ben