Q:

"Forced update" shown after git pull

After I did git pull in my repository, it is showing 
6cca7ee...32eb5b2 bug/12 -> origin/bug/12  (forced update)

Previously, I created bug/12 branch from parent branch parent/1.2.3, made changes in the code, and merged the bug/12 branch in the parent/1.2.3 branch and finished bug/12 branch. But due to some problem I need to again reopen the bug 12 and therefore I again created a bug/12 branch from parent/1.2.3 and did the code changes and pushed the changes to bug/12 branch. But now when I have taken the pull on parent/1.2.3 branch it is showing me forced update.
So, if I merge my newly created bug/12 branch in parent/1.2.3 branch will it create any problem or will that forced update be removed?

A:

This "forced update" thing can be very confusing, but you have asked an important question.
Whether there is any actual problem here—I suspect there isn't—depends on what you mean when you say:

... and finished bug/12 branch.

Git does not have a concept called finishing.  So it's not obvious what actual Git operations you caused to happen, in which repositories.
Git is distributed, so there is more than one repository
If there were only one repository, and it had various branch names like bug/12 and you did something like:
git checkout master
git merge bug/12
git branch -d bug/12

(which would merge the commit at the tip of bug/12 to master, then delete the branch name bug/12) this kind of problem would never come up: having deleted the name, it no longer exists.
But there isn't just one repository.  You:

created the name bug/12 in your repository
did some work in your repository, creating commits
sent those commits to another repository and had them create the name bug/12 in their repository
had your Git obtain new commits and/or branch names from them: this found that they now had a bug/12 in their repository, so your Git created an origin/bug/12 in your repository to remember their bug/12

Now, after all of this, I suspect that what you did—what you mean by "finished bug/12 branch"–is that you were using GitHub or Bitbucket or GitLab or similar, and you went onto their web interface and used the various little clicky buttons to merge bug/12 into master in their repository, and then deleted their bug/12 name.  This is very similar to the three hypothetical commands shown above, except that `git merge bug/12 could do a fast-forward operation instead of a true merge, while the GitHub merge pull request button will never do a fast-forward operation.
But I don't know that this is what you did.  I merely suspect it.
Stale remote-tracking names
Assuming that this is what you did, you probably went on to manually delete the branch name bug/12 from your own repository:
git branch -D bug/12

Since then, you've probably run git fetch (or had git pull run git fetch in a way that would fix things up), but you probably don't have fetch.prune set to true.  When you run git fetch, your Git calls up the Git over at origin and has them list out their branch names.  They don't have a bug/12 branch name at this point, but your Git made your own origin/bug/12 earlier, when they did have their bug/12 branch name.  Your Git therefore does nothing with your own origin/bug/12 name: there is no new value for this name, but you didn't instruct your Git to delete origin/* names that no longer have another name.
This means that as far as your Git is concerned, origin/bug/12 is still remembering a valid bug/12 name in the other Git repository, even though there is no such name any more.  Had you set fetch.prune to true or run git fetch --prune, your Git would have deleted this origin/bug/12.  So at this point, your origin/bug/12 is a stale name.  (Git does not define this term—it has no concept called stale names—but this seems like a good term for this kind of name.)
Again, all of this is deduction from facts not actually in evidence.  Is this really what happened?  I cannot know: you have not told me enough.
Stale names can result in this kind of behavior
Now, assuming that all of the above is correct, your own origin/bug/12 remembers what bug/12 on origin remembered some time ago.  That was before you clicked on a merge or rebase and merge or squash and merge web-browswer clicky button.  At this point, I must make at least one more assumption: that the button you used was not a pure merge but rather rebase and merge or squash and merge.
Let's draw the situation before a rebase-and-merge or squash-and-merge operation.  You have, in the Git repository over on GitHub—I'm going to assume GitHub at this point—a series of commits, each ending at a commit to which some branch name(s) point:
...--A--B--C--D   <-- parent/1.2.3
         \
          E--F   <-- bug/12

Here E and F are the two commits that fix the bug.  You now click on either rebase and merge or squash and merge and get either two or one new commit:
...--A--B--C--D--E'-F'  <-- parent/1.2.3
         \
          E--F   <-- bug/12

or:
...--A--B--C--D--G   <-- parent/1.2.3
         \
          E--F   <-- bug/12

(I'll go with this drawing because it's simpler).  You now have GitHub delete its bug/12 name:
...--A--B--C--D--G   <-- parent/1.2.3
         \
          E--F   [abandoned]

At some point, in your repository, you update your own Git's memory of the GitHub Git's branches:
...--A--B--C--D--G   <-- origin/parent/1.2.3
         \
          E--F   <-- origin/bug/12

Note how your stale origin/bug/12 name is still remembering commit F!
At this point you may or may not add even more commits to origin/parent/1.2.3 and/or bring your own parent/1.2.3 name up to date.  Let's draw in one more commit and show these two in sync:
...--A--B--C--D--G--H   <-- parent/1.2.3, origin/parent/1.2.3
         \
          E--F   <-- origin/bug/12

Remember, this is a drawing of what is in your repository.  The GitHub repository has this instead:
...--A--B--C--D--G--H   <-- parent/1.2.3

It has no origin/* names: it has only its branch names.  Your Git is the one with the origin/* names, including the stale origin/bug/12.  By now, their Git has completely discarded commits E-F.  Your Git is still keeping the otherwise unwanted E-F commits, due to your origin/bug/12 name.
Now you do something in their Git that creates the name bug/12, pointing to commit H:
...--A--B--C--D--G--H   <-- parent/1.2.3, bug/12

You now run git fetch (via git pull) in your repository.  Your Git sees their bug/12 pointing to commit H.  Your Git currently has this:
...--A--B--C--D--G--H   <-- parent/1.2.3, origin/parent/1.2.3
         \
          E--F   <-- origin/bug/12

but your Git is now going to take your origin/bug/12 and yank it off of commit F and move it to point to commit H instead:
...--A--B--C--D--G--H   <-- parent/1.2.3, origin/parent/1.2.3, origin/bug/12
         \
          E--F   [abandoned]

Your Git now does this unusual motion of your name origin/bug/12, yanking it from a commit that you are still keeping—commit F—over to commit H that is not a descendant of commit F.  (Commit H's only parent is G.  G's parent is D, whose parent is C, whose parent is B.  Commit H is therefore not a descendant of F, although they both share the same ancestry at commit B.)  This operation is a non-fast-forward and therefore your Git prints:
+ 6cca7ee...32eb5b2   bug/12 -> origin/bug/12  (forced update)

The plus sign at the front (which you omitted) indicates that this is a forced update because it is a non-fast-forward.
The two hash IDs here, 6cca7ee and 32eb5b2, are abbreviated versions of the full hash IDs of the commits I have been calling F and H above.  The output from git fetch includes the three-dots between these two hash IDs, indicating that 6cca7ee is not an ancestor of 32eb5b2.
The name bug/12 on the left side of the arrow is the branch name as seen in their repository (over on GitHub, or wherever that is).  The name origin/bug/12 is your Git's memory of their bug/12.
The (forced update) at the end indicates the same thing as the plus sign and the three dots: that this was a non-fast-forward, and therefore was done as a forced update.
The git fetch command has therefore told you three times that there was a forced update.
Is there a problem here?
The answer is probably not, but it depends, not on this change to your origin/bug/12, but rather on your own branch names.  In the drawings above, we've been drawing in some of your branch names, some of your remote-tracking origin/* names, and some of the other Git's branch names, depending on which Git repository we are talking about.  But we have not been drawing in all of your branch names.
Your branch names are yours.  They can point to any commit you have in your repository—including the E-F commits that the other Git, over on GitHub or wherever it is, has jettisoned.  If you allow one of your branch names to re-introduce those old commits, that's probably not good.  If you don't allow this, that's fine.  If you don't have any branch names that point to these old commits, you won't accidentally re-introduce them.
That is the key to the puzzle.  Commits are what matter.  Commits have commit hash IDs, and every Git everywhere in the world agrees that those commits get those hash IDs.  No other commit, anywhere or any time, can have those hash IDs!  Your Git still had them under your remote-tracking name, origin/bug/12.  It no longer has them under that name: that name has been updated to remember some other commit hash ID.  But you still have your branch names.  Do any of these remember the same hash ID as the stale origin/bug/12 you had up until the git fetch that your git pull ran updated it, just recently?
Only you can answer this, because only you have your Git repository.

