title: Is squashing commits into one best practice (for this particular workflow)?
body: <p>I have the following <code>git</code> workflow:</p>
  
  <ol>
  <li>Create new feature branch</li>
  <li>Work on feature branch</li>
  <li>Commit often</li>
  <li>Once feature is complete, merge into <code>master</code> branch</li>
  <li>Rinse and repeat</li>
  </ol>
  
  <p>However, sometimes, I have the need to revert a whole feature from master. This could involve a whole lot of <code>revert</code>ing. (<em>The reason for needing to revert a feature is I have a website that works off of one repo. From there, we use a script that deploys the site to either our Production site or Staging site. Both are done from our master branch. Don't ask, that's just what I've been given to work with. Sometimes, I'm working on something that I stage, but then an immediate change needs to be made, so I needed some way to pull my changes in order to clean the repo.</em>)</p>
  
  <p>I'm thinking that the easiest way to do so is if each feature branch has only one commit. Then I could <code>revert</code> that commit. So naturally, I am thinking of squashing all commits of a feature branch into one, prior to merging it into <code>master</code>.</p>
  
  <p>So now my workflow would look like:</p>
  
  <ol>
  <li>Create new feature branch</li>
  <li>Work on feature branch</li>
  <li>Commit often</li>
  <li>Once feature is complete <strong>git rebase -i HEAD~number_of_commits</strong> (or if remote branch is available, <strong>origin/feature_branch</strong>)</li>
  </ol>
  
  <p>Is there any issues with this logic? Does it go against any best practices? I did some testing myself and the whole workflow seems to run smoothly and solves my problem, but I wanted to run the idea by other (smarter) Git-ers to see if there is anything wrong with it.</p>
  
  <p>Thanks!</p>