merge problems with GIT using sourcetree

Question

My company just recently started using GIT instead of SVN so we are not completly used to how the process goes. We are using source tree as our client.

Our problem is that, one of us will be working on the project and push at roughly the same time someone else commited. When they try to push, they are always made to merge even when they changed nothing that had to do with the other persons push. The merge results in them having to commit and push the other persons work (something I do not understand at all) and often results in a lot of lost work.

Our project is in Unity, which adds to diffuculty, but any help would be appreciated.

stevestreeting · Answer

I should have pointed out that 'rebase' is available in a few places:

* Preferences > Git > Use rebase instead of merge by default for tracked branches
* In the Pull dialog, 'Rebase instead of merge'
* Right-click on a branch in the sidebar, or a commit in the log and select 'Rebase...'.

stevestreeting · Answer

This is typical for DVCS - it's because you can commit whenever you like, and have to resolve any case where others have pushed first by either merging or rebasing. If you didn't unify those streams of commits, you'd end up with diverging lines of development. In svn, merge is implicitly part of 'svn update' when someone else committed before you, but it has the disadvantage of possibly messing up your clean working copy if there's a conflict.

When you pull, Git will often automatically 'fast-forward' your commits meaning that you don't need to explicitly merge. If this doesn't happen, then you will need to merge or rebase. Merging is often automatic if there are no conflicts, but you still have to perform it. There is another option, which is to rebase - you can only do this if you have not pushed your own local changes to anyone else yet (with Git you can push commits to places other than the shared primary if you wanted), and what it does is basically alter your commits *as if* they were committed on top of the other person's changes, instead of in parallel, which means you don't get any explicit merge or any separate lines of development in the log - everything looks linear. It's worth bearing in mind that you have to be a little more careful with conflict resolution in this case, because you're altering the original commits; when you merge, the original commits are retained so if you make a mistake when resolving conflicts, the original change is still there. Rebase is therefore a lot like 'svn update', which itself performs a merge in-place and can mess up your pending changes if you're not careful. So it's up to you which you prefer - rebase to keep the history linear, or merges to keep the history unaltered from your original commits.