The answer of @Cupcake is good but I want to add some things...
If you want to be nearer than the tfs workflow when just checked in and solve your merge conflicts during this step, you could use:
git tfs rcheckin --quick --autorebase
which is equivalent to :
git tfs pull --rebase
git tfs rcheckin
It's not necessarily the better thing to do because, normally between the pull --rebase
(where your changes and the one coming from tfs are 'merged') and the rcheckin
(where you push your changes to tfs), you should at least build your solution and also run your unit tests.
But I recognized that sometimes it's a lot easier and my team (all old tfs users) only want to do that!
You should also be aware that's during the pull --rebase
step that your changes are 'merged' with the ones of your team so that's where merged are done at the file level and like with tfs when you checked in, you will have to solve conflicts.
In the case of the rcheckin --quick --autorebase
, if there is conflicts, the command will exit. You will have to solve them and lauch the command again.