git equivalente a hg mq?

Question

Ho appena iniziato a utilizzare Git insieme a Mercurial per familiarizzare con Git.

Utilizzo ampiamente l'estensione mq in Mercurial per gestire le patch locali e sto cercando un equivalente Git.

Dovrei semplicemente usare il ramo Git?Oppure esistono modi migliori per gestire le patch locali che consentono di applicare e rimuovere facilmente le patch?

Grazie,

Answer 1

Check out "per la gestione delle patch strati di interfaccia" nella sezione delle interfacce , frontend e Strumenti pagina su Git Wiki. Vengono elencate due interfacce di gestione delle patch, grosso modo equivalenti a '' mq Mercurials estensione :

• StGIT (Stacked Git), più vecchio dei due, scritto in Python, utilizza due istantanee per rappresentano patch
• Guilt (ex 'GQ'), scritto come una serie di script bash, serie di file e le patch (una per file) vengono memorizzati come file di testo.
• pg (Patchy Git) è deprecato , e non è più mantenuto.

Ma se non è necessario l'utilizzo più avanzato, è possibile utilizzare invece " git rebase --interactive " per riordinare, squash e patch di divisione. E per gestire il ramo contro versione corrente di upstream, "git rebase" di solito sarebbe sufficiente.

Answer 2

Disclaimer:Non sono un utente di hg, quindi ho letto di hg ma non ho molta esperienza diretta nell'usarlo.

git fornisce diversi strumenti molto potenti e flessibili per la gestione dei rami in stile "coda di patch", quindi per molti casi d'uso di base (e anche alcuni piuttosto complessi), git nativo è sufficientemente potente.

In genere, la maggior parte dei progetti mantiene un ramo master centrale stabile che ottiene solo nuovi commit e non viene mai "riavvolto", quindi i commit nel ramo master sono fissi.

Oltre a ciò, un manutentore (o uno sviluppatore) può mantenere uno o più rami fluidi di patch in lavorazione (ad es.commit) che si basano sul ramo stabile.

Le tipiche attività di gestione delle patch includono:

ribasare la coda delle patch sull'ultimo ramo stabile: utilizzare git rebase,

duplicare la coda delle patch su un vecchio ramo di manutenzione: utilizzare git branch E git rebase,

riordinare le patch in coda - utilizzare git rebase --interactive (aka git rebase -i) utilizzando un editor di testo per riordinare la coda.

cerotti schiaccianti - utilizzo git rebase -i con la direttiva sulla zucca

alterare le patch o i messaggi di commit delle patch: utilizzare git rebase -i (individuiamo un tema?) con la direttiva di modifica.

Qualsiasi attività che alteri una patch in qualsiasi modo (ad es.i suoi contenuti, descrizione o parentela) creerà un nuovo commit con un nuovo ID commit per quella patch.Il fatto che i vecchi commit possano essere eliminati e sostituiti regolarmente prima di essere promossi al ramo master stabile è l'unica cosa che li rende una "coda di patch" piuttosto che un ramo, ma questa è una convenzione di progetto piuttosto che una differenza fisica nei dati che compongono i commit.Per Git sono oggetti identici.

Per promuovere una patch a commit 'reale' è sufficiente spostare la patch in primo piano nella coda e unirla al ramo master.Dopo aver spostato la patch in primo piano nella coda, è proprio come un normale commit basato sul ramo master, quindi unirlo fa semplicemente avanzare velocemente il puntatore del ramo master per puntare al commit della patch.

Pubblicare questo commit come patch master "stabile" è l'atto che dice:questo è ormai un impegno che non cambierà e fa parte della storia immutabile del progetto.

Answer 3

Basta usare un ramo e rebase contro la filiale a monte regolarmente. Questo è allo stesso tempo più facile da gestire e più sicuro di utilizzare mq (a cui ho perso i dati in passato).

Answer 4

Git in realtà non fornisce questa funzionalità stessa. A seconda delle usi, si potrebbe essere in grado di cavarsela con "git stash" e / o di rami, ma sarà piuttosto semplice. Se le persone hanno una gestione più avanzata delle patch ha bisogno con git, sembrano girare a trapunta o StGit: vedi http: // git.or.cz/gitwiki/PatchManagement