79

There is a git controlled folder on a server where the main branch is checked out and a whole pile of files have been modified and not committed. Is there a way for me to commit the changes to a separate branch so I can go back to a clean version?

ie I want to effecitvely undo all this persons changes but store them in another chance so if that person wants their changes they can switch to that branch.

(Yes I know this is not how git is designed to work but that is my situation!) Any ideas very much appreciated.

rjgonzo
  • 1,761
  • 1
  • 16
  • 29
corydoras
  • 7,130
  • 12
  • 55
  • 58
  • 1
    similar to . and hey, git works very well in your case, i wouldn’t say it’s not designed for such a workflow. it is! – knittl Sep 21 '09 at 07:09
  • Just for clarification, I expect the changes will never be used, but I do need a permanent record just in case. – corydoras Sep 21 '09 at 08:30

3 Answers3

138

First of all moving to a different branch based in the current HEAD is performed like this:

git checkout -b newbranch

Commit all the changes (assuming no newly added files, otherwise git add them):

git commit -a

Go back to the master branch:

git checkout master

The previously uncommitted changes will all be on the newbranch branch, and master will still be at the state it was without those changes.

CB Bailey
  • 755,051
  • 104
  • 632
  • 656
  • 5
    *Explanation:* contents of working repository and staged changes do not belong to any branch. Simple creating new branch off HEAD (last revision) is sufficient for the new commit to go on just created branch ``. – Jakub Narębski Sep 21 '09 at 07:52
  • Thanks guys, I thought switching to a new branch might wipe away the changes. Coming from an SVN background I didn't think switching like this was possible. Testing it out now. – corydoras Sep 21 '09 at 08:29
13

You can always stash your changes.

git stash
git checkout -b bravenewmaster
git stash apply

Also keep in mind, that if you commit to the "wrong" branch you can always move that branch back, because branch is nothing but a pointer to a commit.

Michael Krelin - hacker
  • 138,757
  • 24
  • 193
  • 173
  • 3
    Why bother to stash if you're going to immediately re-apply the same changes? You may as well just do `git checkout -b bravenewmaster`. It's less typing and won't touch all the changed files unnecessarily. – CB Bailey Sep 21 '09 at 06:54
  • 1
    Well, I haven't tried, but I assumed that `git` for whatever reason doesn't let `git checkout -b` when there are changes. Otherwise, why question? ;-) – Michael Krelin - hacker Sep 21 '09 at 07:03
  • Actually, for what I can tell by "I want to effecitvely undo all this persons changes but store them in another chance so if that person wants their changes they can switch to that branch" remark — stashing alone should be sufficient with no branching and applying. – Michael Krelin - hacker Sep 21 '09 at 07:05
  • 1
    If he's storing the changes (rather than 'stashing' temporarily) then it's probably more appropriate to have a commit (with a message) on a named branch than an stash that musn't be accidentally dropped. Both would work, though. – CB Bailey Sep 21 '09 at 07:15
  • 1
    Of course I can't fully understand other people's intentions, but got a feeling that "I want to work on this instance, but you modified the hell of it, would you sidestep please and deal with it yourself later" ;-) – Michael Krelin - hacker Sep 21 '09 at 07:24
13

This method is useful:

git checkout -B <new_branch> <start point>

Where:

  • <new_branch> is your new branch (e.g. my_branch)
  • <start point> is your starting branch (master in your case)
  • -B creates new branch starting from <start point>, if it already exists, then reset it to (it won't fail as -b when branch already exists)
  • sometimes -m can useful to specify when switching branches, this will perform a three-way merge between the current branch, your working tree contents (useful for scripting).

See: man git-checkout for more details.

kenorb
  • 155,785
  • 88
  • 678
  • 743