TSM - Git: Lecții pentru călătoritul în timp

Bogdan George Barna - DevOps Engineer @ 3PillarGlobal Romania

Git e un utilitar puternic, capabil să rescrie istoria. De asemenea, Git este distribuit, în așa fel că poate rescrie istoria tuturor colaboratorilor unui proiect.

Scufundări artificiale

Lecția 0 - Trecutul este viitor.

Trebuie mers înapoi cu câteva schimbări? git-revert e răspunsul. (Face exact ce scrie pe cutie.)

git-revert - Revert some existing commits

Trebuie adusă înapoi o schimbare mai veche? git-cherry-pick e răspunsul.

git-cherry-pick - Apply the changes introduced by some existing commits

$ git branch 
* a-great-feature 
$ git rev-parse HEAD~3 | head -c3 
8c8710 

$ git checkout -b back-to-the-fuchsia 
Switched to new branch ‚back-to-the-fuchsia’ 

$ git cherry-pick 8c8710 
[back-to-the-fuchsia 2bi302] Reset landing page background color 

Lecția 1 - La întoarcerea în trecut, reține: prezentul nu e doar o dată.

Confirmă-ți punctul în timp analizând fișierul HEAD. Ce este mai exact un git HEAD?

HEAD - symbolic reference to the branch you're currently on

Bun, atunci ce e mai exact un git branch?

branch - in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to

Trebuie mers înapoi pentru a edita o schimbare din trecut? Folosește git-rebase.

git-rebase - Reapply commits on top of another base tip

Lecția 2 - Nu-ți fie rușine de trecut sau teamă pentru viitor. Fiecare lucru negativ se poate preschimba în pozitiv, odată ce știi cum.

Atunci când lucrezi pe un feature branch, e important să faci frecvent commit schimbărilor tale. Nu te deranja de formatul mesajelor din commit cât timp munca e încă WIP.
Atunci cand feature branch-ul e gata pentru a fi evaluat și integrat, sunt utile squash și fixup.

1 pick 405bb71f [JIRA-987] Set doctor=Tennat
2 fixup 67744883 [JIRA-987] Remap Chronopolis for local development
3 squash fd9fb6e4 [JIRA-987] Whitelist Hill Valley on WAF

Lecția 3 - Timpul nu e un râu, acesta e o junglă plină cu monștri.

Git e foarte de ajutor în timp ce se rulează/ merge, cherry-pick, ș.a. m.d. Dar nu poate încă anticipa precis nevoia utilizatorului.
Nu folosi comenzi pe care nu crezi că le stăpânești. Spre exemplu, după git amend, git îți sugerează git pull, dar aici trebuie git push -f cel mai adesea.

Lecția 4 - Mulți factori creează episoadele vieții, factori ce nu pot fi alterați pe o perioadă finită.

Întotdeauna configurează branchul master/release ca protected.

Lecția 5 -În același timp - nu vrem să ne avântăm prea mult pentru că riscăm trezirea demonului.

Tocmai ai pep-8-uit un proiect important. La rularea git blame, numele tau e afișat în locul celor care au chiar scris codul. Ce faci acum?

Lecția 6 - O bună metodă empirică este să-ți oferi o marjă de eroare. Nu vrei să întrerupi curgerea timpului prea des.

Folosește pre-commit hooks, pre-receive hooks și alte asemenea automatizări ce te ajută să scrii cod corect și te opresc din a strica producția. Nu sunt un silver bullet, totuși. Toate aceste utilitare și scripturi trebuie configurate conform nevoilor și proceselor echipei și organizației.

Lecția 7 - Consecințe

Folosește commit conventions și automatizari.

Mai devreme sau mai târziu, va trebui să faci troubleshooting și să analizezi commituri din trecut.
Nu-ți face viitorul mai dificil decât trebuie.

Lecția 8 - Atunci când consideri o călătorie înapoi in timp, deliberează-ți planul cu atenție. Ce speri să obții in trecut?

Nu rula rebase pe trunk/master. Nu rula rebase pe un feature branch folosit concomitent de mai multe persoane.

Lecția 9 - Nu toate interacțiunile temporale merg așa cum au fost plănuite.

Învață să rezolvi conflictele de merge. Vizualizează mereu git tree-ul (git log --graph --oneline --decore poate ajuta).
Folosește trunk-based development și evită branchuri cu o durată de viață lungă (> 3 zile, dar YMMV), ce pot duce la merge hell(s).

În concluzie?

Aparent, git e un utilitar fragil, cu o parte din feature-uri chiar și mai fragile.

Poate părea așa, având în vedere divergența sa privind [plumbing and porcelain user interfaces](https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain ).
Dar antifragilitatea o creezi din componente mai mult sau mai puțin fragile. Conștientizează mereu schimbările aduse și cum acestea pot să încrețească git history-ul.