git svn workflow – feature branch e fusione

Sto usando git-svn con il seguente stream di lavoro ora

git clone  #done once 

successivamente quando lavoro su una funzione

 git branch featureZ git checkout featureZ #make edits for featureZ git commit git checkout master git svn rebase # fetch changes from server git checkout featureZ #go back to branch #git merge master git rebase master #get the changes from SVN->master onto the branch now. Optional if I want the branch to be current. (EDITED: Got from the answer given below) #make edits for featureZ git commit #featureZ completed git checkout master git merge featureZ #getting featureZ onto master. Prepare to send to SVN git svn dcommit #push featureZ back to SVN 

Ora alcuni punti salienti quando faccio una fusione di feature sul master, tutti i singoli commit nel branch di featureZ vengono uniti come uno che va bene per me.

Il messaggio di commit viene sostituito come “unito a featureZ”. Questo può essere risolto con merge fmt msg .

Ora la mia domanda è C’è qualcosa che può andare storto con questo stream di lavoro o deve essere curato. Ho letto nel manuale di git-svn che l’unione non dovrebbe essere eseguita quando si lavora con git svn. Quello che sto facendo nel mio stream di lavoro è ciò a cui si riferiscono? se sì, che tipo di problema causerà? Una cosa è che non voglio fare qualcosa che incasini la linea principale SVN.

SVN non può gestire la cronologia non lineare (semplicemente non ne ha alcuna notazione). Quindi quello che vuoi fare è un rebase invece di un’unione perché conserva la cronologia lineare con SVN (questo è indicato nella pagina man di git-svn qui .

Per elaborare, le storie lineari sono banali. Vanno in linea retta (da A a B a C a D). Mentre le storie non lineari possono andare da (da A a B a C, da B a D poi da C + D a E – in altre parole, si spengono nei rami).

La ridefinizione ti darà una storia lineare. Ricorda che i rebase devono essere eseguiti dai tuoi rami privati ​​locali. Per esempio, se hai 2 rami: master e sperimentale. Verificheresti sperimentalmente e esegui ‘git rebase master’ preferibilmente con l’opzione -i. Farlo viceversa potrebbe causare effetti collaterali indesiderati.

È quindi il tuo checkout master e unisci le modifiche dal ramo sperimentale. La tua storia dovrebbe rimanere lineare.

Si dovrebbe guardare questa opzione di fusione:

 git checkout master git merge --squash featureZ 

Schiaccia tutti i commit sul ramo in un singolo commit sul ramo master. Avrai l’opportunità di modificare il messaggio di log, che viene inizializzato con un riepilogo di ciò che è stato fatto sul ramo.

Ha lo svantaggio che l’individuo si impegna sul ramo della funzione non sono registrati. Inoltre, dovresti farlo solo una volta, e non fare più lavoro sul ramo, perché non è registrato come unione appropriata, e ogni unione successiva potrebbe dare risultati indesiderati.

La risposta fornita da fake-code-monkey-rashid è corretta. Questa è meno una risposta e più di una semplificazione.

Puoi svn rebase / dcommit da qualsiasi ramo git. L’unico master di utilizzo sarebbe se si avessero altre modifiche locali necessarie per unire le modifiche da featureZ .

 git branch featureZ git checkout featureZ #bunch of changes git commit git svn rebase # solve any conflicts git svn dcommit 

Se si desidera mantenere un master pulito, è ansible eseguire il git svn rebase o git merge featuresZ

Invece di git-svn, puoi usare SubGit . È uno strumento lato server che sincronizza automaticamente i repository Subversion e Git.

Puoi utilizzare qualsiasi stream di lavoro Git e qualsiasi client Git disponibile, senza bisogno di strumenti client aggiuntivi.

Considerando il tuo scenario:

 git branch featureZ git checkout featureZ # make edits for featureZ git commit git checkout master 

Puoi procedere come segue:

  1. Sposta interamente il ramo di funzionalità.

     git merge featureZ git push origin refs/heads/* 
  2. Rebase di un ramo di funzione in cima a master / trunk.

     git rebase featureZ git push 
  3. Squash si impegna da un ramo di funzionalità.

     git merge --squash featureZ git commit git push 

Non appena si apportano modifiche, gli hook SubGit traducono le modifiche in revisioni Subversion.

Alcuni ulteriori dettagli:

  • SubGit in molti modi è superiore a git-svn – migliore traduzione di unire-tracking, EOL e supporto di tipo mime, ecc.
  • SubGit richiede l’accesso locale al repository Subversion (utilizza hook personalizzati);
  • SubGit è un prodotto commerciale con alcune opzioni gratuite (progetti open-source e accademici, piccoli team).