Supplementary question with: But when I generate a merge request, it doesn't show my all commits. Basically doesn't display commits before 13th Sept in Merge Request commits tab.
So in which case the above will happen, there are other devs who are also working in the same branch due to the same functionality if that matters.

Side question: Doesn't GitLab checks all files difference during MR (Merge request)? Or just shows the diff. of files which in commit list?

Update

22159e61

b0204dee

CodePudding user response：

Based on the discussion in the comments, it seems that your earlier commits were already merged. It's just the case that the person who made that merge undid your changes.

What this means is simple: you cannot use the original commits any more. They're already in the repository, followed by a subsequent commit that undid your work. You must now redo your work in new commits.

In other words, I think the question is now "How can I copy my old commits to new commits that achieve the same result, after someone backed out all my work?" That makes this a question about Git, rather than about GitLab.

Fortunately, it's easy to do, using either git cherry pick—this is the manual method—or git rebase, which automates cherry-picking. It's probably easier with git cherry-pick, even though this is the manual method, because git rebase itself is too clever. It may, depending on circumstances and invocation, notice that the commits are already there, and thus choose not to copy them.

So, let's look at how you copy commits that someone wrecked and then undid. Note that we do not do this in some fancy GUI, or in a web browser. We need command line Git, preferably with a sensible shell like bash, although it can be done in horrible CLIs like CMD.EXE. (I'm sure it can be done in PowerShell too, but PowerShell tends to be of the opinion that everything Microsoft does, like using UTF-16-LE, is good, and in fact that's not good. So I'll use bash and $ prompts here. Hah, I see TTT already made a similar comment.