Reputation: 4758
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):
git merge --squash my-feature-branch
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?
Upvotes: 2
Views: 161
Reputation: 13617
I will assume that main
(with the squashed commits) is some sort of "official" view that must not show the details in the history, and that the detailed branch is a "personal" branch that lets you investigate a more useful history for developers.
I suggest that you keep the following history:
0--------A-----------D <-- main
\ \ \
a--b--c--o--d--e--f--o <-- detailed
The two branches have a common base 0
. You develop on branch detailed
. The first feature consist of commits a
, b
, c
. When it is ready, you switch to main
, then
git merge --squash detailed
to create commit A
. Then you switch back to detailed
and
git merge main
This does not introduce any new changes, because the tips of the two branches must be equal at this point.
You repeat the procedure for the feature consisting of commits d
, e
, f
to create the squash-merge commit D
.
The effect of merging main
into detailed
is that the squash-merges will not consider the already merged feature commits. When you look at the history of main
, the detailed commits are invisible, but when you look at the history of detailed
, you see all commits, including those in main
.
Upvotes: 3