I have a classic situation where we were all working on the master branch and somewhere between when we had to perform a parallel pipelining process we cut the branch off this master and created a new branch say feature , now this feature branch started to have commits from the entire people and no commit landed in master.
Now after almost 7 months we worked on feature branch and now we want to merge this to master without losing the history of master branch. We have almost 2000 commits in feature branch so rebase is just a dangerous operation.
Approach we are thinking:
appreciate the steps to perform this accurately. We use Gitlab.
There is no history of a branch.1 There is history in a branch, because a branch name identifies one particular commit, and that commit identifies one or more previous commits, each of which also identify still-earlier commits and so on. We then say that these commits are in (contained within) that branch. They may also be contained within other branches as well.
The history in a Git repository is the commits. The commits are the history. If you have the commits, you have the history. They are the same thing, so there's no need to be concerned about separating them. The tricky part here is that the commits are found by their hash IDs. The hash IDs are big and ugly and impossible for humans to deal with correctly on any kind of long-term basis. So we don't even try: we use branch names to find the latest commit, from which we find all the earlier commits.
What this means for you is that your simplest approach, of renaming feature to master (or main or whatever you like) after renaming whatever name(s) may be in the way first, is probably the way to go. If, later, you wish to find a commit that can only be found by searching backwards from whatever used to be called master, when that is now called, say, history-from-1927,2 you would run git log history-from-1927 or git log origin/history-from-1927 to find it.
A branch name—or a remote-tracking name like origin/whatever, which Git creates in clones so that the user of the clone3 can see what the original repository could see—allows you, as the user of the clone, to find and see the commits without having to memorize their hash IDs. (It also protects those commits from being garbage collected, which is a matter for a separate question.)
1This isn't entirely right, as Git keeps so-called reflogs for branch names and other references. However, that's not what you mean. Reflogs are also specific to one particular repository: this history is not transferred by cloning.
2Obviously 1927 is unrealistic; even 1972 would be before Git existed. It's just meant to be whatever name you've used, without suggesting that you use this name, which is a terrible name. Use a better one.
3The person who makes the gets his or her own branch names in that clone, to use as he/she/they see fit. That's why their Git renames the origin-al (origin) branch names: if they want to create their own main and/or feature and/or whatever other names, they won't be affected by the names in the origin repository. Instead, their origin/* names will be affected by those names. That's why we have remote-tracking names: they track the branch names in the remote Git. We run git fetch to obtain any new commits that they have, that we don't have yet; this updates our remote-tracking names to remember those new commits, just as they updated their branch names to remember those new commits.