Comment mettre de côté un tas de modifications non validées pendant que je travaille sur autre chose ?

Question

Si j'ai un tas de modifications non validées et que je veux le mettre de côté tout en travaillant sur autre chose, puis plus tard (par exemple après plusieurs jours) y revenir et continuer à travailler. Quel serait le flux de travail le plus simple pour accomplir cela ? (Jusqu'à présent, je n'ai que de l'expérience avec les fonctionnalités de base de Mercurial). Ma méthode habituelle était de créer une nouvelle branche en utilisant clone, mais il pourrait y avoir de meilleures façons.

Answer 1

Vous avez une poignée d'options :

1. Abri les articles. Cela enregistre les modifications et les supprime du répertoire de travail pour que la branche puisse continuer. Elle ne crée pas de jeu de modifications.

   hg shelve --all --name "UnfinishedChanges"
   
   hg unshelve --name "UnfinishedChanges"

   Mise à jour/Édition : Les nouvelles versions de mercurial peuvent nécessiter l'utilisation de

   hg shelve -n "UnfinishedChanges"
   hg unshelve "UnfinishedChanges"

   Vous pouvez toujours utiliser --name comme alternative à -n mais mercurial ne semble pas aimer --name plus. De plus, le --all n'est plus nécessaire et mercurial va en fait s'en affoler.

2. File d'attente des correctifs les articles en utilisant mq . Ce n'est pas très différent de shelve à certains égards, mais il se comporte différemment. Le résultat final est le même, les modifications sont supprimées et peuvent être éventuellement réappliquées ultérieurement. Lorsqu'ils sont poussés, les correctifs sont des ensembles de modifications logiques, lorsqu'ils sont retirés, ils sont enregistrés ailleurs et ne font pas partie de l'historique des ensembles de modifications.

   hg qnew "UnfinishedWork"
   hg qrefresh
   hg qpop
   
   hg qpush "UnfinishedWork"

3. Livrez-les localement, mettez à jour le jeu de modifications précédent et continuez à travailler en utilisant les branches anonymes (ou les têtes multiples). Si vous voulez ensuite les changements, vous pouvez fusionner les têtes. Si vous ne voulez pas les changements, vous pouvez strip le jeu de monnaie.

   hg commit -m"Commiting unfinished work in-line."
   hg update -r<previous revision>
   
   hg strip -r<revision of temporary commit>

4. Déposez-les dans une branche nommée. Le flux de travail devient alors le même que celui de l'option 3 - fusionner ou dépouiller quand vous êtes prêt.

   hg branch "NewBranch"
   hg commit -m"Commiting unfinished work to temporary named branch."
   hg update <previous branch name>

Personnellement, j'utilise l'option 3 ou 4, car cela ne me dérange pas de supprimer des jeux de modifications ou de vérifier du code partiel (tant qu'il n'est pas poussé). Ceci peut être utilisé en conjonction avec le nouveau Phase pour cacher vos modifications locales aux autres utilisateurs si nécessaire.

J'utilise également le rebase pour déplacer les ensembles de modifications afin d'éviter les fusions qui n'ajouteraient rien à l'histoire du code. J'ai tendance à garder les fusions pour les activités entre les branches importantes (comme les branches de publication), ou les activités d'une branche de fonctionnalité à longue durée de vie. Il y a aussi le histedit que j'utilise pour compresser les ensembles de modifications dont le caractère "bavard" réduit la valeur.

Les files d'attente de patchs sont également un mécanisme courant pour ce faire, mais elles ont une sémantique de pile. Vous poussez et ouvrez les patchs, mais un patch qui se trouve "sous" un autre patch dans la pile nécessite que celui qui se trouve au-dessus soit également poussé.

Avertissement Comme avec toutes ces options, si les fichiers ont subi d'autres modifications depuis les modifications temporaires que vous avez mises en attente / en file d'attente / en branche, une résolution de fusion sera nécessaire lors de la mise en attente / en file d'attente / en branche.

Answer 2

Personnellement, je n'aime aucune des réponses postées jusqu'à présent :

1. Je n'aime pas les branches de clone parce que je veux que chaque projet ait seulement un répertoire. Travailler sur différents répertoires en même temps perturbe complètement l'historique des fichiers récents de mes éditeurs. Je finis toujours par modifier le mauvais fichier. Je ne le fais donc plus.
2. Utilizo shelve pour des corrections rapides (juste pour déplacer mes changements non validés vers une autre branche, si je réalise que je suis sur la mauvaise). Vous parlez de jours, il est hors de question que je mette quelque chose en attente pendant des jours.
3. Creo que mq est trop compliqué pour une situation aussi ordinaire.

Je pense que la meilleure façon est de simplement commiter vos changements, puis de revenir au jeu de modifications avant de commencer ces changements et de travailler à partir de là. Il y a quelques problèmes mineurs, laissez-moi les illustrer :

Disons que vous avez le changeset A. Puis vous commencez vos changements. À ce stade, vous voulez le mettre de côté pendant un certain temps. Tout d'abord, livrez votre travail :

hg ci -m "Working on new stuff"

Si vous le souhaitez, vous pouvez ajouter un signet pour faciliter le retour ultérieur. Je crée toujours des signets vers mes branches anonymes.

hg bookmark new-stuff

Retourner au changeset avant ces modifications

hg update A

A partir de là, vous travaillez et générez le changeset C. Maintenant vous avez 2 têtes (B et C), vous serez averti lorsque vous essayerez de pousser. Vous pouvez pousser une seule branche en spécifiant la tête de cette branche :

hg push -r C

Ou vous pouvez changer la phase de la new-stuff de la branche au secret. Les changesets secrets ne seront pas poussés.

hg phase -r new-stuff --secret --force

Answer 3

Pour conserver les modifications locales non validées, le moyen le plus simple pour moi est de les enregistrer comme un fichier patch.

hg diff > /tmp/`hg id -i`.patch

et quand vous devez revenir à l'état précédent :

hg up <REV_WHERE_SAVED>
hg patch --no-commit /tmp/<REV_WHERE_SAVED>.patch

Answer 4

Vous pouvez simplement cloner votre repo plusieurs fois. J'ai tendance à avoir un clone racine, puis plusieurs enfants à partir de là. Exemple :

• MonProjet.Racine
• MonProjet.BugFix1
• MonProjet.BugFix2
• MonProjet.FeatureChange1
• MonProjet.FeatureChange2

Les 4 enfants sont tous clonés à partir de la racine et poussent/tirent vers/depuis la racine. La racine pousse/tire depuis le dépôt maître sur le réseau/Internet quelque part. La racine agit comme une sorte de zone de transit personnelle.

Dans votre cas, il vous suffit donc de cloner un nouveau dépôt et de commencer à travailler. Laissez votre travail "mis de côté" seul dans l'autre dépôt. C'est aussi simple que cela.

Le seul inconvénient est l'utilisation de l'espace disque, mais si c'était un problème, vous n'utiliseriez pas du tout DVCS de toute façon ;) Oh et il pollue un peu votre liste de "projets récents" de Visual Studio, mais qu'importe.

[Modifier les commentaires suivants] :-

Pour conclure... ce que vous faites est tout à fait bien et normal. Je dirais même que c'est la meilleure façon de travailler lorsque les conditions suivantes sont réunies : 1) c'est de courte durée ; 2) vous n'avez pas besoin de collaborer avec d'autres développeurs ; 3) les changements ne doivent pas quitter votre PC avant le moment du commit/push.