what's the Git equivalent of TFS commands shelve/unshelve? cherry-pick?

Question

I found that the shelve/unshelve commands in TFS are very handy and very simple to use. What's the equivalent in Git ?

here's the scenario in TFS :

• I made changes in the trunk
• I shelve : the change set is saved on the server (with a label) and I get the source back before the changes
• I work in the trunk
• Someone can unshelve : get the change set in his workspace

I know that there's a command call cherry-pick but i"m not sure of the workflow and if it fits the need.

Answer 1

git stash is a bit similar, except it is limited to your working tree.

In a DVCS, to achieve that kind of workflow, you need to:

• commit your current changes in a new branch
• checkout the original branch where you can go on, with none of the changes you had introduced (but committed in the new branch)
• push that new branch to a bare repo
• allow another developer to pull that new branch and merge it to his current branch.

Another way would be to let the other developer fetch your branch (where you have committed that special set of changes), and cherry-pick it, but that is not recommended, for cherry-picked commits are hard to track.

Answer 2

you can use the stash command to store the local changes lcoally - being a DCVS there is no concept of central stashing. You could just share your branch with the other person though and they could fetch from it.

Answer 3

You are looking for the stash command, I think. Reference

Answer 4

What you describe is similar to git stash, except since with git you have your own repository (not just a single one on a server), only you can get that change set back.

The general idea is:

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

# do some other things...

# retrieve your changes
git stash pop

If you wanted someone else to have access to this changeset, you'd want to instead commit it to a working branch:

# 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

Answer 5

If I understand what you want to do, the answer is branching. In a lot of older version control systems, branching and merging is expensive and/or painful. In Git, it's fast, easy and fun.

Let's say you're working on the "master" branch and you decide to implement feature X. You get a good start on it, but then your boss tells you that feature Y needs implemented as soon as possible. Phil in the next cube over volunteers to finish feature X while you do feature Y. Here's what you do:

Make and switch to a new branch for your in-progress feature X work, committing your changes:

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

Push it to a server that Phil can see:

$ git push origin feature_x

Go back to the master branch (which has not changed):

$ git checkout master

You might also want to proactively create a new branch for feature Y:

$ git checkout -b feature_y

Phil can now pull down your feature X work and pick up where you left off:

phil$ git fetch origin
phil$ git checkout -t origin/feature_x