Am lucrat o perioada buna de timp de unul singur, iar acum trezindu-ma intr-un proiect pe echipa, unde-i nevoie de pull request pentru a face merge in master, am dat de o mica problema.
Am avut un feature de dezvoltat, am facut new branch din master, am terminat dezvoltarea, am facut PR spre master. Eh, acum, ca sa nu fiu blocat (pentru ca PRul ramane in pending cateva zile bune) nu stiu care ar fi cea mai buna optiune pentru a putea lucra mai departe (alt branch care depinde de featuresul dezvoltat pe cel care e in pending):
a) fac pull din master pe branchul pe care am lucrat si asa o sa am un branch actualizat si din el creez branch2 pe care continui sa lucrez la features2);
b) astept ca PRul sa fie merge-uit si apoi creez noul branch din master; (insa asta inseamna sa stau degeaba cateva zile, pana e PRul acceptat);
c) fac new branch din master, pull din branchul in PR si continui sa lucrez la features2 (e cam acelasi lucru ca varianta a);
PR-ul ajunge in review, intrebi oamenii daca pot sa iti faca review, daca nu e nimeni disponibil nu te stresezi, iei urmatorul task, daca cineva poate astepti, rezolvi thread/comentariile si dai merge.
Daca depinzi de PR-ul blocat iti faci un nou branch din branch-ul PR-ului.
Dai git rebase origin/master ca sa iti aduci mereu ultima schimbare din master (din mainline e termenul mai corect)
Lucrezi pe branch-ul tau si faci un PR
Daca trebuie sa rezolvi ceva pe branch-ul primului PR atunci treci pe el, dai un git rebase origin/master si il rezolvi acolo. Cand revii la al doilea branch dai git rebase origin/numele-primului-branch ca sa aduci schimbarile din primul branch, dupa mai dai si un git rebase origin/master ca sa fii sigur ca n-ai conflicte din master.
Cand se face merge la primul branch, in PR-ul de la al doilea branch in master o sa vezi ca o sa iti dispara toate change-urile care au fost merge-uite cu primul (fiindca sunt deja in master) - o sa iti ceara un rebase din master si atunci dispar. Daca ai facut rebase-uri intre 1 si 2 la schimbari pe 1 nu ar trebui sa apara conflicte.
P.S. git rebase-ul e putin mai enervant fiindca iti trece prin fiecare commit si trebuie sa rezolvi fiecare conflict intre commit-uri, daca ai 20 de commit-uri pe primul branch o sa fie dureros si confuz. Eu prefer sa fac git amend in loc de commit la fix-uri si sa dau git push -f (force). In acest fel vei avea mai putine commit-uri sau chiar doar unul si poti da rebase-uri linistit.
Dupa fiecare rebase trebuie sa folosesti git push -f, trebuie sa ai grija sa nu cumva sa il rulezi pe master ca poti rescrie toata istoria daca nu e protected.
multam. commiturile sunt o alta problema, m-am obisnuit sa fac destul de des si se observa la PR, mai ales daca am mai multe modificari pe acelasi fisier
Cam ce a zis @isti37 , dar în loc de rebase folosește merge. Nu recomand să faci rebase la branch-uri sau amend la commituri după ce ai făcut push.
taskul 1 / branch1 / PR1 în cod review
taskul 2 / branch2 / PR2 îl faci din
a. master dacă nu ai nevoie de modificările din branch1 și nu o să lucrezi în aceiași zonă de cod (eviți conflictele de merge)
b. din branch1 dacă ai nevoie de modificările din task1
Când alegi 2b, trebuie să fii conștient că ar fi bine să nu trimiți PR2 în review până nu merge-ui PR1, altfel la cod review o să-ți apară modificările de la ambele task-uri și o să fie greu de făcut review. Există și varianta de a face PR2 cu merge în branch1 și atunci vezi doar modificările de la taskul 2, însă după ce merge-uri PR1 trebuie să modifici targetul de la PR2 și pierzi review-urile.
Cât timp lucrezi pe ambele branch-uri faci pull și merge la ultima versiune de master în branch-ul care lucrezi.
Dacă te deranjează numărul de commit-uri, poți face merge cu “squash and merge” atunci când termini fiecare PR și îți reduce fiecare branch la un singur commit și ajungi să ai master branchul cu un log foarte curat.
Nu recomand să folosește rebase sau commit amend decât local. Dacă ai push-uit modificările, nu mai face git push -f (force) că-ți bați joc de colegi care poate au apucat să-și downloadeze codul local și le îngreunezi lor workflow-ul.
Eu nu recomand merge fiindca apare in istoric, in unele echipe nu e o problema, in altele e religie sa nu faci merge ci doar rebase. Claritatea istoricului conteaza cand trebuie sa cauti ceva bug introdus, cu merge-uri graficul o sa fie un arbore complex, cu rebase-uri iti ramane cat de cat linear.
Nu inteleg cum iti bati joc de colegi cu git rebase, inafara de faptul ca nu mai folosesti doar git pull ci trebuie sa dai mereu git rebase origin/numele-branchului de fiecare data. Asta nu e o problema cu feature branch-ul pentru PR daca cel care face review-ul se coordoneaza cu tine.
Dar da, best practice e sa nu faci rebase public (adica daca lucrezi cu doi oameni pe acelasi branch/PR). Eu nu am problema asta fiindca nu lucram mai multi pe acelasi branch ci fiecare pe branch-ul lui.
Pe foarte scurt: merge - va crea un commit cu o lista cu toate commiturile care au fost puse impreuna, rebase - ia toate commiturile si le pune in serie de parca le-ai fi facut direct pe un singur branch.
Unde conteaza si mai mult ? In IDE-uri ai linia de blame, daca faci merge si modifici ceva facut de altcineva fiecare linie pe care ai modificat-o dupa cineva o sa arate cu tu ai scris linia initial cand ai facut merge-ul si va scrie tot tacamul de commit-uri pe un singur blame.
Am gasit si testat optiunea asta in Azure. M-a salvat de macelarirea masterului, de la 13 commituri din branchul sursa, am ajuns la unul singur am vazut ca recomanda stergerea branchului sursa dupa actiunea asta. Cred ca inteleg de ce, commitul general pare ca nu vine de pe un alt branch, ci ca este dat direct in master (astfel branchul sursa nu-si mai are rostul).
Eu îți recomand să eviți să lucrezi la taskuri care depind de alte taskuri in progres. S-ar prea putea să muncești degeaba. Checkout master, pull upstream, branch nou.
Dar cel mai sigur este să întrebi echipa ce fel de mod de lucru se practică.
Problema cu istoricul pe master nu o ai dacă faci squash and merge (dintr-un PR îți rezultă un singur commit).
Din experiențele mele de până acum, echipele care cer git rebase nu prea înțeleg cum funcționează git și pierd mult mai mult timp rezolvând conflicte decât lucrând. Claritatea istoricului se poate obține și altfel, și n-ar trebui să fie o prioritate mai mare decât workflow-ul echipei.
Daca googlesti “git workflow” găsești câteva strategii pentru asta.
Noi facem tot timpul rebase pe master înainte de merge in master. Ce îți rămâne în timp e linia de master și vrei sa o ai cat mai dreaptă și simpla, să nu trebuiască să tot urmărești in istorie îmbârligături pe master. Depinde și de ce tool folosești, cu GitLab ai la merge request checkboxuri de rebase și de delete (dev) branch.
Sunt lucruri la care trebuie sa te sincronizezi cu echipa, gen: fă-mi te rog mai repede review/test/+merge pe dev branchul asta ca să mă pot apuca mai repede de alt issue care depinde de primul. Sau: nu mă apuc de issue-ul asta acum că depinde de cod din dev branch care inca nu e in master.
E bine sa spargi pe cât posibil commit-uri pe maxim o zi de dev. Nu se poate chiar întotdeauna și nu e nevoie chiar întotdeauna (de ex. poți lucra cateva zile fara sa fi deranjat de alte commituri de pe master care te vor pune la merge-uri detaliate în timpul rebase-ului? Adică, mai modifica altcineva zona aia din cod?).
Ca sa ai acele commituri mai granulare, deci chiar cu feature-uri incomplete și ca sa faci release-uri cat se poate de des (codul tau din master trebuie sa fie tot timpul gata de release, iar build/release trebuie sa fie gata și automatizat la un buton, vezi și punctele 2, 3, 4, 5: The Joel Test: 12 Steps to Better Code – Joel on Software) noi folosim feature toggle. Practic pui in master și faci release cu cod pe care nu îl vede userul (fie e ascuns UI printr-o setare/toggle, fie ai backend/refactoring/instalația pregătită pentru un feature viitor fara UI acum): Feature Toggles (aka Feature Flags)
Strategia optima depinde de dimensiunea cod base-ului, număr de oameni din echipa, cat de bine e modularizat codul, modul de lucru, ce tool de git/MR folosești. De asta depinde de la caz la caz, dar sunt bune practici și workflow-uri consacrate. Trebuie sa le cunoști și apoi să alegi optimul din cazul tau.
am vazut ca recomanda stergerea branchului sursa dupa actiunea asta. Cred ca inteleg de ce, commitul general pare ca nu vine de pe un alt branch, ci ca este dat direct in master (astfel branchul sursa nu-si mai are rostul).