git svn: Avoid large-scale conflicts in branching, merging, and rebasing

Question

I work on two machines (Mac and Windows) with git-svn. My remote repo is an svn. I use the Mac as master repo, and the Windows as a slave. So all git-svn operations are done on the Mac, and the Windows machine only "git pull" or "git push" with the Mac.

My workflow which looks like the following often puts me into the situation where I need to resolve hundreds of conflicts:

1. I mainly work on the Mac and then let Windows "git pull" and make tests.
2. Sometimes I need to work on Windows a bit and commit to a feature branch.
3. Then I "git push origin" to push the branch back to Mac.
4. Then on Mac I "git merge windows_branch" into my master branch.
5. Finally I "git svn rebase" and "git svn dcommit".

At step 5, Here come the conflicts!! And I once spent 3 hours going through each and every conflict using "git mergetool", "git rebase --continue", "git rebase --skip", and "git rebase --abort" workflow. If I'm lucky, I can figure out all of them; but sometimes, there are just way too many of them, and worse, the rebasing goes through the same set of conflicts repeatedly as it traverses the history (git knows only changes, not files); eventually I get confused, mis-resolve some of them, and cause bigger nightmares. Some scripts I learned can help me do something like "git accept-ours" or "git accept-theirs", but this doesn't work too well with history that involves deleted files, and I still need to accept repeatedly.

This was such a nightmare to the point where I really start to hesitate to use branching-and-merging workflow. The problem remains that I don't know exactly why there can be so many conflicts. But if there are recommended workflows or practice that can help me either prevent such conflicts or easily batch-resolve, it would be great.

Thanks for you help!

Answer 1

I finally found the problem and will try to answer my own question here:

In my global .gitconfig I disabled automatic merging with

mergeoptions = --no-commit

But after each "git pull", I didn't actually commit the merge on my Windows slave and later pushed things upstream to my Mac master. That was where all the conflicts came from.

I think the general suggestions I got from Web regarding rebase/merge workflows are:

1. Use "git fetch" instead of "git pull" as much as possible, so that further decisions can be made.
2. Use "rerere" to automatically resolve repeated known conflicts.
3. Prefer squashing small commits into a fat one before "git svn dcommit" or branch merging, using either "git rebase -i" or "git merge --squash". This will to some extent reduce the number of repeated conflicts.
4. Create duplicate branch or tracking branch before merging or rebasing to preserve unsquashed branch history.
5. Use "git list-files -u" to show conflicted files before merging.
6. Before every merging operation, use "git diff branch1 branch2" before merging to avoid merging blindly.
7. Use "git show branch..file" to view a particular file under a branch to verify against.