A git sokmindenre jó, de csak egy ember fejlesztését tudja rendesen nyomon követni, közös kódbázis kezelésére tökéletesen alkalmatlan.
A megoldás: valamilyen webes frontend használata, ami pótolja a git hiányosságait (gitee, github, gitlab stb.), különös hangsúllyal a PR-ek kezelésére. Ha többen is dolgoznának egy git repón, felejts el minden mást, csakis PR, kevesebb ősz hajszálad lesz.
Mivel időközben másik fejlesztő módosíthatott az állományokon, ezért kell egy lépés a 3. pont után, amiben ismételten lehúzom a közös repóból a változásokat, ez elvégzi a változások összefűzését. Az itt felmerült kérdésem: mi történik, ha a 4. lépés előtt történik a közös repóban egy változás?Összefossa magát a git és nem fog engedni push-olni, még akkor sem, ha triviális lenne a két változat összefésülése (azaz ha nincs átfedés a módosítások között, pl. másik függvény változott, mint amit te módosítottál). Erre a git képtelen. Elvileg itt lenne ez a merge, de én már annyiszor megszoptam vele, hogy inkább teljesen kizártam a workflow-mból. Ha másvalaki időközben belemódosított, és emiatt besír a push, akkor inkább pull (és fetch-rebase) helyett leklónozom a módosított remote repót egy másik könyvtárba, lokális diff, és átkopiszatázom bele a módosításaimat kézzel, egyesével, majd az új könyvtárból commit+push, a korábbi lokális git repó meg töröl. Nem szép, iszonyat gány megoldás, de higgy nekem, SOKKAL időkímélőbb és időhatékonyabb, mint bármi más gites ökörködés (bónuszként a git history-t sem b*assza össze). Megjegyzem, a PR is lényegében pontosan ugyanezt csinálja, csak épp az remote oldalon duplikálja le és diffeli a repót. (Itt általában az szokott felmerülni, hogy kézzel, egyesével átkopipasztázni a módosításokat macerás, de ha rendes gyakorisággal van commitolva, akkor minimális lesz, és végeredményben gyorsabban elkészülsz vele, mint ha rebase conflicttal bohóckodnál.)