My team has recently transitioned to a GitHub Actions CI/CD workflow and we are encountering an issue that I'm uncertain how best to resolve.
First, I'll describe our current branching strategy:
We are a Salesforce stack shop that uses the Org Development model. This means that each developer has their own sandbox, and in addition we have Integration, UAT, and Production environments.
We have created 3 long-lived branches in git that are meant to represent each of these non-developer sandboxes (int, uat, main). The intended workflow is as follows:
feature branches should be based from main.feature branch is considered ready for QA, a Pull Request is opened to compare the branch to int. Once squashed and merged, a GitHub Action will deploy the delta to the Integration environment.feature branch to uat. Once squashed and merged, a GitHub Action will deploy the delta to the UAT environment.feature branch to main. Once squashed and merged, a GitHub Action will deploy the delta to the Production environment.main should be updated, the feature branch should be rebased on top of main.The issue we have encountered is that after a feature branch has been merged into both int and main, our int branch still seems to think that it is behind the main branch. Example:
feature/A with commit1 has been squashed and merged into int, uat and main via Pull Requests and subsequently deployed to their relevant environments.feature/B is then created based on main, which includes the changes from feature/A.feature/B is ready to be merged into int, and a Pull Request is created.commit1 is already represented in int and wants to re-merge this commit into int.Looking into it, I can see that commit1 has a different hash in the int branch than the one in main. So, I believe I understand why git does not see these as the same commit, but I'm unsure what has caused the hash to change.
I'm certain I'm overlooking something here, or perhaps misunderstanding what is happening with git behind the scenes. Any help would be greatly appreciated.
Once squashed ...
Stop doing that.
In the same way that adding comments as a deodorant to cover up stinking code is a bad idea, squashing branches because the version history stinks is also a bad idea (and that is always the reasoning behind why people want to squash branches on pull requests, although expressed as an euphemism like "clean up the branch" or whatever).
Using fixup or squash in interactive rebase while working on a feature is not only perfectly fine (I am in no way advocating that commits are immutable and should never be changed), but more than that - almost required. However at the point when creating a pull request the history should be clean and proper (including all commits pass tests) and squashing is wrong.
Squashing will ruin your ability to drill down problems with git bisect. And as you have experienced it also breaks your workflow.