title: Git - using rebase to merge public branch to master
body: <p>We are currently 3 devs working on a feature branch. We kept committing and pushing WIP commits to the feature_branch (and to origin/feature_branch) and every other day we merged the master to the feature_branch to make sure we are up to date with all the other changes that are happening.</p>
  <p>Our feature_branch now contains ~100 commits (including lots of merge-commits) that can be easily squashed into one or two commits.
  Up until now, when a work is done on a feature branch, we just merged it back master and that resulted in spaghetti logs and checkpoint commits being pushed to master.</p>
  <p>Instead, we want to rebase.
  If we decided that our work on the feature_branch is done, and no developer will ever pull or push new commits from/to this branch - and that it's time to merge our changes back to master, will rebase violate <a href="https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing" rel="nofollow noreferrer">the golden rule of rebasing</a>?<br />
  After reading on the subject, rebase interactive on top of master sounds like a good idea (and then merge back to master which will be a ff merge) but I just want to make sure I'm not missing anything.</p>
  <p>Also, is there anything wrong with rebasing feature_branch after we kept merging the master into it (in order to keep it updated)?  Is it okay to squash merge-commits?</p>
  <p>Thanks!</p>