2015-12-04 14 views
7

Ho una filiale locale, stiamo usando git-flow con Pull Requests e sto cercando di schiacciare alcuni commit dopo aver ricevuto feedback PR.Come schiacciare il mio ramo git si commette nello stesso ramo senza ridefinire?

Come posso schiacciare tutti i miei commit (da PR ad esempio) nello stesso ramo?

immagino che sarebbe qualcosa di simile:

git checkout master     # For master 
git pull        # Get all branches up-to-date 
git checkout feature1     # Checkout the branch 
git checkout -b feature1_squash  # Make a copy of the branch 
git branch -D feature1     # Delete original branch 
git checkout master     # (?) Branch off latest master for safety 
git checkout -b feature1    # Make new (empty) original branch 
git merge --squash feature1_squash  # Merge with squash into it 
git push -f feature1     # Push, force will be required 

ma non sono sicuro.
Con così tanti passaggi sembra anche un buon caso usare una funzione per legare tutto insieme e basta passare il nome del ramo come parametro. Ovviamente automatizzare significherebbe assicurarci di gestire errori, eccezioni, casi limite ecc.

Non voglio usare rebase interattivo perché è un po 'difficile da ottenere per i neofiti che mi alleno. Inoltre, non voglio conoscere il numero di commit, voglio solo fare tutti quelli che esistono su questo ramo.

+1

Non capisco esattamente quello che vuoi. Hai diversi rami con commit diversi su ciascuno e vuoi metterli tutti in un unico commit su un ramo, perdendo così la cronologia dello sviluppo? – houtanb

+1

Ho 1 ramo ('feature1') con diversi commit e voglio che ci sia 1 commit. –

risposta

1

Penso che quello che stai suggerendo sia non convenzionale, e più complicato per i principianti che usare rebase -i per lo squash.

Che cosa è difficile su git rebase -i HEAD~N (con N è il numero di commit per tornare a per lo schiacciamento)? Basta leggere l'elenco e reprimere i commit quando necessario. La guida "Rewriting History" ha più dettagli e penso che sia perfettamente adatta per un nuovo utente.

Si può sempre creare un ramo demo per i tirocinanti su cui esercitarsi. Basta fare 5-6 commit su un ramo per scopi dimostrativi, e fare in modo che il trainee schiacci i commit con rebase interattivo, quindi fai un PR per dimostrare di poterlo gestire su un ramo dal vivo.

+0

Grazie. la ribellione ci ha causato problemi.(troppo) lunga storia. Se i miei passaggi possono essere impacchettati in una funzione, nasconderebbero la complessità. Possiamo fare un ramo demo, ma finiremo comunque con i casi in cui i commenti di Pull Request entrano e facciamo una piccola modifica e vogliamo schiacciarlo. –

+1

Continuo a credere che nascondere la complessità (e anche eludere i tipici casi d'uso dello strumento e utilizzare strumenti esterni per causare lo stesso comportamento) sia un danno per i tuoi tirocinanti. Credo che, in quanto programmatori competenti, una volta rebase alcune volte, diventerà una seconda natura. Puoi anche usare strumenti come gitosis (https://git-scm.com/book/en/v1/Git-on-the-Server-Gitosis) per controllare l'accesso a varie funzionalità, sebbene abbia anche il suo livello di complessità. In ogni caso, buona fortuna, spero che siano in grado di imparare bene! – Todd

+0

Dimentica la gitosi, non viene più mantenuta. la gitolite lo sostituisce e viene mantenuto. –

4

La risposta di VonC è quasi arrivata. ma sapendo che vuoi andare, il commit di 3 è duro.

invece si dovrebbe usare merge-base

git reset --soft $(git merge-base YOUR_BRANCH WHERE_YOU_BRANCHED_FROM) 
git commit 

e modificare il messaggio (o usare git commit -m invece)

se la vostra su quel ramo, è possibile usare la testa e supponendo che germogliò da padrone tua comandi sarebbero (usando origin/master a causa di maestro locale potenzialmente obsoleto)

git reset --soft $(git merge-base HEAD origin/master) 
git commit 

Se non riesci a ricordare dove si ramificata da, il posto dove si sta fondendo il PR è probabilmente corretto

+0

più uno per non aver bisogno di conoscere il numero di commit –

Problemi correlati