Spero di avere qualche consiglio su come eseguire al meglio una particolare manovra di bitbucket / git che riporterà un repo a una squadra da cui era stato precedentemente biforcato.
Chiamiamolo Repo R, originariamente nel progetto Progetti senza titolo del Team T.
Alcuni mesi fa, Repo R è stato biforcato sull'account personale dell'Utente U, che ha lavorato per un certo numero di mesi, mentre il Team T no. (Quindi, in teoria, lo stato attuale del Repo R languido del Team T è contenuto nella cronologia del Repo R dell'U utente U, ma forse no.)
Ora vogliamo riportare il Repo R dell'Utente U al Team T, dato che l'Utente U non ci sta più lavorando e il Team T lo sarà. (Potrebbe essere stato meglio per l'Utente U aver semplicemente lavorato su di esso sotto il Team T, ma l'acqua sotto il ponte.)
Ora, non possiamo semplicemente riportare Repo R in Untitled Projects, perché il suo nome si scontrerà con il Repo R languido già lì (suppongo).
Non vogliamo rinominare il Repo R rimpatriato, perché ha già il nome più indicativo di quello che serve.
E non vogliamo eliminare il repository languente R, perché potrebbe accadere che Repo R rimpatriato manchi qualcosa o in qualche altro modo deficiente, e dobbiamo tornare a, o almeno consultare, languire il repository R. Inoltre preferirei non rinominare il repository languente R, perché è quello che è sempre stato chiamato.
Quindi, il mio piano provvisorio è quello di creare, nel Team T, un progetto "Obsolete Projects", spostare in questo punto il Repo R languente, e quindi riportare il Repo R dell'Utente U in Untitled Projects.
(Probabilmente otterrai un nome migliore per Progetti senza titolo, più simile a Progetti attivi o somesuch.)
Suona questo piano? C'è qualcosa di meglio che potrei fare? Grazie.
[Modifica rispondendo ai commenti di @BartvanIngenSchenau e @ scriptin]
Sono contrario alla fusione degli sviluppi dell'Utente U nel Repo R languido del Team T per un paio di motivi.
-
Sono diffidente nei confronti delle eventuali modifiche che l'utente U potrebbe aver apportato alla cronologia del suo Repo R e che potrebbe entrare in collisione con Repo R di Team T se unite. Voglio essere sicuro che il Repo R del Team T così com'è è indisturbato.
-
Abbiamo bisogno di avere una buona occhiata a User U's Repo R prima di decidere di andare avanti con quel set di rami. C'è una probabilità del 25% che decidiamo che in genere non è la strada da percorrere, e in fondo vogliamo davvero passare dalla posizione più anziana del Team T. Una volta incorporati nelle modifiche dell'Utente U, ovviamente potremmo ancora ignorarli, ma sarebbero presenti come una distrazione. Ma abbiamo solo un tempo limitato per accedere al Repo R dell'Utente U, quindi dobbiamo spostarlo, copiarlo, clonarlo, forchettarlo o altro, quindi abbiamo un posto dove ispezionarlo e testarlo.