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.
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
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
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
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.
Întotdeauna configurează branchul master/release ca protected.
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?
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.
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.
Nu rula rebase pe trunk/master. Nu rula rebase pe un feature branch folosit concomitent de mai multe persoane.
Î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).
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.
de Ovidiu Mățan
de Daniel Butean , Alex Ghiran , Călin Manea
de Ovidiu Mățan
de Radu Ilea