web-dev-qa-db-fra.com

quel est l'équivalent Git des commandes TFS Shelve / Unshelve? choix de cerise?

J'ai trouvé que les commandes shelve/unshelve dans TFS sont très pratiques et très simples à utiliser. Quel est l'équivalent dans Git?

voici le scénario dans TFS:

  • J'ai fait des changements dans le coffre
  • Je range: l'ensemble de modifications est enregistré sur le serveur (avec une étiquette) et je récupère la source avant les modifications
  • Je travaille dans le coffre
  • Quelqu'un peut démêler: obtenir le changement défini dans son espace de travail

Je sais qu'il existe un appel de commande cherry-pick mais je ne suis pas sûr du flux de travail et s'il correspond au besoin.

gittfs
70
MatthieuGD

Ce que vous décrivez est similaire à git stash , sauf qu'avec git vous avez votre propre référentiel (pas seulement un sur un serveur), vous seul pouvez récupérer ce changement.

L'idée générale est:

# do some stuff
vim foo/bar.c
# stash away your changes
git stash

# do some other things...

# retrieve your changes
git stash pop

Si vous vouliez que quelqu'un d'autre ait accès à cet ensemble de modifications, vous devriez plutôt le valider dans une branche de travail:

# make yourself a branch
git checkout -b temp-featureA
# commit to it
git add foo/bar.c; git commit

# now you Push this branch (or they could just fetch straight from you)
git Push Origin temp-featureA


# Now, in someone else's repo:
# Fetch updates
git fetch Origin
# Make a branch tracking the remote branch
git branch temp-featureA Origin/temp-featureA

# Either check it out:
git checkout temp-featureA
# or cherry-pick it, to apply the changes somewhere else:
git cherry-pick temp-featureA
# or, if it's multiple commits, rebase it!
git rebase --onto my-branch start-of-featureA temp-featureA
81
Cascabel

Ce que vous voulez faire est accompli avec de vieilles branches simples dans git.

De ne belle réponse StackOverflow par JaredPar :

Le rayonnage est un moyen d'enregistrer toutes les modifications sur votre boîte sans vous enregistrer. Les modifications sont conservées sur le serveur.

Cela revient à valider une branche et à la pousser sur un serveur dans git.

Comment faire:

Supposons que vous travaillez sur la branche "maître" et que vous décidez d'implémenter la fonctionnalité X. Vous obtenez un bon départ, mais votre patron vous dit que la fonctionnalité Y doit être implémentée dès que possible. Phil dans le cube suivant sur les volontaires pour terminer la fonctionnalité X pendant que vous effectuez la fonctionnalité Y. Voici ce que vous faites:

Créez une nouvelle branche et passez-y:

$ git checkout -b feature-x

Validez vos modifications:

$ git add filethatyouchanged.cc
$ git commit -m 'partial implementation of feature X'

Poussez-le sur un serveur que Phil peut voir:

$ git Push Origin feature-x

Revenez à la branche principale (qui n'a pas changé):

$ git checkout master

Vous pouvez également créer de manière proactive une nouvelle branche pour la fonction Y:

$ git checkout -b feature-y

Phil peut maintenant dérouler votre travail sur la fonctionnalité X et reprendre là où vous vous étiez arrêté:

phil$ git fetch Origin
phil$ git checkout -t Origin/feature-x
28
Neall

git stash est un peu similaire, sauf qu'il est limité à votre arbre de travail.

Dans un DVCS, pour réaliser ce type de workflow, vous devez:

  • valider vos modifications actuelles dans une nouvelle branche
  • extraire la branche d'origine où vous pouvez continuer, sans aucune des modifications que vous avez introduites (mais validées dans la nouvelle branche)
  • Transférer cette nouvelle branche à un repo nu
  • autoriser un autre développeur à extraire cette nouvelle branche et à la fusionner avec sa branche actuelle.

Une autre façon serait de laisser l'autre développeur récupérer votre branche (où vous avez validé cet ensemble spécial de modifications), et choisissez-le , mais ce n'est pas recommandé, pour cherry- les commits sélectionnés sont difficiles à suivre .

5
VonC