Utilizzo di git-svn: Pull, Merge o Rebase?

Question

Ho combattuto la curva di apprendimento git/git-svn e la notte scorsa, come parte di quella curva di apprendimento, ho fatto qualcosa di molto, molto male. Da allora ho corretto, ma spero di capire l'errore nei miei modi.

Ho un repository svn dal quale ho clonato il trunk e i rami (tag che ho ignorato poiché non lavoriamo su quelli). Utilizzando git, ho creato le sezioni locali per ciascuno dei comparti che attualmente bisogno di lavorare con:

$ git checkout -b trunk svn/trunk 
$ git checkout -b feature1 svn/branches/development/feature1 
$ git checkout -b maint svn/branches/maintenance/previous-version 

ho fatto feature1 mio ramo attivo e fatto alcuni cambiamenti prima ottenere tirato via per un paio di giorni. Ho ripreso a farlo ieri ho voluto integrare eventuali modifiche apportate al baule in modo che stavo lavorando con le ultime e le più grandi. Quello che ho fatto è stato un aggiornamento completo di tutti i settori prima, tramite git svn rebase (nessun altro aveva funzionato sul ramo feature1). Con tutto ciò che è stato aggiornato dal mio repository svn, ho provato a rebase.

Con feature1 come ramo attivo, ho creato un "tronco rebase" pensando che avrei apportato le modifiche dal trunk a il ramo feature1. Ho scoperto che mi sbagliavo molto. Dopo aver unito tutti i conflitti, ho fatto uno git svn dcommit e ho scoperto che le mie modifiche erano state applicate al trunk.

La mia prima domanda è semplicemente dov'era l'errore principale nel mio processo di pensiero? Il mio secondo è, dopo molte letture e googling, vedo persone sposare tiri, fusioni e rebases. Dato che voglio unire le modifiche applicate in un ramo locale a un altro ramo locale, cosa devo fare ? Qual è la migliore pratica per questo scenario?

Grazie per il vostro aiuto.

Answer 1

Il problema che si è verificato è che la sintassi della riga di comando per rebase non corrisponde alle aspettative (molto ragionevoli, IMO).

$ git checkout feature1 
$ git rebase trunk 

Questa sequenza aggiunge la feature1 non condiviso impegna sulla testa del tronco, e che ti aspettavi che sarebbe collocare il nuovo tronco impegna sulla testa del feature1. La sintassi ha davvero un senso quando si sa come viene implementato il modello dati di Git (che è senza dubbio il motivo per cui è così com'è). Ma per me è l'opposto di quello che mi aspetto, funzionalmente. È meglio impararlo come un costrutto arbitrario e non provare ad avere aspettative.

Hai ragione a capire come interagire con il repository SVN utilizzando git-svn. Quindi ignora ciò che hai trovato su Google su "spingere e tirare e fondere": c'è un sacco di discussioni giuste da parte di persone che si comportano come se push e pull e fusioni siano le stesse in git e svn. Quasi giusto è ancora sbagliato.

Answer 2

È necessario utilizzare git svn clone -s per clonare l'albero svn completo, inclusi tutti i rami. Da questo momento in poi utilizzare git svn rebasee git svn dcommit in master per gestire svn, ed è possibile creare normali rami git per uso personale.