1

I have 2 branches. main and deploy. I keep committing changes to the main branch, and when it's the time to deploy, I raise a PR to deploy from main and squash all commits for a cleaner commit history in the deploy branch, it helps to track changes that went in a release, and in the worst case it could be reverted easily as it goes as a single commit.

The issue is that whenever I raise a new PR from main to deploy, it doesn't account for the already merged changes. It shows the old commits again in the PR. I somehow understand the issue as the exact commit hash isn't available in the deploy branch. But how can I avoid this while keeping the deploy branch clean? Are there alternatives to achieve the same?

user3515181
  • 49
  • 1
  • 8

1 Answers1

1

Based on this statement:

I raise a PR to deploy from main and squash all commits for a cleaner commit history in the deploy branch, it helps to track changes that went in a release, and in the worst case it could be reverted easily as it goes as a single commit.

My suggestion would have been similar to Ôrel's comment, that after each PR into deploy:

You restart main from deploy

However, given your additional desire:

I'd like to keep the history on the main branch.

I'd suggest: if you like the history on main, then skip the squash step and just merge main into deploy with a regular merge commit. (Be sure to use --no-ff to force a merge commit if it would have fast-fowarded.)

So now, to track changes that went into each release, you would use:

git log --first-parent deploy

Note that log would show one commit per release linearly, and is similar to what you would see if you had used squashed commits instead. But this way all the history is actually there if you want to see it all with a regular log. Most Git UI tools have an option to display the first-parent view and diff between those commits like you could normally do with the squashed linear commits.

For your other desire, if you need to revert one of those merges, you revert the merge commit with:

git switch deploy
git revert -m 1 <merge-commit-id-to-revert>

And that has the same effect as reverting one of the squashed commits.

TTT
  • 22,611
  • 8
  • 63
  • 69