merge problems with GIT using sourcetree

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.

1 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.

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...'.

Suggest an answer

Log in or Sign up to answer
Community showcase

Scrum Roles Explained: the Do's and the Don'ts

Hello Community,  Today we are going to talk about the three Scrum Roles. There is the Development Team, the Scrum Master and the Product Owner. In my opinion these three are all really impo...

106 views 1 5
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you