1

enter image description here

My application break. I couldn't find where the bugs are, I know that it started to break at commit(2201e03) that I made.

I'm not sure how to go above that, so I decided to do git reset --hard 619176e to reset my application back to where it used to work.

It's work now. I got the message "HEAD is now at 619176e Fix UI in CD Create and Edit" and my application is also back now. Good !

Then, I develop some more, save, commit, and tried to push again, and I CAN'T. As soon as I make changes, and tried to push, I got a message tell me that I am behind 7 commits, and I should perform and PULL and then PUSH. But I don't want that.

If I do that my application will break again. Thus, even if I am behind 7 commits now. I really don't want to delete those commits yet, but I still want to move forward from 619176e.

What should I do ? If I want to keep those 7 commits AND force git to think that 619176e is my HEAD or MASTER ? and move on from here ?

Should I use git reset HEAD^?

Any tip or suggestion will be a huge help for me !!

iori
  • 3,236
  • 12
  • 43
  • 78
  • For what it's worth, `git reset HEAD^` isn't what you are looking for since it is essentially "uncommiting" the last commit without discarding the changes that commit introduced. – Eric Mathison Dec 02 '14 at 22:52

4 Answers4

2

The basic problem is that you don't want to throw away the faulty commits ons master yet, but that's exactly what git reset --hard 619176e does. You did reset your branch (I assume it's the branch master), but the remote branch you are pushing to is still pointing to the old (faulty) state, namely 7 commits ahead.

As Dacotah already suggested, this is the perfect use case for a branch. You can create a new branch starting from commit 619176e via git checkout 619176e -b branchname. Then you can introduce new changes, commit and possibly push them.

As soon as you want to re-integrate the work on master with the bugs on it, you will have to decide which parts of the work you want to use, and which you don't. You might also be able to fix the bugs on master. You would commit those changes to master and then you can merge the branches or rebase your new branch on top of master.

benjamin
  • 1,066
  • 11
  • 22
1

In this case I would probably branch my code once I go back a few commits. I'm not sure if this is a best practice but it is a potential fix. The code for a branch is git checkout -b BranchName

Dacotah
  • 581
  • 1
  • 5
  • 8
  • I'm kind of new to git, so let's say I created a new branch and I will eventually merge it with my master right ? So when that happen, will my application break again ? Please kindly clarify a little bit more. – iori Dec 02 '14 at 18:20
  • I am also kind of new so thats why I'm not sure if it is the best practice. If you plan on merging it with master then you will probably have issues down the road. If this new branch is the one that you want to become master (because it works) then you should reference http://stackoverflow.com/questions/2763006/change-the-current-branch-to-master-in-git for an explanation. Doing it this way allows you to keep the broken code for reference while maintaining a proper master branch – Dacotah Dec 02 '14 at 18:27
1

My suggestion, since it appears that you have pushed several commits to master after 619176e and don't want them removed, is to make another commit that reverts all the changes you have made since 619176e.

First change the state of your working directory to match 619176e.

git checkout 619176e .

This doesn't change the branch you are on or affect existing commits. It simply modifies your files to be EXACTLY as they were in 619176e.

Then make the new commit with git commit.

Other options:

  • Making another branch based off of 619176e. This works ok. It will be difficult to integrate that branch back into master though.

  • Make 619176e master (i.e. git reset --hard 619176e) and force push. If you've already shared master this may cause collaborators to be mad at you. If you haven't shared master yet, this could be a good option and would give you a cleaner history but if you don't want to loose your seven commits, you had better save a reference to them first.

As is often pointed out, it's generally not a good idea to re-write your master branch's history (the main exception to this is when you haven't shared master with anyone yet). If you do git reset --hard 619176e and add more commits, you are re-writing the history of your master branch by replacing the broken commits with your new ones. The hard reset is essentially just pointing your master branch to the specified commit.

Eric Mathison
  • 1,210
  • 10
  • 16
1

What I am about to tell you is very dangerous. If you use:

git push -F

That should force the push to the remote and delete any commits since 619176e. There are a few problems with this. First, if you have other users, they may have the bad commits in their history, and if they push, those bad commits will come back into your repo. Second, if there are other valid commits in the remote, you will lose those.

I'd suggest reverting the bad commits one-by-one, and then if you want squashing them (using an interactive rebase) before pushing the cleaned up repository.

Zeki
  • 5,107
  • 1
  • 20
  • 27