So you’re using some kind of configuration management system and you use a pull based deploy method where nodes pull configuration and set themselves up. Whenever you make changes to these configuration files you’re probably committing those changes and pushing them to the place where you keep these files so that you can test if your changes don’t break the machines. You’re probably doing this in a feature branch and eventually stuff will break, stuff will un-break and every time you’re committing and polluting this feature branch. When you’re done and want to merge things into master you’re going to have a pull request with a bunch of commits that are just experiments along the way. Now there’s a couple of reasons why having too many useless commits in a pull request aren’t ideal but the best one is that reviewers and yourself will have a much harder time understanding changes because the really useful commits might be hidden among the bug fixes and experiments. Let’s see how to prevent it.
Create a branch from release to test your new feature:
Do a bunch of commits while you experiment and bug fix until you’re ready to create a pull-request to whomever owns the repository with your cool new feature. But wait, your branch is now something like this:
Where those commits could be reduced to maybe one or two with clear messages, but to test your deploy you already had to push this branch and its commits to remotes. So an easy way to clean stuff up is to create a new branch from master again:
Which makes it look like this:
Here comes the magic, merge the TEST branch into the DONE branch using squash and delete the TEST branch.
Now you have all the changes of TEST in done without the commit history and you can make as many commits as you like and get this branch ready for a pull-request. Let’s say just one commit would suffice:
Ready to pull request or merge into master without the messy history!