0

Scenario: We've following git workflow:

master branch - has releasable code from individual feature branches

to-be-QAd branch - has code from individual feature branches that is yet to be tested by QA

  1. I created a branch feature-A from master
  2. Made few changes committed (commit 1)
  3. Made few more changes and committed (commit 2)
  4. Merged branch feature-A in to to-be-QAd branch
  5. Realized the feature does not work as expected in to-be-QAd branch
  6. Switched to feature-A branch and did reset --hard to previous commit(commit 1) as the last commit had made code worse
  7. Made changes and committed (commit 3)
  8. Merged feature-A branch into to-be-QAd
  9. A file with correct code (that was part of commit-1) gets merged incorrectly. The merge preserves the file from commit 2. (The file is not modified in last commit.)

Not sure what's done wrong here! It seems to be very trivial thing to do as per my limited knowledge of git.

If I'm doing something fundamentally wrong then what is the right approach in such cases, where you've already merged once, need to go back to previous version in feature branch and merge again.

V Patel
  • 48
  • 3

3 Answers3

1

git reset --hard just resets the HEAD pointer. You probably want to do git revert <commit-id>. This effectively undoes the commit and records this in the history, so that the undo action will be merged into your QA branch.

This is from git help revert:

Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them. This requires your working tree to be clean (no modifications from the HEAD commit).

Note: git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see git-reset(1), particularly the --hard option. ...

Related: What's the difference between Git Revert, Checkout and Reset? and How to revert Git repository to a previous commit?.

Community
  • 1
  • 1
krlmlr
  • 25,056
  • 14
  • 120
  • 217
0

the to-be-QAd branch still has the changes from commit2 and some other incorrect files because you didn't undo the merge from the first time when you brought over feature-A.

Before merging over feature-A the second time after making the fixes, I would run git reset --hard on the to-be-QAd branch where is the id of the commit before the first merge on

Edit!

This could cause problems if other developers have committed features to be QAd after the initial merge over. If doing this, take care with what commits you would be backing out.

Keith
  • 686
  • 5
  • 7
  • 1
    What if someone else has already commit-ed to the to-be-QAd branch? – krlmlr Apr 13 '12 at 01:39
  • I agree, I overlooked that fact. Upvoted your post, I think that is the more appropriate solution, especially when working with other developers. – Keith Apr 13 '12 at 01:43
0

When you did 'git reset' on the feature-A branch you went back to commit-1 and then added commit-3. But on the to-be-QAd branch you still had commit-1 and commit-2. Then when you merged feature-A to to-be-QAd you had something like: commit-1, comment-2 and commit-3-merged. Thus, likely something from commit-2 remained. You could solve the problem in a couple of ways:

  1. Do a 'git reset' on both feature-A and to-be-QAd, add commit-3 to feature-A, merge to to-be-QAd
  2. Do a 'git revert' on feature-A to add a commit that un-does commit-2, add commit-3 - after this your feature-A branch will look like: commit-1, commit-2, commit-2-undo, commit-3. Then, merge to to-be-QAd which will get commit-2-undo and commit-3
GoZoner
  • 67,920
  • 20
  • 95
  • 145