Cum să mutați seturile de schimbări între două sucursale/foldere cu caracteristici care au o relație de dependență?

Să spunem că lucrăm la două caracteristici: caracteristica A și caracteristica B. Caracteristica B depinde de caracteristica A.

Am terminat caracteristica A și am pus-o pentru o examinare a codului înainte de ao verifica în portbagaj. În timp ce așteptăm feedback de la colaboratori/colaboratori, dorim să începem să lucrăm la funcția B. Deci, creăm un alt dosar sau o altă ramură cu modificări pentru funcția A încorporată.

Dar când un feedback pentru vizualizarea codului de pe caracteristica A spune că trebuie să schimbăm un anumit cod, trebuie să schimbăm atît funcția A/ramură, cît și caracteristica B/ramură. Acest lucru este predispus la erori umane.

Există vreo modalitate pentru ca git sau svn să se asigure că toate modificările din folderul/ramura A vor fi portate și în folderul/ramura B fără a fi verificate în portbagaj sau pentru a muta modificările manual?

0
adăugat
Vizualizări: 4

3 răspunsuri

Dacă acestea sunt dependente, ar trebui să urmăriți doar modificările ulterioare ale funcției B. Funcția de legătură B pentru a include funcția A și în trackerul de probleme/bug-uri. Nu merită timpul să clasificați că corectarea se face pentru caracteristica A. Utilizați comentariile pentru a spune de ce a fost făcut.

0
adăugat

svn: extern pentru folderele din SVN, ramuri de funcții și ramificații (mai bune) pentru SVN și Git

0
adăugat

git sau svn? este aceasta ipotetică? această întrebare însumează exact de ce ați folosi git sau svn în primul rând. da, puteți face acest lucru. iată cum se face cu git.

Voi lăsa-o la tine pentru a cerceta rebase v. Îmbinați fluxurile de lucru cu git, dar iată cum echipa mea face acest lucru ... și o facem tot timpul ... (co = checkout)

branch featureA 
#do stuff

co featureA
#branch off feature a since it's dependent
branch featureB 

mai târziu, puteți oricând să actualizați caracteristica B cu modificările ultime ale caracteristicii A

co featureA
pull --rebase
co featureB
pull --rebase
#update featureB with changes in featureA
rebase featureA
#resolve any conflicts

trunchiul/masterul nu este afectat în nici un fel, după eliberarea dvs. puteți actualiza maestru cu cele mai recente featureB prin verificarea master și rebasing off featureB, apoi împingând noul master full-featured pentru master. acest tip de ciclu dev păstrează maestrul curat (întotdeauna gata să se desfășoare), permițându-vă dev devin concomitent pe multe ramuri cu atâtea dependențe, după cum este necesar. niciodată nu trebuie să faceți schimbări de cod (dacă vreodată credeți că faceți acest lucru, trebuie să vă regândiți fluxul de lucru), dar este posibil să fiți nevoiți să rezolvați conflictele de îmbinare (inevitabile cu orice cod divergent care se îmbină).

co master
rebase featureB
push origin master
0
adăugat
Într-adevăr mai ușor va fi cu Subversion, sigur
adăugat autor Lazy Badger, sursa
Mulțumesc, răspunsul a fost corect la fața locului. Am cerut atât svn cât și git. Se pare că este mai ușor să se facă cu git. În locul meu de muncă folosim SVN, dar unii oameni pozitiv rebeli folosesc git-svn.
adăugat autor genkiro, sursa