Changes are shown in DEVELOP branch but they are already exists in DEVELOP branch in GIT Bitbucket

Question

I am facing an issue again and again that, while creating a Pull Request from Branch "A", which was created by "release" branch, to "Develop" I find code changes which are already exists in "develop" branch Any idea why it's happening?

Answer 1

tl;dr: This usually happens because you have different commits with the same changes in them on both the source and target branches of the Pull Request. This could be from cherry-picking/squashing/rebasing commits from a shared branch, or independently arriving at the same changes. Although sometimes it's unavoidable, if you can tweak your workflow to reduce its frequency, then this won't happen as often. Otherwise, you'll just have to get used to it.

Details:

The reason this happens is because a Pull Request doesn't actually show you "what will change", but instead shows you "what was changed on the branch since the source and target branches diverged". To see what will actually change you need to perform the merge. Many (possibly all?) SCM tools, when a Pull Request is created, behind the scenes actually do perform the merge, and some allow you to view that temporary merge commit directly in the UI. If you can't find that option you can just do the identical merge from any Git client to see what will actually change when the PR is completed.

If your gut reaction to the previous paragraph is "But why? It's not helpful to show me stuff getting changed that won't actually be changed,", you're not alone. and this is a pretty common complaint with Pull Request functionality (in most popular SCM Tools), However, it turns out that most of the time. seeing what was changed from the point of view of the branch getting merged in is preferred, If you think you'd always rather see what will actually change, and it's oftentimes different from the PR default view (which it sounds like yours is). then you may want to consider a tweak to your workflow, The simplest way to make the PR look like what you expect is to update your source branch with the target branch: which means:

1. If your source branch is a non-shared feature branch, then rebase your branch onto develop and all of the identical changes will fall out.
2. If your source branch is shared , then you should not rebase it, but instead consider merging develop into it first, and then when you PR the branch into develop only the actual changes will show up.

As for why you're getting duplicate changes on both branches, it's usually caused by one of these:

1. Different people made the same change on each branch and no one realized it until it was too late to prevent that from happening.
2. When completing a PR, commits were squashed or rebased, and the source branch was not deleted after completing that PR. This might happen if the source branch is another shared branch such as main or release , or if someone doesn't delete the branch simply because they want to keep working on it afterwards.
3. Some commits were cherry-picked from one shared branch, say develop , to another, say release . Perhaps you did this because you decided to release a change to Production sooner than originally thought.

When #1 happens, there really isn't much you can do about it, so you'll just have to live with it. Fortunately this doesn't happen very often in most cases, unless two people are working on the same issue without communicating.

#2 is a pretty straight forward and easy to fix. If you are completing Pull Requests using Squash or rebasing and the source branch is a shared branch, simply stop doing that. Only ever use regular merge for merging one shared branch into another. In the case that someone is completing a PR with squash or rebase on a feature branch, that's completely fine, but then they should delete that branch and start fresh with a new one even if they are continuing work on the same feature. In that case reusing a branch puts it in the same category as a shared branch. A good rule of thumb here is:

Don't rewrite a shared branch.

A corollary to that is:

Don't reuse old versions of branches that were rewritten.

#3 is sometimes unavoidable if you prematurely complete a PR into a branch like develop but then realize you need to release it sooner and have to get it onto a release branch. In that case you don't have much choice and probably do have to cherry-pick the commits and deal with the incorrect PR view when you merge release back into develop later. But if you know you need it on both branches before you merge it into either, you could merge it into release first, and then immediately merge release back down to develop (if you're using a workflow like Git Flow where that is allowed at all times), or you could branch off of the merge-base of the two branches, make your new commit, and then merge that into both target branches without changing the commit ID. Some people even recommend, specifically for bug fixes, branching off of the commit that caused the bug, even if it's super old, which also would work for merging it into however many branches need it, without the need to use cherry-picking. A good rule of thumb here is:

Merge instead of cherry-pick whenever possible.