Git-svn dcommit dopo aver unito git è pericoloso?


Answers

Creare rami locali è sicuramente possibile con git-svn. Finché stai usando solo le filiali locali e non provi a usare git per unire i rami svn upstream, dovresti stare bene.

Ho un ramo "master" che uso per tenere traccia del server svn. Questo è l'unico ramo da cui non riesco. Se sto facendo del lavoro, creo un ramo tematico e ci lavoro su di esso. Quando voglio commetterlo, faccio quanto segue:

  1. Impegna tutto sul ramo dell'argomento
  2. git svn rebase (risolvi eventuali conflitti tra il tuo lavoro e svn)
  3. git checkout master
  4. git svn rebase (questo fa il passo successivo una fusione veloce, vedere i commenti di Aaron sotto)
  5. git si unisce topic_branch
  6. risolvere eventuali conflitti di unione (non ci dovrebbero essere a questo punto)
  7. git svn dcommit

Ho anche un'altra situazione in cui ho bisogno di mantenere alcune modifiche locali (per il debug) che non dovrebbero mai essere spinte fino a svn. Per questo, ho il ramo master di cui sopra ma anche un ramo chiamato "lavoro" dove normalmente lavoro. I rami degli argomenti sono derivati ​​dal lavoro. Quando voglio impegnarmi a lavorare lì, eseguo il checkout di master e uso cherry-pick per prelevare i commit dal ramo di lavoro che voglio convertire in svn. Questo perché voglio evitare di commettere i tre commit locali del cambiamento. Quindi, invio dal master branch e rebase tutto.

Vale la pena eseguire git svn dcommit -n prima per assicurarsi che si stia per commettere esattamente ciò che si intende impegnare. A differenza di git, riscrivere la storia in svn è difficile!

Sento che ci deve essere un modo migliore per unire il cambiamento su un ramo dell'argomento mentre si saltano quei cambiamenti locali rispetto all'utilizzo di cherry-pick, quindi se qualcuno ha qualche idea sarebbe gradita.

Question

La mia motivazione per provare git-svn è la fusione e la ramificazione senza sforzo. Poi ho notato che l'uomo git-svn (1) dice:

L'esecuzione di git-merge o git-pull NON è consigliata su un ramo dal quale si intende eseguire il dcommit. Subversion non rappresenta fusioni in alcun modo ragionevole o utile; quindi gli utenti che usano Subversion non possono vedere alcuna fusione che hai fatto. Inoltre, se si uniscono o si estraggono da un ramo git che è un mirror di un ramo SVN, dcommit potrebbe commettere il ramo sbagliato.

Questo significa che non riesco a creare un ramo locale da svn / trunk (o da un ramo), incidere via, unire nuovamente in svn / trunk, quindi dcommit? Capisco che gli utenti di svn vedranno lo stesso casino che si fonde in svn pre 1.5.x sono sempre stati, ma ci sono altri svantaggi? Anche quest'ultima frase mi preoccupa. Le persone fanno abitualmente questo tipo di cose?




La risposta di Greg Hewgill in cima non è sicura! Se qualche nuovo commit appare sul trunk tra i due "git svn rebase", l'unione non sarà avanti veloce.

Può essere assicurato usando il flag "--ff-only" su git-merge, ma di solito non eseguo "git svn rebase" nel ramo, solo "git rebase master" su di esso (assumendo che sia solo un local ramo). Quindi, un "git merge thebranch" è garantito per essere veloce avanti.




Rebase il ramo git locale sul ramo git master poi dcommit e in questo modo sembra che tu abbia eseguito tutti quei commit in sequenza in modo tale che le persone svn possano vederlo linearmente come sono abituati. Quindi supponendo che tu abbia un ramo locale chiamato topic che potresti fare

git rebase master topic

che poi eseguirà i tuoi commit sul ramo principale pronto per te a smettere