Is there a way to tell GIT two commits on different branches are related — i. e. they fix the same issue?

Question

I discovered a crash issue on one branch of my project. I fixed it, committed it.

Then I discovered that, contrary to my original belief, that particular crash bug was widespread across multiple branches, so I fixed it in the master branch.

Unfortunately, this leaves me with the 'same' commit across two branches (not exactly identical because the branches are slightly different in the same region of code).

Is there any way to tell GIT that the commits are related and should be ignored for the purposes of merges, when I pull changes from the master to the branch?

---

As background, the branch in question isn't designed to add functionality, it's designed to 'white list' the app in question -- same application, with different artwork and seed data. (Basically, a second company licenses our software and pretends it's theirs). This is the best solution I could come up with to let the software for the white-label version update based on the main version.

Answer 1

This should not be a problem if you plan on merging or cherry-picking later. The algorithms that do that will notice the similarities and do the right thing.

You will have multiple commit messages if you merge these two branches, but you should - this is the way you merge your work, the work here just happens to have the same content. If you are really concerned, once you merge, you can squash, but I would not bother, the history is important.

Answer 2

I'm not sure of your GIT workflow, but I would creating a hotfix branch from master, fix the issue in that branch, and merge it into all relevant branches.

This way if/when you merge your branch into master there will not be multiple commits for the same fix.