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

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


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 stuffvim foo/bar.c# stash away your changesgit stash# do some other things...# retrieve your changesgit 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 branchgit checkout -b temp-featureA# commit to itgit 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 updatesgit fetch origin# Make a branch tracking the remote branchgit 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


What you want to do is accomplished with plain old branching in git.

From a nice StackOverflow answer by JaredPar:

Shelving is a way of saving all of the changes on your box without checking in. The changes are persisted on the server.

This is analogous to committing to a branch and pushing it to a server in git.

How to do it:

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 a new branch and switch to it:

$ git checkout -b feature-x

Commit your changes:

$ 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 originphil$ git checkout -t origin/feature-x


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.