I follow the standard practice of maintaining a "dev" branch in my software project and adding new features by first creating and checking out a new branch, writing the new feature, then merging the feature branch back into the "dev" branch.
However, I recently found while scrolling through the commit and branch graph in Gitkraken that one of these feature branches seems to have hijacked all of the previous commits from the "dev" branch.
In the screenshot above, the commits at the top all "belong" to the "dev" branch (as evidenced by hovering over the commit and observing the branch tag that pops up on the top left). The feature branch starting with "MAG-33..." was created during development and should only consist of commit b2b550. However, Gitkraken appears to think that commit 885da9 and all of its parents also "belong" to the branch "MAG-33..." even though "MAG-33..." didn't even exist at the time that commit 885da9 or the earlier commits were created.
What I would expect to see here is what Gitkraken displays on other feature branches. For example, "MAG-35..." in the following screenshot:
I am aware that git branches do not actually "own" commits but are merely pointers to the last commit in a chain of commits linked by a "parent" relationship, so I have two questions:
- What logic does Gitkraken use to "calculate" the "owner" of a commit for the purpose of the visual branch tree?
- Is there any way to force Gitkraken to recognize that commit 885da9 (and all previous commits) should "belong" to the "dev" branch in the graph?