git eclipse resolving conflicts results in recommitting non-modified changes as well

I've started using git (on github) and have a newbie workflow question. Apologies beforehand if the description is long-winded but I wanted to describe what I'm thinking as I'm going through the process so you can correct me. I'm also using Eclipse EGIT plugin, which I realize wi开发者_StackOverflow社区ll never be as good as using command line but just bear with me.

Our project is set up such that my partner owns a master repo and I'm a private collaborator. Whenever I push, I push directly to his repo. In general we're OK with committing, pulling and pushing, as long as there are no conflicts. Problem occurs whenever there are conflicts. Here's an example:

1. My partner and I start off my pulling the latest code into our respective working repos. No probs.
2. I modify FileA and FileB, add, commit, and push them both. No probs.
3. Meanwhile, my partner modifies FileA, then attempts a pull to get my updates.
4. Eclipse gives him an error: CheckOut conflict with FileA

5. We venture into git bash land and get a more useful message upon executing git pull:

   error: Your local changes ... written by merge: FileA. Please, commit your changes or stash them before you can merge.

6. OK, fair enough. He commits his changes (FileA), and attempts to pull again (through Eclipse).

7. He gets a message indicating FileA conflict. Good, this is expected. He now proceeds to resolve the conflict on FileA, and does a git add on FileA to indicate it's resolved.

8. He's now ready to commit and push. He expects his merged changes to FileA to be pushed. But now, the following is the part I don't get. Even though he did not modify FileB at all, Eclipse determines it to be part of his commit by default, so he needs to manually uncheck it to avoid recommitting FileB, and thus avoid pushing FileB (since no changes were made to it). But even doing so results in FileB being pushed upstream. As a result, not only does he end up pushing FileA, but also FileB.

I would like to know whether we are doing things the right way, and since we're probably not, advice appreciated.

Maybe in point 6. your colegue makes a commit that contains all the changes he made until an attempt to pull? That might happen if he uses something like commit -a a lot. It might also be the default behaviour of Eclipse to just add all the changes to all files to a commit. These changes may then include both files A and B.

To make sure only changes to FileA are commited, something like this should be used:

git add FileA
git commit         # Notice, no '-a' option

Not sure if Eclipse allows for this kind of fine grained control over which changes are and which aren't commited.