Flusso di lavoro Git riguardante i rami di funzionalità remote

Question

Flusso di lavoro Git riguardante i rami di funzionalità remote

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

3

Utilizzo git da un po ', ma ancora non capisco come gestire i branch delle funzionalità.

Quando sviluppi in un branch di funzionalità in modo strettamente locale, tutto ha un senso. Tu commetti, unisci upstream, rebase su master e infine premi tutto.

Le cose cambiano con il ramo di funzione che viene spinto su un telecomando nelle prime fasi. Ora non puoi schiacciare, rebase, ecc. Semplicemente non puoi cambiare la cronologia per altri sviluppatori. Certo, questo è un comportamento corretto.

Quindi non spingere al telecomando? Tutto è solo locale? Un filesystem muore e il tuo ramo va con esso? Una cancellazione casuale di .git ... Non sembra corretta.

Qualche raccomandazione?

git version-control

posta Yuri 05.12.2018 - 18:43

fonte

2 risposte

Leggi altre domande sui tag git version-control

Filosofia di incapsulamento OOP Vantaggi e svantaggi di creare app web puramente con microservizi e ibridi con framework web

score 2 · Answer 1

The golden rule of git rebase is to never use it on public branches. See merging-vs-rebasing

In breve: git rebase cambia la cronologia dei commit, quindi usalo sul tuo ramo personale che non è utilizzato da nessun altro sviluppatore. Quindi puoi inviarlo al remoto per scopi di backup.

git merge introduce un nuovo commit che unisce la cronologia di due rami, quindi è ideale per i rami condivisi tra più sviluppatori.

score 1 · Answer 2

La raccomandazione generale è di non utilizzare le operazioni che cambiano la cronologia sui rami pubblici. Tuttavia, i rami delle caratteristiche dovrebbero essere di breve durata. Generalmente sono lavorati da una persona, o da due o tre persone che lavorano a stretto contatto, in modo tale che l'occasionale spinta della forza possa essere facilmente comunicata e risolta. Quando lavoro in una squadra del genere, di solito utilizzo solo le unioni, quindi, se pensiamo che sia necessario, esegui lo squash o il rebase appena prima di inviare la richiesta di pull.

Se sei davvero paranoico su qualcuno che fonde il tuo ramo in uno stato incompleto e non comunica con te, puoi sempre creare un fork privato nell'area del tuo profilo e renderlo visibile solo a quelli specificati.