The short answer is yes.

Haystack uses the commit history on your Github repositories to calculate its metrics. Specifically, Haystack uses metadata such as titles, messages, and timestamps to aggregate your key metrics around Change Lead Time, Throughput, etc.

Because of this, any change to the commit history will affect the data appearing in Haystack.

We suggest avoiding squashing or rebasing commits.

Not only does this help Haystack track your metrics more accurately, it helps avoid merge conflicts and other issues with team collaboration.

We generally want to keep our commit history intact. Yes, it means that local commit messages made by a developer can bloat the number commits in the tree and make it a bit less readable but it's far more useful to have a running log of commits overtime.

Note: You should never squash or rebase a commit after it's been pushed to Github. This causes issues and requires other developers to potentially re-clone or patch their work into the main source.

If your team is in the habit of squashing or rebasing their commits, we highly suggest avoiding this practice.

If the goal is to have a clean, running log of work then Github Releases and Tags are a more conventional way of keeping a clean list of updates rather than using commits in this fashion.