title: Git Merge simple vs Squash. What is the purpose? How to track one commit per feature?
body: <p>One thing I don't like with Git is the amount of commits. Don't get me wrong, it's a very convenient method of storing (safely) your work but in the long run there is too much granularity to search into.</p>
  
  <p>Let me describe the following scenario while developing with feature branches branched from <strong>develop</strong>.</p>
  
  <ul>
  <li><strong>Feature1</strong> is branched from <strong>develop</strong> and has 5 commits</li>
  <li><strong>Feature2</strong> is branched from <strong>develop</strong> and has 3 commits</li>
  <li><strong>Feature3</strong> is branched from <strong>Feature1</strong> and has 5+2 commits.</li>
  </ul>
  
  <p>The reason there are three branches is because there is a team working on the repository. <strong>Feature3</strong> assumes the <strong>Feature1</strong> is done, waiting to be merged into develop. There are other use cases for this but this is the simplest example.</p>
  
  <p>My goal is to have three commits on <strong>develop</strong> when all features are done.</p>
  
  <p><strong>Using git merge/pull</strong></p>
  
  <p>The above scenario works well. Because in essence both commands move commits into the develop branch. When <strong>Feature1</strong> is merged, <strong>develop</strong> references it's five commits. When <strong>Feature3</strong> is going to be merge, only the last two commits will be merged into <strong>develop</strong>.</p>
  
  <p>The only negative aspect of this is that <strong>develop</strong> gets too many commits. That means that when merging into <strong>master</strong> all that "noise" moves along. Therefore my goal is not achieved.</p>
  
  <p><strong>Using git merge with squash</strong></p>
  
  <p>When <strong>Feature1</strong> is merged, <strong>develop</strong> gets a new commit which is the aggregation of all <strong>Feature1</strong>. This is very nice, as the feature is now tracked with only one commit. When <strong>Feature1</strong> is removed, all intermediate commits are not visible any more making tracking easier. This also matches with concepts such as one pull request and one github issue.</p>
  
  <p>When <strong>Feature3</strong> is going to be merged there are conflicts and the problem starts. To solve this, you need to merge the <strong>develop</strong> back to <strong>feature3</strong>. with conflicts. This results to a new commit that has zero files changed. And now we merge squash <strong>Feature3</strong> to <strong>develop</strong>.</p>
  
  <p>My goal is achieved but with a lot of micro-management sacrifice. </p>
  
  <p><strong>Questions/Remarks</strong></p>
  
  <p>As far as I understand this is the git reality. One advice I've read is to create a sibling feature branch that holds the squashed merge commit. Use the sibling branch for the pull request therefore enforcing the usage of one commit per feature. This doesn't solve the conflicts created when trying to merge the other branches in, especially the ones inheriting from other feature branches.</p>
  
  <ul>
  <li>Can a do an internal squash within the same branch? I don't think so, but doesn't hurt to ask.</li>
  <li>I'm I missing something?</li>
  <li>Is this the trade-off of squash merge? Resolving conflicts that potentially have zero code changes?</li>
  <li>Is it worth while to go after the "one commit per feature" concept?
  
  <ul>
  <li>If not, then what's the purpose of squash? Who is using this?</li>
  </ul></li>
  </ul>
  
  <p>I've read alternative with rebase and simulating the squash with reset after merge, but as far as I understand none solves the overhead mentioned to merge <strong>feature3</strong>.</p>