Sembra sia per Mercurial che per Git, se non eseguo il commit per primo, non riesco a spingere?Spingere senza commit in Mercurial o Git
Quindi, se non eseguo il commit (quando non è ancora pronto), non posso inviare a un server remoto il backup del mio codice? Il codice è in un computer portatile, trasportato in giro, che può essere in qualche modo fragile trasportato.
Questo è corretto. Lo scopo del push è di condividere uno o più commit con altri repository. Né sono principalmente intesi come backup (anche se alcune persone li usano per questo).
Esistono numerosi strumenti di backup dedicati e servizi online. Vedi Online backup for personal use per un elenco.
Questo è corretto; non puoi spingere le modifiche senza commit. Tuttavia, solo perché le tue modifiche non sono ancora pronte non significa che non puoi impegnarle. Non ho esperienza con Mercurial, ma con Git, puoi modificare un commit (git commit --amend) per modificarlo dopo che è stato eseguito il commit. Puoi anche fare una serie di commit e poi fare un rebase interattivo per combinarli in un singolo commit. Oppure puoi semplicemente eseguire le commit se necessario e non preoccuparti di assicurarti che la tua cronologia sia completamente originale.
Come spiegato in [RECUPERARE DA RIPRODUZIONE UPSTREAM] (http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html#_recovering_from_upstream_rebase), '--amend' può diventare un grosso problema . Chiunque estragga dalla versione pre-emendamento deve modificare la propria cronologia una volta ottenuta la versione modificata. –
Questo è rilevante solo se il repository a cui sta spingendo è condiviso. Se lo sta solo usando per scopi di backup, non dovrebbe essere un problema. – mkarasek
... e il ramo è ufficiale.Se si preme su un ramo chiamato 'my-wip' e qualcuno pensa di dover costruire un prodotto intorno a questo, allora meritano confusione. – Dustin
Sei sempre pronto per il commit.
Impegnarsi spesso. Impegnarsi in un ramo di lavoro in corso e distribuirlo nel modo più ampio possibile.
Quando arrivi allo stato in cui ti stai riferendo come "pronto al commit", esamina la divergenza del tuo ramo dall'upstream, fai un rebase -i per pulirlo e farlo apparire come desideri.
Questo sarà più facile, più sicuro e, in generale, ti darà risultati migliori rispetto a cercare davvero di ottenere tutto perfetto prima di impegnarti. Ricorda: un commit non rappresenta necessariamente uno stato permanente desiderato dell'universo. È solo da qualche parte che sei. Come lo pubblichi dipende da te.
git rende molto facile pubblicare un ramo do-not-look-at-me per il vostro lavoro in progress che in seguito sarà possibile entrare nella vostra base di codice ufficiale a qualsiasi punto ed in qualsiasi forma si pensa meglio vi si addice.
Basta creare un nuovo ramo di lancio.
Avviare le modifiche semicarbonizzate in quel ramo e spingere quel ramo.
Quando le modifiche sono pronte, schiaccia i tuoi commit a metà (utilizzando rebase) e unisci il risultato nel tuo master ed elimina il ramo di lancio. (È possibile eliminare un ramo da un repository remoto utilizzando git push origin :branch: notare i due punti prima del nome del ramo.)
Non c'è mai un motivo per non confermare le modifiche, anche se potrebbero esserci motivi per non commettere in un ramo particolare quando non sono ancora pronti.
Lemme vedi se lo scenario è corretto. Hai...
... ma il tuo capo fastidioso si batte sulla indietro e dice "Ehi! Quando hai intenzione di spingere quel cambiamento che hai menzionato nella riunione del personale? Stiamo tutti aspettando!" Lui sta lì in attesa che tu lo faccia, quindi come fai a tirarlo fuori dai capelli velocemente e facilmente?
Questo è facile. Vuoi usare lo MQ extension. È in bundle con l'installazione standard di Mercurial.
Innanzitutto aggiungilo al file .hgrc.
[extensions]
mq =
per riporre le modifiche non impegnati in una voce di coda delle patch, fare questo:
$ hg qnew stash
$ hg qpop
Ora spingere il più vecchio commette, così il vostro capo vi scendere la schiena.
$ hg push
Infine, ripristinare la directory di lavoro in questo modo:
$ hg qpush
A questo punto, avete ancora la patch registrato nella vostra coda di patch. È appena contrassegnato come "applicato" ora. Terminare la modifica del codice, poi fare questo per aggiornare la patch con le modifiche finiti e un messaggio di commit di registro, quindi finalizzare la patch in un changeset:
$ hg qrefresh -m"Commit message goes here."
$ hg qfinish stash
Ecco le nozioni di base, ma c'è molto di più si può fare se vuoi diventare davvero fantasioso. L'estensione MQ è come un nuovo mondo di controllo di revisione nascosto sotto il repository Mercurial. È come la scorta di Git, ma più flessibile e marginalmente meno confusa.
Impara, muta, evolvi!
disporre di un sistema di backup separato può sembrare un po 'una seccatura. Se solo Git o Mercurial possono consentire alle persone di impostare un repo per push non vincolato. Qualcosa come 'git push --uncommitted ssh: // some/peter/tmp' –
@Jian, ancora, questi non sono programmi di backup. L'idea è di fare uno o più commit significativi, che poi condividi. Non avrebbe molto senso avere un repository che contenesse sia commit che work-in-progress. –
Anche il "sistema di backup separato" può essere un repository. Questo è il modo in cui lavoro: codice nel mio repository personale (dove mi impegno spesso), e ho un repository centrale per condividere il mio lavoro con i miei colleghi (dove spingo, ma meno spesso). Per fare il backup del lavoro che faccio nel mio repository personale, ho un terzo repository: un hook nel mio repository personale esegue una push su quel repository di backup ogni volta che commetto. In questo modo, l'operazione di backup è completamente trasparente (la penalità temporale è trascurabile). – barjak