Come gestisci le modifiche minori che vuoi mantenere locali in modo mercuriale?

Lo gestisco in questo modo:

Nel mio repository locale, commetto ogni cambiamento, anche se sto sperimentando. Se sto bene con l'esperimento, e viene testato, lo sposto nel repository remoto. In caso contrario, rimane nel mio repository locale (o torna a una revisione precedente).

L'idea è che il repository remoto contenga solo versioni funzionanti e testate dei miei progetti.

Ci sono un paio di cose che aggiungerò.

Uno è suggerire un flusso di lavoro che faccia un uso giudizioso di shelve , che viene fornito di serie con TortoiseHg .

Ogni volta che volevo impegnare parte della mia attuale directory di lavoro, avrei accantonato le modifiche che non volevo salvare, ricompilare (per assicurarmi di non aver accantonato bit che ora risultano in una compilazione fallita) e poi esegui i miei test Quindi commetterei il set completo, funzionante e testato. Alla fine eseguirò unshelve per ripristinare i miei cambiamenti.

Se avessi delle modifiche piuttosto permanenti, diciamo che volevo un file di configurazione sulla mia macchina di sviluppo per puntare sempre alla porta di localhost 3333 piuttosto che al server di produzione, quindi esaminerei l'estensione delle code Mercurial, che viene fornita con entrambi Mercurial e TortoiseHg .

Non credo che i cambiamenti non eseguiti siano intrinsecamente una cosa negativa. Si fa riferimento a una "incapacità di fondersi con loro" - se si ha una modifica non vincolata ad un file, e si tira e si aggiorna una modifica a quel file, Mercurial avvierà il processo di fusione come se l'avessi commesso, quindi ha chiesto unire. Intendevi qualcosa di diverso?

Quindi, per le modifiche locali che non vuoi ancora condividere con altri sviluppatori, hai due approcci. Il primo è quello di mantenere i cambiamenti nella tua copia di lavoro, ma non li spinge, e l'altro è metterli da parte, fuori dalla copia di lavoro. La scelta dipende dal fatto che desideri rendere disponibili queste modifiche mentre lavori.

Se li tieni nella copia di lavoro, le modifiche in arrivo funzioneranno correttamente, quindi devi solo evitare di creare modifiche in uscita e questo significa evitare di commetterle. Se i file sono nuovi, è facile: basta non aggiungere hg add . Se sono già tracciati, puoi escluderli espressamente dai commit con hg commit --exclude foo.txt . Se hai un numero elevato di file da escludere o li escluderai da molti commit (ad esempio per una modifica permanente a un file di configurazione locale), guarda escludi l'estensione .

Se sei pronto a spostare le modifiche da parte, hai un altro set di opzioni. La cosa più semplice è semplicemente usare hg diff sui file per produrre una patch che li descriva, che conservi in un posto sicuro, quindi hg patch --no-commit per riapplicare quella patch quando vuoi che le modifiche tornino. Puoi renderlo più fluido installando l'estensione shelve , estensione attica , o qualche altro parente. Potresti anche utilizzare l'estensione delle code , ma questo sta usando una mazza per rompere un dado. Potresti anche solo eseguire il commit delle modifiche, quindi aggiornare di nuovo al genitore e impegnarti in altri lavori, lasciando le modifiche in un branch anonimo stub - hg commit -m 'temporary branch' && hg up $(hg log -r 'parents(.)' --template '{node}') (anche se potrebbe essere più facile da fare manualmente!). Dovresti quindi fare attenzione a non spingere quel changeset, però.

Due metodi di base sono usati per separare i flussi di sviluppo.

• Rami con nome. L'idea è, tu lavori sul tuo ramo, il nmichaels_branch_of_awesome. In questo modo puoi commettere i tuoi cambiamenti senza friggere il lavoro di altre persone. Poi ti unisci alle altre persone quando hai bisogno del loro lavoro, e quando arriva il momento per la funzionalità, passi al ramo più stabile per l'integrazione. Io preferisco i rami denominati.

• Clone anonimo. Questo crea un repository separato per la tua sandbox. Qui suona fino a quando non ottieni quello che vuoi, poi (probabilmente) fai una patch MQ per i tuoi commit e spingi da dove hai iniziato. Non sono appassionato di questo approccio, poiché richiede la gestione delle directory e potenzialmente il lavoro di MQ, che può essere un trucco. E con alcuni repository, possono iniziare a ricevere solo un piccolo grande per questo. Detto questo, questo sembra essere preferito dagli sviluppatori Kiln.