2

So I made a bad change to my project about four commits ago. I've learned that I can revert back to a previous state as described here, and by checking out previous commits in turn (and testing them on my device) I had identified where the problem happened.

Now I want to go back to the state just before the bad change, and then re-do the subsequent changes (except for the bad change of course). There aren't that many so I can go through them manually, but my question is more about how to handle the git commit/push process so that I don't mess up my repo.

So once I've checked out the old commit (the last "good" one), can I then just make further code changes and then commit and push those to my repo as normal, or am I now on some sort of side branch that I need to merge back on the main branch?

drmrbrewer
  • 11,491
  • 21
  • 85
  • 181

1 Answers1

2

First, that would be an interactive rebase, where you would replay your commit, but dropping the ones which are not good:

git rebase -i SHA1-before-bad-commit

Second, that would rewrite the history of your repository, which means you will need to git push --force after that. That is OK if you are the only one working on that repository.

For Android Studio, see "Rebasing in Android Studio", from Gyula Juhász:

From Android Studio, the same can be achieved, relatively easily. VCS / Git / Rebase is the menu item that has to be chosen and it will show the following dialog:

https://gyulajuhasz.com/blog/blogcontent/hidden_content/uploads/2017/06/07-InteractiveRebase.png

The meaning of Git Root and Branch is straight-forward to find out.
The interesting part is the Onto field.
This has to be the first commit that we would like to see in interactive rebase.
In the example above, this would be HEAD~2.
After clicking Start rebasing, the Studio will present us another window where we can decide the faith of the commits:

https://gyulajuhasz.com/blog/blogcontent/hidden_content/uploads/2017/06/08-InteractiveRebase2.png

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks. If I'm doing everything through the Version Control tab of Android Studio (i.e. not command line), what is the best way of doing that? – drmrbrewer Dec 22 '18 at 09:42
  • @drmrbrewer I have edited the answer to add Android Studio illustrations for an interactive rebase. – VonC Dec 22 '18 at 09:48
  • quick follow-up question (related): if, having checked out different revisions in the history for testing, I then decide to go "back to the top", can I can check out the latest revision (at the top) and then proceed to make further code edits and commit/push as before, without taking any special measures (e.g. rebasing) to get back on track with the repo? – drmrbrewer Dec 22 '18 at 10:55
  • @drmrbrewer If the latest commit has not yet been pushed, you can add new commits and push without issue. If that "op" commit is one already pushed, on top of which you want to make new commits, you can too, but you will have to force push or push a new branch. – VonC Dec 22 '18 at 11:52
  • The commit I mean is indeed one that I have already pushed. When you say "you will have to force push" do you mean, after checking out the top-most commit, and making further code changes, I can commit and *then* "force push"... is that different to just pushing as normal (VCS > Git > Push)? – drmrbrewer Dec 22 '18 at 12:32
  • @drmrbrewer I mean, as mentioned in https://gyulajuhasz.com/blog/rebasing-in-android-studio/, In Android Studio, force push is disabled by default, but it can easily be enabled with a few clicks from the VCS / Git / Push window. The push will differ in that the remote history will be replaced by the one you create locally – VonC Dec 22 '18 at 12:40
  • Except that if you check out the final revision (already pushed to remote) then local is completely in sync with remote and it is good to go from there (without forcing anything)? – drmrbrewer Dec 22 '18 at 13:06
  • 1
    Yes, if you are pushing only new commits, then a regular push is enough. – VonC Dec 22 '18 at 13:50
  • When I tried my first commit (using Android Studio UI) after checking out the final revision, and after making further code changes, I get the message: "The Git repository at the following path is in the detached HEAD state: You can look around, make experimental changes and commit them, but be sure to checkout a branch not to lose your work. Otherwise you risk losing your changes." What does it mean by "be sure to checkout a branch"? – drmrbrewer Dec 22 '18 at 14:03
  • That you need to checkout a branch which references the commit you want to start working from – VonC Dec 22 '18 at 14:44
  • I have never actually created a branch as such. I've always being going along linearly along the main branch. So I assume it's OK to proceed because I must have checked it out from the same branch? – drmrbrewer Dec 22 '18 at 15:37
  • So checkout master: that branch should exist – VonC Dec 22 '18 at 15:41
  • Sorry, it's thoroughly confusing for the beginner, and no doubt very easy to go very wrong. I thought I *had* checked out `master` (or at least a specific commit of `master`) when I right clicked on the top commit and chose `Checkout Revision`? Since doing that, I've made further code changes... is it possible now to preserve those? If I right-click on the top commit again, as well as `Checkout Revision` which I used before, I also have an option for `Branch master > Checkout...` or `Branch origin/master > Checkout As...` ... which if any of these is correct? Will I lose my pending edits? – drmrbrewer Dec 22 '18 at 16:09
  • Even if you go wrong, you will have a hard time losing any commit. That being said, try and reset master to yout current commit – VonC Dec 22 '18 at 16:31
  • OK so it seems that I ended up working on a detached head... to preserve those changes I made on the detached head and to get back onto master I used: `git stash; git checkout master; git stash pop` (source: https://stackoverflow.com/a/27735365/4070848) – drmrbrewer Dec 22 '18 at 17:05
  • 1
    @drmrbrewer Well done. Going back to the command line is generally easier in those instances. – VonC Dec 22 '18 at 21:13