I'll try to give some pointers and tips. First I'll just say this. It's little point in going to git if you just need the svn-features. svn is fine in those cases. git can do a lot of more powerful things but you'll have to do it the git-way, any other way is going to be cumbersome, at best.
That said. If your long term goal is to fully adopt git thinking it might help to "just do it" like it was svn for a while and gradually change your thinking.
When you do a git pull
it actually does one of two things
git fetch
git merge
or
git fetch
git rebase
It depends on a config setting or the option --rebase
. On a local branch (even local master) I prefer to do rebase but when it comes to conflicts "their" and "mine" is very confusing but here is what happens.
- git will first rewind your working copy and HEAD back to where your local branch and origins branch diverged
- then apply all of the commits from origin.
- git will then try to re-apply your commits one by one. If a conflict happens now it's going to call your change, then one being re-applied "theirs" which is correct but very confusing. Think of "mine" being what is already in the working copy and "theirs" as what's going to be added and it makes more sense.
When you do a merge instead of a rebase then it's the other way around. Your changes are already in the working copy, "mine", and the changes that are being merged in are "their". Unfortunately very confusing.
I've never used kdiff3 or TortoiseGIT so I can't help there but I'll say this, if you get a conflict using the command line tool the file with the original name is going to be full of conflict markers, just as it would with svn. Use whatever tool your comfortable with to solve the conflict and then
git add <conflict file>
git rebase --continue
or
git add <conflict file>
git commit
depending on if you do rebase or merge to resolve the conflict and move on.