I have are requirement that the main branch has only one (potentially big) commit per issue ID. However, to confirm to the best practice of small commits, I also need to create and keep(!) multiple small commits per issue ID.
I have already found an OK solution (I think):
- Create a feature branch my-feature-branch from main.
- Make multiple small commits to my-feature-branch.
- In main:
git merge --squash my-feature-branch
- main now has the big commit, automatically with a message referring to the small commits, so you can always "zoom in" to the detailed history if needed.
- Keep my-feature-branch and stop working on it.
- Create a new feature branch my-feature-branch-2 etc.
However, it would still be nicer to not need multiple feature branches for this. It would be nice to just have one extra branch, e.g. main-detailed. The problem is that whenever I git merge --squash main-detailed
to master, Git tries to merge the full history of main-detailed, because it does not know that some of that history had already been merged via previous merge --squash
commits. Is it still possible somehow to implement the desired workflow?
The problem is .... Git not know that some of that history had already been merged
sqashing the commits changes the history. So the answer is no, there's no way to have 2 different commit histories also be the same commit history.