git - Migrate a Current branch to Master branch without losing history or no failure - (hard merge)

Question

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:

• rename the branch feature to master and master to xxxxx ( but I don't know how to keep the history of master branch)
• Perform a hard merge by first make a MR against master branch and delete everything in master and then force merge feature to master.
• Just go for rebase (might be less painful but could be catastrophic when conflicts).

appreciate the steps to perform this accurately. We use Gitlab.

question from:https://stackoverflow.com/questions/65910914/migrate-a-current-branch-to-master-branch-without-losing-history-or-no-failure

Answer 1

There is no history of a branch.¹ 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,² 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 clone³ 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.)

---

¹This 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.

²Obviously 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.

³The 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.