Start from scratch in git mess?

I've been working on a Visual Studio solution which contains about 40 or 50 projects.

I've added about 10 more projects to the .sln file, but in the meantime somebody else added a project to the .sln file.

So effectively there was a file - V1, which two people independently worked 开发者_运维知识库on creating two separate V2s.

I'm finding merging the changes a nightmare. The machine I'm using has BeyondCompare installed on it, and it's showing me a three column merge. I couldn't figure that out so I decided to just overwrite my local file with what git thinks the remote version is. But then I've the problem of re-adding the new projects back in.

So. Before I do the 90th pull+rebase / commit, is there an easy way to resolve this? Like, overwrite the current local copy of everything with what's in the remote side. Then re-add in my newly added projects. Then commit. Build + test. Then push. Perhaps?

*edit: FWIW, the machine also has tortoise git installed and everything right now is showing with green ticks... so that's pretty good right?

If you are asking for Git / some other tool to know that there are projects added in the sln file in remote, add them, and then add the ones I have added - no that should not be your approach.

Just fix the merge conflicts such that all the projects that were added on the remote and the ones you have added are there.

First, let's get you back to a known state. Do a git reflog and find a commit that's at a point before you tried to do all this pulling and rebasing. Do a git checkout -b my-feature <commit-id> to create a branch called my-feature that points to that commit. Verify that it works as expected without all the recent changes from the server.

Now, make your master branch match what's on the server by doing git branch -f master origin/master.

Now comes the hard part. You have to resolve the merge conflicts between what you changed and what changed on the server. This is a normal part of working in a group and you should methodically learn how to do it rather than flipping out about it. This is a good resource on it. Beyond compare is a very good tool to help resolve 3-way merges, and you should learn to use it.

Sometimes if you have a file that's generated by a tool rather than written by hand, it's easier to use the tool to make the changes, just erasing your local changes and adding them back later. If you don't really understand the syntax of an sln file, this might be the case for you.

To change just the sln file to match what's on the server, do:

git checkout master -- filename.sln
git commit -am "Reset solution file to match origin"

Then add your projects and commit the file again as normal. Now you want to get these changes onto the master branch. Do:

git rebase master
# resolve any merge conflicts, then git rebase --continue after each one
git checkout master
git merge my-feature
# test to make sure everything works
git push

I'm in a 'same but different' situation. I have spilt the problem into two parts. One is simply to capture what history I can and put that into a nominal sequence of snaphots/commits. I could identify a number of distinct sub-projects and phases, so each got its own repo during the capture phase. I can then graft them together and use git filter-branch to bring it all into one big history.

For the current work I am both starting a new git repo from a suitable 'now' point, and also continuing with established merge techniques, with dumps into the git repo until we can fully meld the two processes together. Some folk will need some convincing & (self-)management means we daren't drop the current practice until the new one is shown to work.

It takes a while to 'get' the git philosophy, and abandon old entrenched, but wrong, methods.