Comment mettre de côté un tas de changements non validés tout en travaillant sur autre chose

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

mercurial

17 juil. 2012Erik

Vous avez plusieurs options:

Shelve les articles. Cela enregistre les modifications et les supprime du répertoire de travail afin que la branche puisse continuer. Il ne crée pas de jeu de modifications.
```
hg shelve --all --name "UnfinishedChanges"

hg unshelve --name "UnfinishedChanges"
```
Mise à jour/Édition : les versions plus récentes de Mercurial devront peut-être utiliser
```
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 paniquer.
File d'attente des correctifs les éléments utilisant mq. Ce n'est pas trop différent pour être mis de côté à certains égards, mais se comporte différemment. Le résultat final est le même, les modifications sont supprimées et peuvent éventuellement être réappliquées ultérieurement. Lorsqu'ils sont poussés, les correctifs sont des ensembles de modifications logiques, lorsqu'ils sont extraits, 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"
```
Validez-les localement, mettez à jour le jeu de modifications précédent et continuez à travailler et à utiliser des branches anonymes (ou plusieurs têtes). Si vous souhaitez ensuite les modifications, vous pouvez fusionner les têtes. Si vous ne voulez pas les changements, vous pouvez strip le change-set.
```
hg commit -m"Commiting unfinished work in-line."
hg update -r<previous revision>

hg strip -r<revision of temporary commit>
```
Validez-les dans une branche nommée. Le flux de travail devient alors le même que l'option 3 - fusionner ou supprimer lorsque 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 les ensembles de modifications ou de vérifier le code partiel (tant que cela ne finit pas par être poussé). Cela peut être utilisé en conjonction avec le nouveau Phase truc pour cacher vos changements locaux des autres utilisateurs si besoin est.

J'utilise également la commande rebase pour déplacer les ensembles de modifications afin d'éviter les fusions où une fusion n'ajouterait rien à l'historique du code. Les fusions que j'ai tendance à économiser pour l'activité entre les branches importantes (telles que les branches de publication), ou l'activité d'une branche de fonctionnalité plus longue. Il y a aussi la commande histedit que j'utilise pour compresser les ensembles de modifications où leur "bavardage" réduit la valeur.

Les files d'attente de correctifs sont également un mécanisme courant pour ce faire, mais elles ont une sémantique de pile. Vous push et pop des correctifs, mais un correctif qui est "en dessous" d'un autre correctif dans la pile nécessite que celui du dessus soit également poussé.

Attention , comme avec toutes ces options, si les fichiers ont plus de changements depuis les changements temporaires que vous avez mis en attente/mis en file d'attente/branchés, il y aura fusion résolution requise lors du retrait des étagères/pousser/fusionner.

129

17 juil. 2012Adam Houldsworth

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

Je n'aime pas les branchements de clones car j'aime que chaque projet n'ait qu'un répertoire one. Travailler sur différents répertoires en même temps gâche complètement l'historique des fichiers récents de mes éditeurs. Je finis toujours par changer le mauvais fichier. Donc je ne fais plus ça.
J'utilise shelve pour des solutions rapides (juste pour déplacer mes modifications non validées vers une autre branche, si je me rends compte que je suis dans la mauvaise). Vous parlez de jours, pas question de ranger quelque chose pendant des jours.
Je pense que mq est trop compliqué pour une telle situation ordinaire

Je pense que la meilleure façon est de simplement valider vos modifications, que de revenir à l'ensemble de modifications avant de commencer ces modifications et de travailler à partir de là. Il y a quelques problèmes mineurs, permettez-moi d'illustrer:

Supposons que vous ayez l'ensemble de modifications A. Que vous commenciez vos modifications. À ce stade, vous souhaitez le mettre de côté pendant un certain temps. Tout d'abord, engagez votre travail:

hg ci -m "Working on new stuff"

Si vous le souhaitez, vous pouvez ajouter un signet pour faciliter le retour plus tard. Je crée toujours des signets pour mes succursales anonymes.

hg bookmark new-stuff

Revenir à l'ensemble de modifications avant ces modifications

hg update A

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

hg Push -r C

Ou vous pouvez changer la phase du new-stuff branche à secret. Les modifications secrètes ne seront pas poussées.

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

25 juil. 2012Rafael Piccolo

Pour conserver les modifications locales non validées, le moyen le plus simple pour moi consiste simplement à les enregistrer en tant que fichier de correctif.

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

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

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

20 juin 2014mapcuk

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

MyProject.Root
MyProject.BugFix1
MyProject.BugFix2
MyProject.FeatureChange1
MyProject.FeatureChange2

Les 4 enfants sont tous clonés depuis la racine et Push/pull vers/depuis la racine. La racine puis Push/Pulls du repo maître sur le réseau/Internet quelque part. La racine agit comme votre sorte de zone de mise en scène personnelle.

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

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

[Modifier les commentaires suivants]: -

Pour conclure alors ... ce que vous faites est tout à fait bien et normal. Je dirais que c'est la meilleure façon de travailler lorsque les conditions suivantes sont vraies: 1) c'est de courte durée 2) vous n'avez pas besoin de collaborer avec d'autres développeurs 3) les changements n'ont pas besoin de quitter votre PC jusqu'à ce qu'ils soient validés/Temps de poussée.

17 juil. 2012nbevans