2

I'm using Git as the version control for a Django/ Python project for which I recently took over the development, having not used it much previously.

Recently, I created a new branch from the master branch, in order to work on fixing a bug (obviously, doing the development on my local machine, with the intention of pushing to the server once I had fixed the bug).

The branch on which I have been doing the development work is called dateReceived, and I recently fixed the particular bug that I had created this branch to work on.

After completing the work, I tried to merge dateReceived back with my local master, but there were a number of conflicts which seemed to break my local master branch, and I was unable to resolve them, so the version on my local master was then no longer working.

I restored my local master to a backup I had made from the live version on the server by checking out a commit that I had made prior to starting work on this bug, when everything else was still working. This meant that I was briefly in a 'detached head' state, before I committed/ branched again, and started working from there. I was then no longer in a 'detached head' state.

So, on the live server, I now have the original master branch, which is working correctly- except for the bug that I am working on locally, and on my development machine, I have two branches: master, which is up-to-date with the version on the live server (and on which the bug still exists), and dateReceived, which is working correctly (with the bug fixed).

If I checkout my local master branch, and view the site in my browser from localhost:800/.../.../concept, I can see that the bug still exists when I try to perform that particular function on that page of the website.

But, if I checkout my local dateReceived branch, and view the site in my browser from localhost:8000/.../.../concept, I can see that the bug has been fixed when I try to perform that particular function on that page of the website.

If I try merging dateReceived into master again now on my local machine (ready to push my local master branch to the server once it is up to date with the bug fixed) using the command:

git merge dateReceived

from my master branch, I get a message that says:

Already up-to-date

but it clearly isn't, since the bug still exists in master, but is fixed in dateReceived.

If I run:

git diff dateReceived

from my master branch, a list of the differences between master and dateReceived are shown- so clearly, Git can tell that there are differences between the two branches...

I found a similar question at: Git merge reports "Already up-to-date" though there is a difference

and the accepted answer seems to suggest that the branch I am trying to merge is a parent of my current branch, which I guess may have happened when I restored a commit after breaking my local master.

It seems that the way to resolve this is to do a hard reset, but I am quite wary of doing this, since as I understand, it will completely remove changes, etc with no way of reverting after I do it...

Is this actually the only way to resolve the issue that I'm having with master saying it's already up-to-date when trying to merge another branch into it, even though I can actually see that it's not, or is there anything else I can do?

What are the potential risks of doing a hard reset, and how can I minimise those risks? Is there anything else I can do to resolve this git merge issue, so that I can merge dateReceived into master in order to push the fixed version to the server?

Community
  • 1
  • 1
Noble-Surfer
  • 3,052
  • 11
  • 73
  • 118

1 Answers1

1

the accepted answer seems to suggest that the branch I am trying to merge is a parent of my current branch

I believe that either this is true, or something else happened to your local master branch to put in a bad state. Regardless of what is wrong, you should be safe resetting it to the version which is on the remote, which seems to be working properly (minus the one bug). Try the following:

git fetch origin                 # update origin/master to the remote
git checkout master              # switch to local master branch
git reset --hard origin/master   # reset local master to origin/master

And then try doing the merge again:

git merge dateReceived

If you get merge conflicts, don't panic, but rather examine each conflicted file in your IDE if possible, or even in any text editor. My guess is that you will be able to get through them. Then, make the merge commit and hopefully your bug should be resolved.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
  • Thanks for your answer- I'll do what you've suggested in a moment, but before I do, I just want to check: after performing these steps, and doing the `git reset --hard origin/master`, will I lose any of my previous commits/ other branches, or will all of my commit history and other branches still be there ready to be used again in future if I decide I need to? Apologies if this seems pretty basic- it's just that I am quite new to Git, and still a bit unsure of how it works... – Noble-Surfer Jan 05 '17 at 10:15
  • All good questions: The reset operation will reset your _local_ `master` branch to whatever is on the _remote_. If you have some local commits which you have not yet pushed to the remote, then you should not use this method. If so, I can give you a way to find the commit locally to which to reset. – Tim Biegeleisen Jan 05 '17 at 10:16
  • The setup I am working with is: on the live server, I have one branch- `master`, which is currently in a working state, and my colleagues are using this to manage their work projects every day (which is why I need to be absolutely sure any changes I push to the live server are working and won't break anything else that is currently working). On my local machine, I have several branches- `master`, which should in theory always be the same as the `master` branch on the server, and then have a number of other branches which were created from `master`, with `git branch newBranch`, which I have – Noble-Surfer Jan 05 '17 at 10:28
  • created for every new feature that I have added, and every bug that I have tried to fix. When I am happy that the new feature works, or the bug has been fixed, I then merge the `newBranch` that was created for the development of the new feature/ bug into my local `master`, check that the new feature/ bug resolution works on my `localhost` (while on `master`), and then push my local `master` to the server. – Noble-Surfer Jan 05 '17 at 10:31
  • Unfortunately your comments don't help us find a solution. We need to know whether your current remote `master` branch is acceptable. Please answer this question. – Tim Biegeleisen Jan 05 '17 at 10:37
  • So as things currently stand on my local machine, I have a `master` branch, which is identical to the `master` on the server (where the bug still exists), and a `dateReceived` branch (where the bug has been fixed). But if I try to merge `dateReceived` into `master`, I get the message stating `Already up-to-date`, even though running a `git diff dateReceived` from my local `master` will show that there are differences between the two branches... – Noble-Surfer Jan 05 '17 at 10:37
  • `I have a master branch, which is identical to the master on the server` ... no it's not, or else you could complete the merge. – Tim Biegeleisen Jan 05 '17 at 10:39
  • Ok, yes, the current remote `master` branch is acceptable (it is the state that my local `master` was in before I started working on this bug). The only thing I need to be sure of is that I don't lose the `dateReceived` branch, as that is where the fix currently exists. – Noble-Surfer Jan 05 '17 at 10:44
  • Working on my local `master`, if I run `git status`, it states that there is "nothing to commit, working directory clean" – Noble-Surfer Jan 05 '17 at 10:46
  • If the current remote `master` is acceptable then my answer should work for you. – Tim Biegeleisen Jan 05 '17 at 10:48
  • Thanks- this appears to have worked, and I am now at the point I was at just before this broke last time: after running `git merge dateReceived` from `master`, Git has given me messages stating: Auto-merging projects/forms.py`, `CONFLICT (content): Merge conflict in projects/views.py`, `Automatic merge failed; fix conflicts and then commit the result.`... I'm a bit unsure about how to resolve the conflicts... `views.py` in my editor (Sublime) has now refreshed and the lines: `<<<<<<<< HEAD`, `=========` & `>>>>>>>> dateReceived` have been inserted seemingly randomly in this file. – Noble-Surfer Jan 05 '17 at 11:02
  • How do I fix these conflicts? – Noble-Surfer Jan 05 '17 at 11:02
  • The file you are looking at actually reflects versions from _both_ parents of the merge. Everything contained between `<<<` to `===` is one version and everything in between `===` and `>>>` is the other version. You need to figure out which version, or maybe combinations of versions, you want to appear in your `master` branch, and only you can answer that question. – Tim Biegeleisen Jan 05 '17 at 11:04
  • Once you have resolved the conflicts and deleted the markers, do `git add` on `views.py`, then commit your work to complete the merge. That is it. – Tim Biegeleisen Jan 05 '17 at 11:05
  • Ah, ok, thanks. I am unsure which version I will want, as there is only a subtle difference- can I switch to my `dateReceived` branch to check, and then switch back to `master` without losing the `merge` & markers, etc? – Noble-Surfer Jan 05 '17 at 11:09
  • You don't need to switch branches, you can figure out which is which because the _bottom_ conflict marker says `dateReceived` :-) – Tim Biegeleisen Jan 05 '17 at 11:13
  • Ah ok- that's indicating that that's the branch it has come from? – Noble-Surfer Jan 05 '17 at 11:20
  • Correct, sometimes it can be hard to read, but in your case it looks like Git has used branch names, making your life even easier. – Tim Biegeleisen Jan 05 '17 at 11:21
  • Brilliant, thanks very much- really helpful explanation. – Noble-Surfer Jan 05 '17 at 11:41
  • Happy to help you. Git is really powerful once you know it well, but as you have already learned, there is a bit of a learning curve. – Tim Biegeleisen Jan 05 '17 at 11:47