0

I feel really stupid right now. I have used a number of version control apps but not git that much. I have read lots of posts, but am more confused than ever as many of the (apparently correct) answers use the command prompt and assumptions that I understand GIT much better than I do.

I am working in windows on a project with multiple people checking in code. We use Git Gui, but I also have Git Bash installed. Up till now, all I have needed to do was commit, push, pull, and merge and life was good.

I want to be able to roll back my code commit session by commit session until I can get back to a version were a module that was tested and complete was working. I have no idea when the code was subsequently broken.

I do NOT want to modify the main repository, but my local version. Once I find the change, I then want to copy the files, restore back to the current version and then apply the diffs from the copied files to the current version and check that in.

I have tried a number of options, but none seem to allow me to do this. And I don't want to screw up the main repository either.

I have to believe this is rather simple, just not sure how to do it. And yes, I could spend a few days learning the intricacies of Git, but right now, I have to get the code working, not break the main repository, and not lose a few days to figuring out git./git gui/etc. (which is really the right way to do it-but people need this code working (again) now.

Thanks!

JustMeToo
  • 325
  • 1
  • 14

1 Answers1

3

Crashmstr's comment is the best way to go: http://git-scm.com/docs/git-bisect

Basically you start bisecting with

$ git bisect start

Then declare your "bad version"

$ git bisect bad                 # Current version is bad

And then declare your last known "good version"

$ git bisect good v2.6.13-rc2    # v2.6.13-rc2 was the last version
                                 # tested that was good

Then you can test each version through bisection until you find the breaking commit.

If you aren't familiar with bisection, basically it's cutting a space into halves until you get the value you want, e.g.

[               bad commit in here                       ]
[[        good            ][          bad               ]]
[[        good            ][[   bad      ][    good     ]]

Until you get the actual commit you want.

A simpler way is to do

git log

And then checkout each commit one at a time until you find the broken one.

E.g.

$ git log
commit 63cd158599d77ac73abcefd087a2f7bdfdb171cb
Author: Jordan 
Date:   Fri May 1 02:12:46 2015 -0700

    Start look at query builder

commit d0ca01f7c7c2e7a2153fbe3c980f79022f096aad
Author: Jordan
Date:   Thu Apr 30 23:48:38 2015 -0700

    TODO: add cloudsearch filtering for inactive

Then you can checkout an old commit without changing anything with

git checkout 63cd15

Until you find the broken one.

jaypb
  • 1,544
  • 10
  • 23
  • Do I have to provide the entire commit string (very tedious) or do I only need the first 6 or so characters? I ask as I have seen similar abbreviations in other threads. – JustMeToo May 05 '15 at 19:10
  • Basically you only need to provide enough characters for git to understand it as a unique hash. 6 is a pretty good rule, although you can go as low as 2 or 3 I think depending on the situation. – jaypb May 05 '15 at 22:36