Question

I make a change to one existing file test.cs

1. git add .
2. git commit -m “my change to test.cs”
3. git pull origin master
4. > it pulls down SomeOtherFile.cs (changed by someone else, not new)
5. > I check the build… )
6. git push

When I go to github, there are two commits under my push, one for ‘test.cs’, and one for SomeOtherFile.cs

Is this expected behavior?

Thanks..

Answer 1

So what you are running into here is the difference between a Merge and a Rebase. When you did the:

git pull origin master

You created a merge commit which merged the changes in from master. That merge commit was empty, but it was created. This behavior from merge is expected, but in my opinion undesirable. The commit was created to hold the differences between the two branches (Your local and Origin Master), and is created regardless of the existence of any differences. If you had instead issued

git pull --rebase origin master

You would have done a rebase. A rebase looks for the last commit your local and Origin Master have in common, sets aside into temporary storage your changes since that commit, then layers on the changes from Origin Master (the SomeOtherFile.cs commit from NotYou), and finally replays your changes on top of that new updated line. This replaying is done commit by commit, so if you’re 10 commits ahead it will happen 10 times.

If there are no conflicts, then this all happens instantly and without intervention. If there is a conflict, then you will be stopped in the middle, asked to correct the problem, and then you issue a

git rebase --continue

to have the process move on. What happens here is that conflicts are handled by redefining your original commit, rather than by adding a merge commit. But it keeps the file histories clean, which merge does not as you have seen.