Fairly new to GIT here (previously on SVN), am o problema de abordare cred. Situatia sta asa: fac dev si mentenanta pe un proiect marisor. Ei, imi vin bugs, enhancements, new features, eu lucrez pe un branch, fac deploy pe un server de staging spre testare si dupa aia fac merge pe master, trimit in productie.
Problema e ca se aduna taskurile in partea de testare (di cauza ca sunt foarte rapid si eficient si rezolv chestiile mai repede decat pot astia sa testeze) si se trezesc ca au un bugfix in mijlocul unei liste de taskuri si il testeaza pe ala si il vor in productie.
O solutie ar fi ca fiecare task sa fie pe branch-ul lui, care sa faca merge in branch-ul de dev, pe care il trimit in staging, dupa testare sa fac merge in master. Pare overkill insa, ca sunt o groaza de chestii mici si rapide, schimbari de texte… Si n-as mai vrea sa stau sa caut si nume de branch-uri.
Cum ar trebui abordata chestia asta?
Also, daca stiti cum sa fac rost de fisierele modificate intre doua commit-uri as mai putea face si manual niste manarii…
Dacă ai reparat un bug într-un commit, și vor să dai sus cu fix-ul ăla, poți să faci merge doar la acel commit, nu e nevoie să faci merge la tot branch-ul. Vezi git-cherry-pick, și răspunsurile de aici, în special ăsta.
Un branch per task (unde task foarte fi orice de la pus o virgula, la modificat functionalitate majora in proiect).
In situatia descrisa de tine, as lucra cu mai multe branch-uri in functie de complexitatea si tipul task-ului, adica as avea un branch special pentru bugfixes, unul pentru enhancements (presupunand ca sunt mici) si cate un branch pentru fiecare feature nou.
Este genul de situație în care se pretează ori git flow ori github flow. Ambele metode se învârt în jurul ideii de un branch pentru orice modificare (indiferent că-i feature sau bugfix).
Branch-ul master este producția, branch-ul dev este staging-ul, prin urmare, tot ce faci aici este ori merge ori accepți PR-uri (practic tot merge-uri).
Eu aș alege Gitflow pentru că mi se pare mai intuitiv: toate branch-urile au nume de genul feature/foohotfix/bar șamd și e destul de greu să nu îți dai seama care-i care.
Nu știu cum aș aborda situația în care tu vrei merge pe dev după ce se testează pe server…
Pe mine articolul ăla m-a ajutat să fiu mult mai ordonat. Este și o unealtă scrisă de același tip, nvie/gitflow, dar nu am folosit-o pentru că nu am adoptat modelul de acolo în mod religios, ci am adaptat puțin la modul meu de lucru și prefer să am flexibilitatea asta. De asemenea, git merge --no-ff feature/whatever (important e --no-ff ăla) e grozav pentru că poți vedea mai ușor istoricul proiectului iar în cazul în care sunt probleme și trebuie să îți dai seama ce funcționalitate a introdus-o, poți sări ușor la punctele de merge.
Dacă folosești un sistem de administrare a funcționalităților, bug-urilor, etc, ai putea folosi ID-ul lor în numirea branch-urilor; asta ar evita, cred, confuziile între branch-uri. Eu așa am început să fac în ideea unor integrări cu alte unelte care știu de ID-urile alea.
Faci diff între B2 și branch-ul care e acum pe server (B1, la commit-ul X) și dai sus cu modificările.
Ideal, și pe server ai tot repo git, și doar dai git checkout [branch name] și acolo (precedat de git pull, bineînțeles). Altfel, tot faci diff-uri între diversele branch-uri, la diversele commit-uri la care sunt fiecare, și aplici modificările.
