Posso applicare un ramo di tipo merge in git?

Question

Sto usando git, e sto impostando i seguenti rami per sostenere il mio flusso di lavoro:

• rilascio, che contiene solo rilasciato un software,
• test, che contiene il software rilasciato al gruppo di test,
• sviluppo, che è dove si verifica lo sviluppo,
• some_topic_branch, dove vengono aggiunte funzionalità, ecc.

I rami di argomento si ramificano e si fondono in sviluppo. Quando siamo pronti per una versione di test, test si fonde in sviluppo. Quando una versione di test viene approvata per la produzione, rilascia le unioni nei test.

Questo è tutto abbastanza facile da configurare, ma mi chiedo le opzioni di applicazione in git. Ad esempio, è possibile applicare un criterio in cui gli unici commit sul ramo release vengono uniti dal test, impedendo che le modifiche avvengano direttamente sul ramo di rilascio?

Answer 1

Bene, una specie di. Ma non penso che tu voglia andare lì.

Come dice Jason, esistono alcuni hook che è possibile utilizzare per evitare determinati comportamenti. In questo caso potremmo usare il gancio di pre-commit per impedire a chiunque di eseguire "git commit". Ma questo è problematico in diversi modi:

1. Per vari motivi di sicurezza, i git hook non sono distribuiti con il repository, quindi non è possibile costringere le persone a usare i propri hook nei propri repository. Ricorda, i loro repository sono i loro, non per te decidere cosa fanno nei loro repository.
2. Cosa succede quando fai un pull o un merg e ottieni conflitti? Per risolvere questi conflitti devi essere in grado di utilizzare "git commit", che abbiamo appena disabilitato.

Questo crea solo più problemi di quanti ne risolva.

Tuttavia, è possibile risolvere questo in altri modi. È possibile creare un flusso di lavoro che applichi questi principi. Ad esempio, immagina di avere la persona A incaricata di eseguire l'unione dal ramo di test nel ramo di rilascio. Se si lascia che solo questa persona sia in grado di trasferire le modifiche al repository centrale (o che quel repository di persone sia il repository "centrale"), è possibile inserire le modifiche dal ramo di test del repository di test o dal ramo di test di tester B (usa la tua immaginazione).

Ciò che è importante qui è rendersi conto che è possibile applicare una politica progettando il modo in cui si comunicano i cambiamenti tra loro. Non tutti devono essere in grado di trasferire le modifiche su un repository. Diamine, non hanno nemmeno bisogno di spingere i loro cambiamenti. Le persone/persone di prova potrebbero apportare modifiche agli sviluppatori, non appena vogliono qualcosa di testato, e in questo modo puoi lasciare che il test decida quando sono pronti a introdurre nuove modifiche, non lasciare che gli sviluppatori decidano quando i tester dovrebbero ottenere il loro cose. Lo stesso principio

Answer 2

Si dovrebbe essere in grado di far rispettare questo utilizzando alcuni git git.

Answer 3

Si potrebbe voler controllare Git flow per qualche idea in più su questo tipo di workflow.

Answer 4

Più di recente, un quadro fatto per l'applicazione dell'autorizzazione, gitolite, può aiutare l'istituzione di tutti i tipi di politiche, ad esempio per consentire solo il tester per unire nella "Testing" ramo.

Inoltre, gitolite propone con VREFs (spiegato in "Gitolite Update Hook exclude a repository") la possibilità di definire molti "hook di aggiornamento" che controlleranno i commit che vengono inviati al repository gestito da gitolite.

Ma tutti questi controlli sono per un repository "centrale", non per tutti gli archivi clonati a valle sulle varie workstation degli sviluppatori.