title: When I am using Git, should I rebase before I merge?
body: <p>I am working on a large scale Rails project, and the team I am working with is using Github to manage the project. While many changes are worked on locally and then pushed directly to our development branch, we create a branch when we are going to work on a very large change. When the time comes to merge that branch back into develop, I often try to rebase develop back into my feature branch before I merge my feature branch into develop (to prevent overwriting of other people's work). I find that when I do this, I seem to run into the same merge conflicts twice. I run into a whole list of conflicts while rebasing, then run into the same list of conflicts again while merging. Should I rebase develop into my feature branch before I merge my feature into develop, or should I just merge my feature into develop?</p>
  
  <p>Let's say my feature branch is called "new_feature". My process for merging it with the "develop" branch goes like this:</p>
  
  <pre><code>git checkout develop 
  
  git pull (this is set up on our rig to always pull rebase)
  
  git checkout new_feature 
  
  git rebase develop 
  
  (lots of merge conflicts ensue) 
  
  git checkout develop  
  
  git merge -no-ff new_feature 
  
  (same set of merge conflicts again)
  </code></pre>
  
  <p>It's as if the timeline changes from my rebase cause my new feature branch to kind of mirror develop all the way back, and then develop conflicts with a psudo-copy of itself.</p>