È Branching l'opzione migliore al posto del biforcarsi per i repository git

Question

È Branching l'opzione migliore al posto del biforcarsi per i repository git

#1 da (4 voti)
#2 da (1 voti)

0

Per ragioni a me sconosciute, la forking di repository non è consentita in gitlab nella nostra azienda. L'idea era di consentire allo sviluppatore di eseguire il fork e creare una richiesta di fusione che verrà poi approvata e post-approvazione il codice verrà inviato al repository principale.

Da quando non abbiamo a disposizione l'opzione di forking, stavo pensando di consentire agli sviluppatori di creare branch, gli sviluppatori spingono il codice nel loro branch e poi sollevano una richiesta di Merge e all'approvazione il codice verrà inviato al ramo principale.

Sarà l'approccio giusto o ci sono altri approcci che possiamo guardare?

git

posta Sam 06.07.2018 - 14:54

fonte

2 risposte

Leggi altre domande sui tag git

Il modo migliore per nominare classi e pacchetti in Java Perché gli sviluppatori Python trasmettono stringhe speciali alle funzioni anziché simboli definiti? [chiuso]

score 4 · Answer 1

Il forking e il branching sono pressoché gli stessi per quanto riguarda Git stesso e i workflow Git orientati al team. Nel tuo repository locale puoi avere qualsiasi numero di telecomandi. Quando recuperi gli aggiornamenti da loro puoi vedere i rami remoti localmente, preceduti dal nome del repository remoto. Pertanto potrebbero esserci team/master e anamadeya/master e il tuo ramo master locale. La forcella è solo un'altra serie di rami.

Quindi perché le forche sono comuni nello sviluppo open-source? A causa del controllo degli accessi. Un contributore può pubblicare modifiche sul proprio fork, inviarmi una richiesta pull e posso unire le loro modifiche nel mio repository. Quindi non devo dare accesso in scrittura a tutti coloro che vogliono contribuire.

In una squadra questo è irrilevante: a tutti può essere dato accesso in scrittura. Puoi fidarti l'un l'altro di non abusare di quell'accesso. Pertanto, l'utilizzo di più fork non ha alcun valore aggiuntivo. Puoi semplicemente spingere il lavoro su un ramo separato ed emettere una richiesta pull (gitlab: richiesta di unione) per quel ramo quando è pronto. Mantenere tutto in un unico repository rende anche più facile l'integrazione di strumenti CI esterni e l'uso efficace del software di tracciamento dei problemi.

score 1 · Answer 2

Git è progettato per essere un sistema di controllo delle versioni decentralizzato. Un clone locale sulla tua macchina potrebbe essere chiamato "fork". Ma usare il termine "fork" è un po 'fuorviante.

Lavorare in un team di solito ha l'obbligo di trasferire le modifiche locali in un repository centralizzato ogni giorno. Se potrebbe rompere l'altro codice, le modifiche dovrebbero essere mantenute in un ramo e unite nel ramo master o developmente, non appena sono stabili per evitare conflitti di fusione.

Se disponi di "fork" privati in gitlab, gli altri non possono vedere le tue modifiche e possono avere effetti simili a non premere affatto le modifiche:

Qualcuno potrebbe correggere bug, l'hai già risolto. Ma lui non può vedere.
Nessuno può verificare conflitti di fusione in caso di modifiche difficili, poiché il tuo ramo non è disponibile.
Se ti ammali, nessuno ha i diritti di accesso per unire la tua funzione importante o per continuare il tuo lavoro

Puoi risolvere questi effetti negativi, ma potrebbero essere la ragione per non consentire "fork".