2011-11-17 9 views
10

Sto usando la ramificazione per creare e distribuire istanze personalizzate della piattaforma. Queste istanze di solito iniziano come un ramo dal ramo "master", vengono personalizzate in qualche modo, vengono implementate in testing e produzione e infine archiviate.impedendo la fusione tra git e master branch

Se nel master vengono aggiunte nuove funzionalità o correzioni di errori, vorrei essere in grado di recuperarle/unirle nelle istanze del progetto (diramazioni), ma quasi mai non voglio unire le modifiche dai rami al master. Questo è accaduto di recente per sbaglio e ha creato seri mal di testa. Un git pull per aggiornare un repository ha fuso tutto nel master branch e poi è stato reimpostato nel repository principale.

C'è un modo semplice per vietare la fusione nel master? O almeno che richiede un po '--force flag?

risposta

2

È possibile garantire l'assenza di fusione nel master da altri rami vietando a chiunque di spingere il ramo principale. Una persona con autorità può farlo. La gitolite è qualcosa che ti permette di sintonizzare con precisione l'accesso ai rami. È anche possibile scrivere i propri hook lato server e rifiutare l'aggiornamento del ramo master a meno che non si sia un utente specifico.

+0

che cosa è con il downvote? Fammi sapere cosa c'è di sbagliato nella mia risposta e chiarirò. Grazie. –

+0

Ciao Adam, non penso di aver svalutato la tua risposta. Sono abbastanza sicuro di averlo alzato. Ma se ho fatto un errore mi dispiace. Anche Gitolite è un po 'troppo per le nostre esigenze in questo momento, ma posso vedere come i ganci lato server potrebbero fare ciò di cui ho bisogno. – balm

+0

la gitolite è sorprendentemente facile. Ti raccomando di dargli un giro. Il più grande vantaggio è che semplifica enormemente la gestione delle chiavi. Oh, e non volevo dire che eri tu che hai downvoted. Non puoi ottenere quelle informazioni. Ero davvero curioso di sapere perché la mia risposta non soddisfacesse qualcuno o se avessi commesso un errore. –

-1

Se si desidera evitare l'unione in master, è possibile utilizzare l'hook di pre-unione per vietarlo.

+1

Non trovo alcuna prova che esista un aggancio pre-unione. – pjmorse

1

Git è abbastanza contento di lavorare con più repository remoti.

Si consiglia di utilizzare un repository remoto per ogni istanza personalizzata. Ciò non cambierebbe il tuo flusso di lavoro, dato che Git può unire due rami diversi indipendentemente dall'origine.

per aggiornare una "istanza personalizzato" con correzioni di bug dal "master remoto" devi digitare qualcosa come

git checkout <custom-branch> 
git fetch main 
git merge main/master 

dove main è il repository remoto si fa riferimento a come master (ho cambiato il nome per evitare confusione tra un ramo e un telecomando)

Criteri sezioni locali, non si indica main come il ramo monitoraggio remoto, invece specificare una distanza specifica dell'istanza. Ad esempio un repository remoto per istanza personalizzata.

Per spingere le modifiche al campione personalizzato, utilizzare

git push 

Nel raro caso in cui è necessario spingere i cambiamenti a monte del "master" uso ramo

git push main 
+0

Grazie. Questo è esattamente il modo in cui lavoriamo, ma in qualche modo qualcuno ha fatto una spinta git - tutto e poi un tiro di coglioni o qualcosa di simile che univa tutto. O almeno per quello che capisco. – balm

+0

Non usare git pull. Git fetch prima e poi agisce di conseguenza sui rami di monitoraggio remoto aggiornati con l'unione, la rideposizione o il ripristino di rami locali. –

+0

Sono d'accordo con Adam, questo è il modo in cui lo faccio. Assicurati solo di non rebase dopo aver spinto le modifiche o le cose si mettono male. –

Problemi correlati